Backup và Disaster Recovery là gì? Hướng dẫn RPO, RTO, 3-2-1 backup và phục hồi sau ransomware

Backup và Disaster Recovery là gì? Hướng dẫn RPO, RTO, 3-2-1 backup, immutable backup và phục hồi sau ransomware

Ảnh preview/raster đã được kiểm tra khả năng hiển thị trước khi đưa vào file Markdown, dùng minh họa cho Kubernetes backup và disaster recovery. Không dùng SVG.¹

Ảnh preview/raster đã được kiểm tra khả năng hiển thị trước khi đưa vào file Markdown, dùng minh họa cho công cụ backup mã nguồn mở. Không dùng SVG.²

Ảnh preview/raster đã được kiểm tra khả năng hiển thị trước khi đưa vào file Markdown, dùng minh họa cho deduplicating backup. Không dùng SVG.³

Tóm tắt nhanh

Backup là bản sao dữ liệu, cấu hình hoặc hệ thống để có thể khôi phục khi xảy ra lỗi, xóa nhầm, hỏng phần cứng, ransomware, lỗi triển khai hoặc sự cố hạ tầng. Disaster Recovery hay DR là kế hoạch, kiến trúc và quy trình để khôi phục dịch vụ sau sự cố lớn, không chỉ khôi phục file.

NIST SP 800-34 Rev. 1 mô tả contingency planning là quá trình giúp tổ chức hiểu mục đích, quy trình và định dạng của kế hoạch khôi phục hệ thống thông tin; tài liệu này cũng nhấn mạnh việc đánh giá hệ thống và hoạt động để xác định yêu cầu và ưu tiên khôi phục.⁴ AWS Well-Architected Reliability Pillar nhấn mạnh RTO và RPO là mục tiêu khôi phục; chiến lược DR phải được thiết kế theo nhu cầu kinh doanh, vị trí tài nguyên, chức năng workload, xác suất gián đoạn và chi phí khôi phục.⁵

Nói ngắn gọn: backup trả lời “dữ liệu còn không?”; disaster recovery trả lời “dịch vụ hoạt động lại được chưa, trong bao lâu và mất bao nhiêu dữ liệu?”

Vì sao backup thôi chưa đủ?

Một bản backup chỉ hữu ích khi bạn có thể restore đúng dữ liệu, đúng phiên bản, đúng thời gian, đúng hệ thống và trong giới hạn RTO/RPO.

Nhiều đội IT có backup nhưng vẫn không phục hồi được vì:

• backup chưa từng test restore;
• backup bị ransomware mã hóa cùng hệ thống chính;
• backup thiếu database transaction log;
• backup không có encryption key;
• backup chỉ có file, thiếu cấu hình app/IaC;
• backup không tương thích version mới;
• restore quá chậm so với RTO;
• không biết backup nào sạch trước thời điểm bị tấn công;
• backup nằm cùng account cloud bị compromise;
• không có runbook ai làm gì khi sự cố xảy ra.

Vì vậy backup phải đi kèm DR plan, restore testing, monitoring, access control và incident runbook.

Backup, High Availability và Disaster Recovery khác nhau thế nào?

AWS cũng phân biệt Availability và Disaster Recovery: cả hai dùng nhiều best practices giống nhau như monitoring, multi-location và automatic failover, nhưng DR tập trung vào bản sao rời của toàn bộ workload và thời gian khôi phục sau disaster.⁵

RPO và RTO là gì?

Hai chỉ số quan trọng nhất trong DR là RPO và RTO.

Ví dụ:

Hệ thống thanh toán:
RPO = 5 phút
RTO = 30 phút

Blog nội bộ:
RPO = 24 giờ
RTO = 2 ngày

Không phải hệ thống nào cũng cần RPO/RTO cực thấp. RPO/RTO càng thấp thì chi phí càng cao.

3-2-1 backup là gì?

Quy tắc phổ biến:

3 bản sao dữ liệu
2 loại media/storage khác nhau
1 bản copy offsite

