Cloud Backup Và Disaster Recovery: Runbook Khôi Phục Dịch Vụ Trên AWS, Azure, GCP

Khi chạy dịch vụ trên cloud, rất dễ nghĩ rằng “nhà cung cấp đã lo hết”. Thực tế, AWS, Azure hay GCP giúp hạ tầng bền hơn, nhưng không tự đảm bảo dữ liệu của bạn có thể khôi phục đúng lúc, đúng phiên bản và đúng quy trình. Một thao tác xóa nhầm database, ransomware trong workload, lỗi deploy phá schema hoặc outage theo vùng vẫn có thể khiến dịch vụ dừng. Vì vậy cloud backup disaster recovery cần được thiết kế như một năng lực vận hành, không phải một checkbox trong console.

Bài viết này đi từ khái niệm RPO/RTO, kiến trúc backup đa lớp, cách triển khai snapshot và cross-region backup trên AWS/Azure/GCP, đến runbook restore, lỗi thường gặp, checklist nghiệm thu và bài lab để đội sysadmin/cloud engineer có thể diễn tập định kỳ.

1. Phân biệt backup, high availability và disaster recovery

High availability giúp dịch vụ tiếp tục chạy khi một instance hoặc một zone gặp lỗi. Backup giúp có bản sao dữ liệu để khôi phục khi dữ liệu bị mất hoặc bị hỏng. Disaster recovery là kế hoạch khôi phục toàn bộ dịch vụ ở trạng thái chấp nhận được sau sự cố lớn. Ba khái niệm này bổ sung nhau nhưng không thay thế nhau.

HA trả lời câu hỏi: nếu một node chết, dịch vụ có còn chạy không?
Backup trả lời câu hỏi: nếu dữ liệu bị xóa/hỏng, có bản sạch để quay lại không?
DR trả lời câu hỏi: nếu cả region, account, subscription hoặc cụm chính gặp sự cố, khôi phục ở đâu và trong bao lâu?
Restore drill trả lời câu hỏi quan trọng nhất: bản backup có thật sự dùng được không?

2. RPO và RTO: hai con số phải chốt trước khi mua công cụ

RPO (Recovery Point Objective) là mức mất dữ liệu tối đa chấp nhận được. RTO (Recovery Time Objective) là thời gian tối đa để khôi phục dịch vụ. Nếu hệ thống billing có RPO 15 phút và RTO 1 giờ, thiết kế backup hằng ngày là không đủ. Ngược lại, một wiki nội bộ có thể chấp nhận RPO 24 giờ để giảm chi phí.

RPO 24 giờ: backup daily, phù hợp dữ liệu ít thay đổi hoặc ít quan trọng.
RPO 1 giờ: snapshot hoặc dump theo giờ, cần automation và monitoring.
RPO vài phút: replication, binlog/WAL shipping, continuous backup.
RTO vài phút: warm standby hoặc active-active, chi phí cao hơn nhiều.
RTO vài giờ: restore từ backup + IaC, phù hợp nhiều hệ thống nội bộ.

3. Kiến trúc backup đa lớp cho cloud platform

Một thiết kế an toàn thường có nhiều lớp: snapshot nhanh để restore gần, backup độc lập để chống xóa nhầm, copy sang region khác để chống lỗi vùng, và export định kỳ sang tài khoản/project tách biệt để giảm rủi ro compromise.

Local snapshot: khôi phục nhanh nhưng không đủ nếu account bị compromise hoặc region lỗi.
Cross-region copy: bảo vệ khi region chính gặp sự cố.
Cross-account hoặc immutable backup: giảm nguy cơ attacker xóa cả backup.
Application-aware backup: dump database hoặc dùng native backup để đảm bảo consistency.
Infrastructure as Code: không chỉ backup dữ liệu, còn cần tái tạo network, IAM, compute và cấu hình.

4. Ví dụ AWS: EBS snapshot, RDS backup và cross-region copy

Trên AWS, có thể kết hợp AWS Backup, EBS snapshot, RDS automated backup, S3 versioning/Object Lock và Route 53 failover. Dưới đây là các lệnh kiểm tra nhanh bằng AWS CLI trong một tài khoản lab.

# Liệt kê recovery point gần nhất trong vault
aws backup list-recovery-points-by-backup-vault   --backup-vault-name prod-backup-vault   --max-results 10

