Backup và restore Cloud Platform trong production: chiến lược 3-2-1, snapshot và kiểm thử khôi phục

backup và restore Cloud Platform không phải là việc bấm nút snapshot rồi yên tâm. Trong môi trường production, backup chỉ có giá trị khi anh biết rõ dữ liệu nào được bảo vệ, mất tối đa bao lâu là chấp nhận được, khôi phục trong bao lâu, và đã từng restore thử ít nhất một lần trong điều kiện gần giống sự cố thật.

Bài này đi theo hướng thực chiến cho đội SysAdmin/DevOps đang vận hành VM, database, object storage và dịch vụ chạy trên cloud. Ví dụ dùng cú pháp Linux phổ biến, AWS CLI minh họa, nhưng tư duy áp dụng được cho Google Cloud, Azure, DigitalOcean, Vultr hoặc hạ tầng private cloud.

Vì sao backup và restore Cloud Platform hay thất bại trong sự cố thật?

Phần lớn hệ thống có backup, nhưng vẫn không khôi phục được vì ba lý do: backup thiếu thành phần, backup chưa từng được restore thử, hoặc quyền truy cập vào bản backup cũng mất khi tài khoản cloud gặp sự cố. Vì vậy, backup và restore Cloud Platform cần được thiết kế như một quy trình vận hành, không phải một tính năng phụ.

RPO: lượng dữ liệu tối đa có thể mất. Ví dụ RPO 15 phút nghĩa là chấp nhận mất tối đa 15 phút dữ liệu.
RTO: thời gian tối đa để dịch vụ chạy lại. Ví dụ RTO 2 giờ nghĩa là sau 2 giờ người dùng phải truy cập được hệ thống tối thiểu.
Restore point: mốc dữ liệu có thể khôi phục.
Runbook: tài liệu từng bước để người trực ca có thể khôi phục mà không cần đoán.

Chiến lược 3-2-1 cho Cloud Platform

Quy tắc 3-2-1 nghĩa là có ít nhất 3 bản dữ liệu, nằm trên 2 loại lưu trữ khác nhau, và 1 bản ở ngoài vùng lỗi chính. Trên cloud, có thể triển khai như sau:

Dữ liệu production chạy trên volume hoặc managed database.
Snapshot định kỳ nằm trong cùng cloud account để restore nhanh.
Bản export nén/mã hóa đẩy sang object storage khác region hoặc account khác.
Với hệ thống quan trọng, thêm bản immutable/object lock để chống xóa nhầm hoặc ransomware.

Tài liệu chính thống của AWS về hướng backup có thể tham khảo tại AWS Prescriptive Guidance for Backup and Recovery. Nếu dùng Kubernetes, anh nên đọc thêm Velero documentation để hiểu cách backup resource và persistent volume.

Thiết kế phạm vi backup: đừng chỉ backup server

Một lỗi rất thường gặp là chỉ snapshot VM nhưng quên database managed, file upload, secret, DNS record, cấu hình load balancer, rule firewall và pipeline deploy. Khi restore, máy ảo có thể bật lên nhưng ứng dụng vẫn lỗi vì thiếu cấu hình.

Checklist thành phần cần đưa vào kế hoạch

Database: PostgreSQL, MySQL, MongoDB, Redis nếu có persistence.
File người dùng upload: thư mục /var/www/uploads, bucket S3-compatible, media WordPress.
Cấu hình ứng dụng: .env, Nginx/Apache config, systemd unit, cron.
Infrastructure as Code: Terraform, Ansible inventory, Helm values.
Secret: lưu trong password manager/Vault/KMS, không chỉ nằm trên một server.
DNS/CDN/WAF: export cấu hình hoặc quản lý bằng IaC.

Ví dụ backup database PostgreSQL lên object storage

Ví dụ dưới đây tạo bản dump PostgreSQL, nén bằng gzip, mã hóa bằng GPG, sau đó upload lên S3. Với production lớn, anh nên cân nhắc snapshot cấp storage hoặc công cụ native như WAL archiving, nhưng dump vẫn hữu ích cho lab, staging và database vừa.

#!/usr/bin/env bash
set -euo pipefail

APP="billing-api"
DATE=$(date +%F-%H%M)
BACKUP_DIR="/var/backups/${APP}"
BUCKET="s3://company-dr-backup/postgres/${APP}"
DB_NAME="billing"
DB_USER="backup_user"

mkdir -p "$BACKUP_DIR"

pg_dump -U "$DB_USER" -d "$DB_NAME"   --format=custom   --file="$BACKUP_DIR/${DB_NAME}-${DATE}.dump"

gzip -9 "$BACKUP_DIR/${DB_NAME}-${DATE}.dump"
gpg --batch --yes --symmetric --cipher-algo AES256   "$BACKUP_DIR/${DB_NAME}-${DATE}.dump.gz"

