Backup 3-2-1 là nguyên tắc thiết kế giúp tránh phụ thuộc vào một bản sao hoặc một failure domain. Cách diễn giải phổ biến là: giữ 3 bản dữ liệu gồm production + ít nhất 2 copies, trên 2 loại storage hoặc failure domain khác nhau, và có 1 bản offsite.
Điểm quan trọng không nằm ở việc đếm đúng con số một cách máy móc, mà ở mục tiêu giảm khả năng một sự cố duy nhất phá hỏng toàn bộ đường phục hồi.
Giải thích 3-2-1 theo failure domain
3 copies
Production không được xem là backup. Bạn cần thêm ít nhất hai copies để một bản hỏng, bị xóa hoặc không dùng được vẫn còn đường recovery khác.
2 storage/failure domains
“Hai thiết bị” đặt chung server, chung account hoặc chung quyền xóa có thể không tạo separation thực sự. Trong môi trường hiện đại, nên nghĩ theo failure domain: storage technology, account, provider, region hoặc quyền quản trị khác nhau.
1 offsite copy
Offsite giúp giảm rủi ro mất dữ liệu do server/site/account hoặc physical location gặp sự cố. NIST SP 800-34 Rev. 1 cũng đề cập offsite storage trong contingency planning. Cách đánh giá vị trí, account separation, encryption và recovery path nằm ở Offsite Backup. Một failure mode thực tế để đối chiếu là server hỏng nhưng website vẫn phục hồi nhờ Offsite Backup.
Ví dụ 3-2-1 cho WordPress self-hosted
| Lớp | Ví dụ | Failure domain |
|---|---|---|
| Production | Hosting server | Primary host/account |
| Backup copy 1 | Backup storage của host | Provider backup system |
| Backup copy 2 | Object storage ở account/provider khác | Separate account/provider |
Nếu provider backup copy 1 thực chất nằm cùng account và attacker có thể xóa bằng cùng credential, separation kém hơn bảng gợi ý. Cần kiểm tra quyền thực tế.
Ví dụ 3-2-1 cho managed WordPress
Managed host có snapshot/backup built-in rất hữu ích, nhưng đừng mặc định đó là “đủ 3-2-1”. Hỏi:
- Backup nằm cùng control plane hay tách biệt?
- Khách hàng có thể export offsite không?
- Retention bao lâu?
- Có restore test và downloadable copy không?
- Nếu account bị takeover, attacker có xóa mọi restore point được không?
Cloud làm “2 media” thay đổi cách hiểu
Trong cloud, khái niệm “hai loại media” không phải lúc nào cũng map trực tiếp như tape + disk. Điều quan trọng hơn là tránh common-mode failure: cùng account, cùng IAM, cùng region, cùng provider control plane hoặc cùng ransomware path.
Vì vậy, khi áp dụng 3-2-1 hiện đại, ghi rõ failure domain thay vì chỉ ghi “copy 1/copy 2”.
Offline và immutable có phải là phần bắt buộc của 3-2-1?
Không phải phần định nghĩa truyền thống, nhưng chúng là các extension hữu ích khi threat model có ransomware hoặc privileged compromise. CISA khuyến nghị offline, encrypted backups và test định kỳ vì ransomware có thể cố xóa hoặc mã hóa các backup accessible.
“Immutable” cũng cần đánh giá control plane: ai có thể hạ retention, xóa account hoặc thay key? Xem Backup Security để kiểm tra quyền xóa, credential, encryption và monitoring của repository.
Anti-pattern thường gặp
- Production + backup folder trên cùng disk.
- Hai bucket khác tên nhưng cùng account admin có quyền xóa.
- Host snapshot + plugin backup vẫn lưu trên chính host.
- Offsite copy nhưng credential nằm plaintext trên production.
- 3 copies nhưng cả 3 chưa từng restore test.
- Copy offsite có retention quá ngắn, không còn known-good point.
Một anti-pattern khác là backup job âm thầm ngừng tạo restore point mới trong thời gian dài; case Backup Job thất bại nhiều tuần cho thấy vì sao 3-2-1 vẫn cần monitoring và freshness check.
3-2-1 không thay thế retention và restore test
Bạn có thể có 3 copies nhưng tất cả đều chứa corruption nếu được tạo sau khi lỗi bắt đầu. Retention và detection delay giúp giữ restore points cũ; restore test chứng minh copies thực sự dùng được. Case có backup nhưng website vẫn không restore được là ví dụ trực tiếp cho khoảng cách giữa số lượng bản sao và recoverability.
Với WordPress, xem bảo mật backup WordPress: restore integrity, retention và recovery.
3-2-1 Architecture Worksheet
| Copy | Storage | Account/Owner | Location/Provider | Delete path |
|---|---|---|---|---|
| Production | … | … | … | … |
| Backup A | … | … | … | … |
| Backup B | … | … | … | … |
Sau khi điền, hỏi: một credential compromise, một provider outage hoặc một thao tác xóa có thể phá cả ba không? Nếu có, failure domains chưa đủ tách biệt.
Test tình huống thất bại
- Giả lập production unavailable.
- Giả lập backup A không truy cập được.
- Restore từ backup B/offsite trong môi trường test.
- Đo thời gian và kiểm tra business flow.
- Xác minh key/credential recovery.
- Ghi issue và cải tiến architecture.
Để chứng minh từng copy thực sự usable, chạy restore test backup thay vì chỉ kiểm tra file tồn tại.
Khi nào 3-2-1 là chưa đủ?
Hệ thống critical có thể cần nhiều region/provider, immutable copies, database replication, point-in-time recovery hoặc additional disaster-recovery controls. 3-2-1 là baseline design principle, không phải chứng nhận rằng RPO/RTO đã đạt.
Nguồn kỹ thuật
- CISA StopRansomware Guide
- NIST SP 800-34 Rev. 1 — Contingency Planning Guide
- WordPress Developer — Backups
Kết luận
Backup 3-2-1 giúp loại bỏ single point of failure trong recovery. Khi áp dụng cho website hiện đại, hãy nghĩ theo copies + failure domains + offsite, sau đó bổ sung retention, security và restore test. Đếm đủ “3-2-1” nhưng mọi bản sao vẫn chung quyền xóa thì chưa đạt mục tiêu thực sự.
Dịch vụ liên quan: Nếu bạn cần triển khai hoặc vận hành chuyên sâu, xem Backup & Recovery cho website.