Trong bối cảnh ransomware hiện đại, nên mở rộng thành:

3-2-1-1-0
3 bản sao
2 loại storage
1 bản offsite
1 bản offline hoặc immutable
0 lỗi qua kiểm tra restore/verification

Ý nghĩa thực tế:

• production data không được là bản duy nhất;
• backup không nên nằm cùng một account/quyền với production;
• phải có bản chống sửa/xóa;
• phải test restore định kỳ;
• phải giám sát backup job failure.

Immutable backup và offline backup

Immutable backup là backup không thể sửa hoặc xóa trong một khoảng thời gian retention, kể cả khi có credential thông thường. Ví dụ: object storage có Object Lock, WORM storage hoặc backup appliance có immutability.

AWS S3 Object Lock cho phép lưu object bằng mô hình write-once-read-many và có thể ngăn object bị xóa hoặc ghi đè trong một khoảng retention.⁶ Azure Blob immutable storage cũng hỗ trợ lưu dữ liệu business-critical ở trạng thái WORM với policy time-based retention hoặc legal hold.⁷

Offline backup là bản backup không kết nối thường trực với hệ thống, ví dụ tape, disk rời, offline vault hoặc air-gapped repository.

Khuyến nghị:

• có ít nhất một bản immutable/offline;
• tách quyền backup admin và production admin;
• không cho CI/CD hoặc app runtime quyền xóa backup;
• bật MFA delete hoặc tương đương nếu có;
• monitor hành động delete/retention change;
• test restore từ bản immutable/offline.

Các loại backup

Không có loại backup tốt nhất cho mọi trường hợp. Cần chọn theo RPO, RTO, dữ liệu, chi phí và khả năng vận hành.

Application-consistent vs crash-consistent

Snapshot storage nhanh nhưng không phải lúc nào cũng an toàn cho database.

Với database, cần hiểu rõ:

• snapshot có tích hợp database freeze/hook không;
• có backup transaction log/WAL/binlog không;
• restore có cần replay log không;
• có test query sau restore không;
• backup có đảm bảo consistency giữa nhiều volume không.

Database backup

PostgreSQL

PostgreSQL docs có chương riêng về backup và restore, gồm SQL dump, file system level backup và continuous archiving/point-in-time recovery.⁸

Chiến lược thường dùng:

Base backup hằng ngày
+ WAL archiving liên tục
= Point-in-time recovery

Checklist:

• backup pg_dump cho database nhỏ hoặc logical export;
• physical base backup cho database lớn;
• archive WAL;
• test PITR;
• backup roles/users/extensions;
• kiểm tra checksum;
• monitor replication lag;
• mã hóa backup;
• ghi lại version PostgreSQL.

MySQL

MySQL docs có mục riêng về backup and recovery.⁹ Với MySQL, cần cân nhắc:

• logical dump bằng mysqldump;
• physical backup bằng tool phù hợp;
• binary logs cho point-in-time recovery;
• replication;
• GTID;
• consistency khi backup InnoDB;
• backup users/grants.

MongoDB

MongoDB docs có phần backups riêng.¹⁰ Cần cân nhắc:

• snapshot phù hợp với replica set/sharded cluster;
• logical backup bằng mongodump cho trường hợp phù hợp;
• oplog để point-in-time hoặc incremental strategy;
• version compatibility;
• restore test.

Kubernetes backup

Kubernetes backup không chỉ là backup container image. Cần backup:

• Kubernetes resources: Deployment, Service, Ingress, ConfigMap, Secret, CRD;
• PersistentVolumes/PVC data;
• Helm release values;
• namespace labels/annotations;
• RBAC;
• admission policies;
• cluster-level config;
• external dependencies như database/object storage;
• etcd nếu tự quản lý control plane.

Kubernetes docs có mục backing up cluster, trong đó nhấn mạnh việc sao lưu etcd cho cluster state.¹¹ Velero cung cấp công cụ backup/restore Kubernetes cluster resources và persistent volumes; docs nói Velero có thể backup cluster, restore khi mất dữ liệu, migrate resources sang cluster khác và replicate production cluster sang dev/test.¹²

