Bảo mật

Backup, snapshot và RAID: chọn đúng lớp phục hồi

Backup, snapshot và RAID giải quyết các nhóm rủi ro khác nhau. Hệ thống có mirror và nhiều snapshot vẫn có thể mất khả năng phục hồi nếu toàn pool hỏng hoặc tài khoản quản trị xóa được tất cả bản sao.

thuemaychu.vn
Ảnh minh họa: Backup, snapshot và RAID: chọn đúng lớp phục hồi

Backup, snapshot và RAID giải quyết các nhóm rủi ro khác nhau. Hệ thống có mirror và nhiều snapshot vẫn có thể mất khả năng phục hồi nếu toàn pool hỏng hoặc tài khoản quản trị xóa được tất cả bản sao.

Hiểu mục tiêu từng lớp

LớpMục tiêuGiới hạn chính
RAID/mirrorDuy trì dữ liệu khi một số ổ hỏng theo topologyKhông khôi phục trạng thái trước xóa hoặc sửa sai
SnapshotĐiểm khôi phục nhanh của dữ liệu tại storageCó thể phụ thuộc cùng pool và quyền quản trị
BackupBản sao để khôi phục theo phạm vi đã lưuPhụ thuộc độ đầy đủ, tính nhất quán và khả năng restore

Một snapshot được chuyển sang hệ thống khác có thể là thành phần của chiến lược backup; vấn đề là mức độc lập và quy trình phục hồi, không chỉ tên gọi. Tương tự, một file được gọi là 'backup' nhưng chỉ nằm trên host gốc vẫn chia sẻ nhiều rủi ro.

Đối chiếu theo sự cố

Sự cốCần đánh giá
Một ổ hỏngTopology RAID và quy trình thay ổ
Xóa nhầm fileSnapshot/bản sao trước thời điểm xóa
Database sửa saiBackup nhất quán và điểm phục hồi phù hợp
Host/pool bị mấtBản sao ngoài host cùng môi trường thay thế
Tài khoản quản trị bị chiếmQuyền độc lập, chống xóa/sửa bản sao
Mất toàn siteBản sao ngoài site và kế hoạch dựng lại dịch vụ

Tính nhất quán ứng dụng

Snapshot storage không tự đảm bảo mọi ứng dụng đã ghi trạng thái theo cách cần để restore. Với database, chọn công cụ/quy trình phù hợp và kiểm tra điều kiện nhất quán. Một bản copy directory khi database đang ghi không nên mặc định được coi là backup hợp lệ.

Ngoài dữ liệu, phục hồi có thể cần cấu hình, phiên bản ứng dụng, secret và khóa mã hóa. Lưu các thành phần này có kiểm soát quyền; một database nguyên vẹn nhưng thiếu khóa cần thiết có thể không dùng được.

Tách quyền và vị trí

  • Giữ ít nhất một bản sao không phụ thuộc host production.
  • Hạn chế quyền production xóa hoặc sửa bản sao.
  • Quản lý thời gian lưu và khả năng chống thay đổi theo dịch vụ.
  • Lưu khóa khôi phục riêng nhưng vẫn có thể tiếp cận khi sự cố.
  • Cảnh báo job backup thất bại và dung lượng sắp đầy.

Bản sao bất biến cần cấu hình đúng retention và quyền quản trị; không chỉ bật một nhãn 'immutable'. Kiểm thử khả năng xóa theo quyền của tài khoản bị giả định chiếm quyền trong môi trường được phép.

Thử restore, không chỉ xem backup thành công

  1. Chọn bộ dữ liệu và thời điểm cần khôi phục.
  2. Dựng môi trường tách biệt để tránh ghi đè production.
  3. Lấy đủ dữ liệu, cấu hình và khóa được phép dùng.
  4. Khôi phục và kiểm tra log cùng tính nhất quán.
  5. Mở ứng dụng, thử chức năng và đối chiếu dữ liệu.
  6. Ghi thời gian, lỗi và bước thiếu để cập nhật runbook.

Checksum giúp xác minh file truyền đúng nhưng không thay kiểm tra ứng dụng. Cần có người biết dữ liệu để đánh giá liệu hệ thống khôi phục đúng nghiệp vụ.

Lập chính sách theo nhu cầu

Chốt RPO/RTO trước khi chọn lịch sao lưu. Tần suất cần phù hợp dữ liệu thay đổi; thời gian lưu cần đáp ứng trường hợp lỗi chỉ được phát hiện muộn. Dự trù dung lượng, băng thông và thời gian restore khi database tăng trưởng.

Đọc Proxmox và ZFS để hiểu giới hạn mirror. Khi thuê máy chủ, hỏi backup có bao gồm database/file, lưu ở đâu và ai chịu trách nhiệm thử restore.

Snapshot trên cùng host có vô ích không?

Không. Nó hữu ích cho một số thay đổi hoặc xóa nhầm, nhưng cần bản sao độc lập cho rủi ro mất host/pool.

Backup thành công có đủ chứng minh an toàn?

Chưa. Cần thử restore và kiểm tra dữ liệu, cấu hình cùng chức năng ứng dụng.

Cần máy chủ cho workload này?

NOC thuemaychu.vn hỗ trợ chọn CPU, GPU và băng thông. PoC trong 24 giờ.

Bài viết liên quan

Xem tất cả bài viết
GọiFBZaloSalesZaloOA