aws s3 cp "$BACKUP_DIR/${DB_NAME}-${DATE}.dump.gz.gpg" "$BUCKET/"
aws s3 ls "$BUCKET/" | tail -n 5

Giải thích nhanh:

set -euo pipefail giúp script dừng khi có lỗi, tránh báo thành công giả.
pg_dump --format=custom cho phép restore linh hoạt bằng pg_restore.
gpg --symmetric mã hóa file trước khi rời khỏi server.
aws s3 ls in ra vài bản backup cuối để log có bằng chứng upload.

Output mẫu:

2026-05-06 19:03:11  184732901 billing-2026-05-06-1900.dump.gz.gpg
2026-05-06 19:03:14  upload: ./billing-2026-05-06-1900.dump.gz.gpg to s3://company-dr-backup/postgres/billing/

Kiểm thử restore: phần quan trọng nhất

Nếu chưa restore thử, anh chưa có backup; anh chỉ có một file hy vọng là dùng được. Mỗi tuần hoặc mỗi tháng, hãy tạo môi trường lab/staging cô lập và khôi phục từ bản backup mới nhất.

createdb billing_restore_test
aws s3 cp s3://company-dr-backup/postgres/billing/billing-2026-05-06-1900.dump.gz.gpg .
gpg --batch --yes --decrypt billing-2026-05-06-1900.dump.gz.gpg > billing.dump.gz
gunzip billing.dump.gz
pg_restore -d billing_restore_test --clean --if-exists billing.dump
psql -d billing_restore_test -c "select count(*) from invoices;"

Lệnh cuối không chỉ kiểm tra database có restore được hay không, mà còn xác nhận bảng nghiệp vụ quan trọng có dữ liệu. Với ứng dụng thật, nên có thêm smoke test HTTP:

curl -fsS https://staging.example.com/healthz
curl -fsS https://staging.example.com/api/invoices?limit=1

Lịch backup đề xuất cho production

Database quan trọng: incremental/WAL mỗi 5–15 phút, full backup mỗi ngày.
VM/volume: snapshot mỗi ngày, giữ 7–30 ngày tùy chi phí.
Object storage: bật versioning, lifecycle policy, replication khác region nếu cần.
IaC/config: lưu Git private repository, tag theo release.
Restore drill: ít nhất mỗi tháng một lần; hệ thống quan trọng nên mỗi tuần.

Lỗi thường gặp và cách troubleshooting

Backup báo thành công nhưng file rỗng

Kiểm tra exit code, kích thước file và log stderr. Với PostgreSQL, user backup thiếu quyền có thể khiến dump thiếu schema hoặc table.

ls -lh /var/backups/billing-api/
pg_restore --list billing.dump | head -n 20

Không restore được vì khác phiên bản database

Nguyên tắc an toàn: restore bằng phiên bản database bằng hoặc mới hơn phiên bản tạo dump. Ghi rõ version vào log backup:

psql --version >> /var/log/backup-version.log

Mất quyền truy cập bucket backup

Không dùng chung một IAM user toàn quyền cho production và backup. Nên có tài khoản/role riêng, MFA, quyền ghi hạn chế, và chính sách ngăn xóa trong thời gian retention.

Snapshot VM chạy được nhưng ứng dụng lỗi

Thường do IP, DNS, secret hoặc external service thay đổi. Runbook restore cần có bước cập nhật DNS, kiểm tra security group/firewall, nạp lại secret và chạy migration nếu cần.

Checklist nghiệm thu backup và restore Cloud Platform

Đã định nghĩa RPO/RTO cho từng dịch vụ.
Đã liệt kê đầy đủ database, file upload, config, secret, DNS, IaC.
Backup được mã hóa trước khi lưu ngoài server.
Có ít nhất một bản nằm khác region hoặc khác account.
Có retention policy rõ: daily/weekly/monthly.
Đã restore thử trong lab/staging và lưu log kết quả.
Có smoke test sau restore.
Runbook đủ rõ để người trực ca làm theo.

Lab thực hành cuối bài

Tạo một VM lab chạy PostgreSQL và một ứng dụng demo nhỏ.
Viết script backup database theo mẫu, đổi tên bucket và database cho phù hợp.
Đẩy bản backup lên object storage có bật versioning.
Xóa database lab, restore sang database mới.
Ghi lại thời gian restore thực tế để ước lượng RTO.
Thêm cron chạy backup hằng ngày và log ra /var/log/app-backup.log.

Kết luận: backup và restore Cloud Platform tốt không nằm ở số lượng snapshot, mà nằm ở khả năng khôi phục có kiểm chứng. Hãy bắt đầu từ một dịch vụ quan trọng nhất, viết runbook ngắn, restore thử, rồi mở rộng dần sang toàn bộ nền tảng.

Tác giả: Mạnh Hoàng

Để lại một bình luận Hủy