Ví dụ:

velero backup create prod-backup --include-namespaces app-prod
velero restore create --from-backup prod-backup

Lưu ý: với managed Kubernetes, etcd thường do cloud provider quản lý; nhưng application resources/PVC vẫn cần chiến lược backup riêng.

Backup cho SaaS

Nhiều người nghĩ SaaS tự backup là đủ. Thực tế cần xem trách nhiệm chia sẻ.

Cần kiểm tra:

• Google Workspace/Microsoft 365 retention;
• GitHub/GitLab repo backup;
• Jira/Confluence/Notion export;
• CRM/billing/helpdesk export;
• IAM/SSO configuration;
• audit logs;
• admin account recovery;
• data deletion retention;
• API export rate limit;
• legal/compliance retention.

SaaS provider có thể bảo vệ hạ tầng của họ, nhưng không luôn bảo vệ bạn khỏi xóa nhầm, insider, retention policy sai hoặc account compromise.

Backup encryption và key management

Backup thường chứa dữ liệu nhạy cảm nhất. Cần mã hóa và quản lý key đúng.

Checklist:

• encrypt in transit;
• encrypt at rest;
• key nằm ngoài backup repository;
• không để encryption key cùng backup;
• rotate key có kế hoạch;
• test restore với key thật;
• có quy trình khôi phục key khi admin nghỉ việc;
• quyền đọc backup tách khỏi quyền production;
• log truy cập backup;
• backup key/certificate/secrets manager metadata nếu cần.

Một backup không có key để decrypt coi như không thể restore.

Ransomware recovery

Ransomware làm backup phức tạp hơn vì attacker có thể:

• xóa backup trước khi mã hóa production;
• mã hóa backup nếu backup repo online;
• đánh cắp backup chứa dữ liệu nhạy cảm;
• chờ nhiều tuần để backup sạch bị overwrite;
• chiếm domain admin/backup admin;
• phá monitoring và logs;
• tấn công cả identity provider.

Chiến lược:

Immutable/offline backup
  + privileged access hardening
  + backup anomaly detection
  + clean restore point identification
  + isolated recovery environment
  + malware scan before reconnect
  + identity rebuild plan

Không nên restore trực tiếp vào môi trường production đang bị compromise. Nên có isolated recovery environment để kiểm tra.

DR strategies theo mức độ

AWS Well-Architected thường phân loại chiến lược DR theo mức độ đầu tư và tốc độ phục hồi.⁵

Không nên chọn active/active chỉ vì nghe tốt. Nó tăng độ phức tạp, chi phí và nguy cơ lỗi vận hành.

DR runbook cần có gì?

Runbook khôi phục nên đủ rõ để người trực sự cố làm theo.

Nội dung:

• tiêu chí kích hoạt DR;
• danh sách hệ thống ưu tiên;
• owner từng hệ thống;
• RPO/RTO;
• liên hệ khẩn cấp;
• backup location;
• credential/key cần thiết;
• thứ tự restore;
• lệnh restore;
• cách kiểm tra dữ liệu;
• cách đổi DNS/traffic;
• cách thông báo khách hàng;
• cách rollback;
• cách ghi log sự cố;
• checklist post-incident.

Runbook không nên chỉ nằm trong wiki nội bộ nếu wiki có thể cũng down. Cần có bản offline/print hoặc lưu ở nơi độc lập.

Restore testing

Backup chưa test restore thì chưa đáng tin.

Các kiểu test:

Nên đo:

• thời gian restore thật;
• dữ liệu bị mất thật;
• lỗi trong runbook;
• quyền/key thiếu;
• dependency bị quên;
• bước thủ công gây chậm.

Monitoring backup

Cần monitor:

• backup job success/failure;
• thời lượng backup;
• dung lượng backup;
• số lượng restore point;
• tuổi restore point mới nhất;
• replication lag;
• immutable retention;
• object lock status;
• error khi verify;
• ransomware-like deletion;
• chi phí storage;
• restore test status.

Alert tốt:

Backup job failed 2 lần liên tiếp
Không có restore point mới trong 6 giờ
Backup size giảm bất thường 80%
Retention/object lock bị thay đổi
WAL/binlog archiving dừng
Velero backup failed
Restore test quá RTO

Roadmap triển khai 30/60/90 ngày

Ngày 1–30: kiểm kê và giảm rủi ro lớn

• Kiểm kê hệ thống, database, SaaS, storage, Kubernetes cluster.
• Xác định owner, RPO, RTO cho hệ thống quan trọng.
• Kiểm tra backup hiện tại có restore được không.
• Bật backup cho database quan trọng.
• Tạo bản backup offsite.
• Tách quyền backup admin khỏi production admin.
• Mã hóa backup.
• Thiết lập alert backup failed.
• Viết runbook restore cơ bản.
• Test restore một database nhỏ.

Ngày 31–60: chuẩn hóa và chống ransomware

• Áp dụng 3-2-1 hoặc 3-2-1-1-0.
• Bật immutable backup/object lock cho dữ liệu quan trọng.
• Bật WAL/binlog/PITR cho database cần RPO thấp.
• Tạo backup cho IaC, GitOps repo, secrets metadata.
• Thiết lập Velero hoặc giải pháp backup Kubernetes nếu dùng K8s.
• Tạo isolated recovery environment.
• Thêm monitoring backup age/size/anomaly.
• Review quyền xóa backup.
• Tạo lịch restore test.
• Diễn tập tabletop ransomware.

Ngày 61–90: DR hoàn chỉnh

• Xây chiến lược DR: backup/restore, pilot light, warm standby hoặc multi-site.
• Test full application restore.
• Đo RTO/RPO thực tế.
• Tối ưu runbook theo kết quả test.
• Tự động hóa restore bước lặp lại.
• Kiểm tra DNS/traffic failover.
• Backup SaaS critical data.
• Tạo dashboard DR readiness.
• Diễn tập khôi phục khi identity provider bị lỗi.
• Review chi phí storage và retention.

Checklist backup nhanh

Dữ liệu

• Database.
• Object storage.
• File uploads.
• Persistent volumes.
• Config files.
• Secrets metadata.
• IaC/GitOps repos.
• SaaS exports.
• Audit logs.
• Encryption keys hoặc quy trình khôi phục key.

Kỹ thuật

• Full + incremental/differential phù hợp.
• PITR cho database quan trọng.
• Offsite copy.
• Immutable/offline copy.
• Encryption.
• Access control.
• Monitoring.
• Restore testing.
• Retention policy.
• Backup documentation.

Quy trình

• Owner.
• RPO/RTO.
• Runbook.
• Escalation.
• Communication plan.
• Restore approval.
• Evidence collection.
• Postmortem.
• Periodic DR drill.

Sai lầm phổ biến

• Có backup nhưng chưa từng restore.
• Backup nằm cùng account bị compromise.
• Không có immutable/offline copy.
• Không backup transaction logs.
• Không backup config/IaC.
• Không biết RPO/RTO.
• RTO trên giấy khác xa thực tế.
• Backup key bị mất.
• Backup chứa secret nhưng không mã hóa.
• Chỉ backup database, quên file uploads/object storage.
• Chỉ backup Kubernetes manifests, quên PV data.
• Restore production trực tiếp vào môi trường còn bị nhiễm ransomware.
• Không monitor backup failure.
• Không kiểm tra chi phí backup retention.
• Không có người chịu trách nhiệm.

Tooling tham khảo

Restic là công cụ backup mã nguồn mở tập trung vào bảo mật, hiệu quả và mã hóa; BorgBackup cũng là deduplicating backup program phổ biến cho Linux/Unix-like systems.¹³¹⁴

FAQ

Backup và Disaster Recovery khác nhau thế nào?