# Tạo snapshot EBS thủ công cho một volume quan trọng
aws ec2 create-snapshot   --volume-id vol-0123456789abcdef0   --description "manual pre-maintenance snapshot $(date -Iseconds)"   --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Service,Value=payment},{Key=Env,Value=prod}]'

# Kiểm tra RDS automated backup retention
aws rds describe-db-instances   --query 'DBInstances[].{DB:DBInstanceIdentifier,Retention:BackupRetentionPeriod,MultiAZ:MultiAZ}'   --output table

Điểm cần nhớ: snapshot block storage chưa chắc application-consistent. Với database tự quản lý trên EC2, nên flush/freeze hoặc dùng native dump/WAL backup phù hợp trước khi snapshot.

5. Ví dụ Azure: Recovery Services Vault và soft delete

Azure thường dùng Recovery Services Vault hoặc Backup Vault để bảo vệ VM, Azure Files, SQL workload. Với môi trường production, nên bật soft delete, multi-user authorization nếu có, private endpoint khi cần và policy retention rõ ràng.

# Liệt kê vault trong resource group
az backup vault list -g rg-prod --query '[].{name:name,location:location}' -o table

# Xem item đang được backup
az backup item list   --resource-group rg-prod   --vault-name prod-rsv   --backup-management-type AzureIaasVM   -o table

# Kiểm tra job backup gần đây
az backup job list   --resource-group rg-prod   --vault-name prod-rsv   --status Completed   -o table

Nếu chỉ cấu hình policy mà không kiểm tra job và restore point, đội vận hành rất dễ phát hiện backup đã fail quá muộn. Cần cảnh báo khi backup job lỗi hoặc không có recovery point mới trong ngưỡng RPO.

6. Ví dụ GCP: snapshot schedule, Cloud SQL backup và bucket retention

Trên GCP, Compute Engine có snapshot schedule, Cloud SQL có automated backup/point-in-time recovery, Cloud Storage có versioning và retention policy. Với dữ liệu quan trọng, nên tách project backup hoặc dùng quyền IAM tối thiểu.

# Liệt kê snapshot policy
 gcloud compute resource-policies list --filter="snapshotSchedulePolicy:*"

# Xem backup config của Cloud SQL
 gcloud sql instances describe prod-db    --format="value(settings.backupConfiguration.enabled,settings.backupConfiguration.pointInTimeRecoveryEnabled)"

# Bật versioning cho bucket chứa artifact quan trọng
 gsutil versioning set on gs://prod-critical-artifacts

# Xem retention policy của bucket
 gsutil retention get gs://prod-critical-artifacts

Cloud SQL PITR giúp quay về thời điểm trước khi lỗi logic xảy ra, nhưng chỉ hiệu quả nếu đội vận hành biết timestamp sự cố và đã diễn tập restore sang instance mới.

7. Runbook restore: viết trước khi sự cố xảy ra

Một runbook tốt không chỉ nói “restore backup”. Nó phải chỉ rõ ai quyết định, restore ở đâu, dùng bản nào, kiểm tra dữ liệu ra sao, chuyển traffic như thế nào và khi nào rollback. Runbook cần đủ cụ thể để một kỹ sư trực ca có thể làm theo lúc áp lực cao.

Xác định incident commander và người phê duyệt restore.
Freeze thay đổi ghi dữ liệu nếu cần để tránh split-brain.
Chọn recovery point theo timeline sự cố.
Restore sang môi trường tạm hoặc DR trước, không ghi đè production khi chưa kiểm tra.
Chạy smoke test, kiểm tra dữ liệu quan trọng, quyền truy cập, queue và background job.
Chuyển DNS/load balancer/route khi đã đạt tiêu chí.
Ghi lại thời gian thực tế để so với RTO/RPO.

8. Mẫu runbook khôi phục database production

# 1. Ghi nhận mốc thời gian sự cố
INCIDENT_TIME="2026-06-26T18:42:00+07:00"
SERVICE="payment-api"

# 2. Dừng job ghi dữ liệu phụ trợ nếu có
kubectl -n prod scale deploy/payment-worker --replicas=0

# 3. Restore database sang instance mới từ recovery point gần nhất trước INCIDENT_TIME
# Ví dụ thao tác cụ thể tùy cloud provider: RDS restore-db-instance-to-point-in-time,
# Azure SQL point-in-time restore, hoặc Cloud SQL clone với PITR.

# 4. Chạy migration kiểm tra ở chế độ read-only nếu ứng dụng yêu cầu
kubectl -n prod run db-check --rm -it --image=postgres:16 --   psql "$RESTORED_DATABASE_URL" -c "select count(*) from orders;"