Backup là bản sao dữ liệu/hệ thống. Disaster Recovery là chiến lược và quy trình để khôi phục dịch vụ sau sự cố lớn theo RPO/RTO đã định.

RPO và RTO là gì?

RPO là mức mất dữ liệu tối đa chấp nhận được. RTO là thời gian tối đa để khôi phục dịch vụ.

3-2-1 backup là gì?

3-2-1 backup là có 3 bản sao dữ liệu, trên 2 loại storage/media, với 1 bản offsite. Với ransomware, nên có thêm một bản immutable/offline và restore verification.

Immutable backup có chống ransomware không?

Nó giúp giảm rủi ro ransomware xóa hoặc mã hóa backup, nhưng không đủ một mình. Cần tách quyền, monitor, identity security, malware scanning và isolated recovery.

Có cần backup Kubernetes không?

Có. Kubernetes cần backup resources, CRDs, RBAC, ConfigMaps, Secrets và PersistentVolumes. Velero là một công cụ phổ biến cho Kubernetes backup/restore.¹²

Backup test bao lâu một lần?

Tùy mức quan trọng. Hệ thống critical nên test định kỳ theo tháng/quý và sau thay đổi lớn. Ít nhất phải có restore test thực tế, không chỉ kiểm tra backup job success.

Kết luận

Backup và Disaster Recovery là nền tảng sống còn của vận hành IT. Một hệ thống không có backup đáng tin cậy có thể mất dữ liệu vĩnh viễn; một hệ thống có backup nhưng không có DR plan vẫn có thể downtime quá lâu hoặc restore sai dữ liệu. Điểm cốt lõi là xác định RPO/RTO theo nhu cầu kinh doanh, có bản backup offsite/immutable, bảo vệ key và quyền truy cập, test restore định kỳ và có runbook rõ ràng.

Cách triển khai thực tế là bắt đầu bằng kiểm kê hệ thống quan trọng, kiểm tra backup hiện tại, test restore, thêm monitoring và offsite copy. Sau đó nâng cấp sang immutable backup, PITR cho database, Kubernetes backup, isolated recovery, DR drill và tự động hóa khôi phục. Backup chỉ có giá trị khi bạn đã chứng minh restore được.

Nguồn tham khảo

Footnotes

1. GitHub Open Graph preview image for vmware-tanzu/velero. https://opengraph.githubassets.com/backup-dr-guide/vmware-tanzu/velero ↩

2. GitHub Open Graph preview image for restic/restic. https://opengraph.githubassets.com/backup-dr-guide/restic/restic ↩

3. GitHub Open Graph preview image for borgbackup/borg. https://opengraph.githubassets.com/backup-dr-guide/borgbackup/borg ↩

4. NIST SP 800-34 Rev. 1. “Contingency Planning Guide for Federal Information Systems.” https://csrc.nist.gov/pubs/sp/800/34/r1/final ↩

5. AWS Well-Architected Reliability Pillar. “Plan for Disaster Recovery (DR).” https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html ↩ ↩² ↩³

6. AWS S3 User Guide. “Using S3 Object Lock.” https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html ↩

7. Microsoft Learn. “Immutable storage for Azure Blob Storage.” https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview ↩

8. PostgreSQL Docs. “Backup and Restore.” https://www.postgresql.org/docs/current/backup.html ↩

9. MySQL Docs. “Backup and Recovery.” https://dev.mysql.com/doc/refman/8.4/en/backup-and-recovery.html ↩

10. MongoDB Docs. “Backups.” https://www.mongodb.com/docs/manual/core/backups/ ↩

11. Kubernetes Docs. “Backing up a cluster.” https://kubernetes.io/docs/concepts/cluster-administration/backing-up/ ↩

12. Velero Docs. “Overview.” https://velero.io/docs/main/ ↩ ↩²

13. Restic documentation. https://restic.readthedocs.io/en/stable/ ↩

14. BorgBackup official website. https://www.borgbackup.org/ ↩