# 5. Smoke test ứng dụng với database đã restore
curl -fsS https://staging-dr.example.com/healthz
curl -fsS https://staging-dr.example.com/api/orders?limit=1

# 6. Chuyển traffic sau khi incident commander phê duyệt
# Update secret/endpoint, rollout deployment, kiểm tra error rate và latency.

Output kỳ vọng của smoke test phải rõ ràng: HTTP 200 cho health check, query dữ liệu trả kết quả hợp lệ, application log không có lỗi migration/schema, metric lỗi không tăng sau khi chuyển traffic.

9. Monitoring cho backup và DR

Backup không có monitoring thì chỉ là niềm tin. Cần đo cả trạng thái job, tuổi recovery point, dung lượng backup, lỗi copy cross-region và kết quả restore drill gần nhất.

Alert khi backup job fail hoặc chạy quá lâu.
Alert khi recovery point mới nhất cũ hơn RPO.
Alert khi cross-region copy lỗi.
Dashboard dung lượng và chi phí backup theo service.
Log audit cho thao tác xóa backup/vault/snapshot.
Báo cáo restore drill hằng tháng hoặc hằng quý.

10. Lỗi thường gặp

10.1. Có snapshot nhưng không restore được ứng dụng

Nguyên nhân thường là thiếu cấu hình, secret, IAM role, security group hoặc DNS. Backup dữ liệu phải đi cùng IaC và tài liệu phụ thuộc. Hãy thử restore trong account/project sạch để phát hiện thiếu sót.

10.2. Backup cùng account bị xóa khi bị compromise

Nếu attacker có quyền admin trong cùng account, họ có thể xóa snapshot hoặc giảm retention. Dùng cross-account backup, vault lock/Object Lock, MFA delete hoặc quy trình phê duyệt nhiều người cho thao tác phá hủy.

10.3. RPO ghi trên giấy nhưng job backup không đủ tần suất

Một service cam kết RPO 15 phút nhưng chỉ backup mỗi 6 giờ là sai thiết kế. Cần map từng workload với policy cụ thể và có alert dựa trên recovery point age.

10.4. Không kiểm tra restore vì sợ tốn chi phí

Chi phí restore drill định kỳ nhỏ hơn rất nhiều so với downtime kéo dài vì backup hỏng. Có thể chọn mẫu service quan trọng, chạy drill theo lịch và xóa tài nguyên sau khi nghiệm thu.

11. Checklist nghiệm thu cloud backup disaster recovery

Mỗi workload có owner, RPO, RTO và policy backup rõ ràng.
Backup job thành công và được monitor tự động.
Recovery point mới nhất không vượt ngưỡng RPO.
Backup quan trọng có copy cross-region hoặc cross-account.
Có bảo vệ chống xóa nhầm/xóa độc hại như vault lock, object lock hoặc soft delete.
Runbook restore đã được viết, review và lưu ở nơi đội trực ca truy cập được.
Đã diễn tập restore ít nhất một lần và ghi nhận thời gian thực tế.
IaC có thể tái tạo hạ tầng tối thiểu cho DR.
DNS/load balancer/failover plan đã được kiểm tra.
Chi phí backup được theo dõi để tránh tăng không kiểm soát.

12. Bài lab cuối bài

Tạo một VM nhỏ và một database mẫu trong cloud lab.
Thiết lập snapshot/backup tự động với retention 7 ngày.
Copy backup sang region khác hoặc bucket/vault tách biệt nếu tài khoản lab hỗ trợ.
Xóa một bảng dữ liệu mẫu hoặc làm hỏng file cấu hình để mô phỏng sự cố.
Restore sang instance mới thay vì ghi đè instance cũ.
Chạy smoke test và ghi lại RPO/RTO thực tế.
Viết lại runbook dựa trên những bước bị thiếu trong lúc lab.

Kết luận

Cloud backup disaster recovery không phải là bật một policy rồi quên. Đó là quá trình thiết kế RPO/RTO đúng với nhu cầu, bảo vệ backup khỏi lỗi vùng và lỗi con người, viết runbook đủ chi tiết, monitor liên tục và diễn tập khôi phục định kỳ. Khi sự cố thật xảy ra, đội đã từng restore thành công trong lab sẽ bình tĩnh hơn rất nhiều so với đội chỉ có niềm tin vào nút “backup enabled”.