Cloud backup strategy không chỉ là bật một dịch vụ backup rồi hy vọng mọi thứ ổn. Trong môi trường production, chiến lược sao lưu phải trả lời được ba câu hỏi rất thực tế: mất bao nhiêu dữ liệu là chấp nhận được, mất bao lâu để khôi phục dịch vụ, và làm sao chứng minh bản backup có thể restore khi sự cố thật xảy ra.
Bài này đi theo góc nhìn SysAdmin/DevOps đang vận hành hệ thống web, database và file storage trên cloud. Em dùng ví dụ gần với AWS, nhưng nguyên tắc áp dụng được cho Google Cloud, Azure, DigitalOcean hoặc hạ tầng hybrid. Tài liệu chính thống nên đọc thêm là AWS Backup documentation và Google Cloud disaster recovery scenarios.
Cloud backup strategy bắt đầu từ RPO và RTO
Trước khi chọn công cụ, hãy xác định hai chỉ số:
- RPO (Recovery Point Objective): được phép mất tối đa bao nhiêu dữ liệu. Ví dụ RPO 15 phút nghĩa là khi sự cố xảy ra, dữ liệu restore không được cũ hơn 15 phút.
- RTO (Recovery Time Objective): thời gian tối đa để dịch vụ hoạt động lại. Ví dụ RTO 1 giờ nghĩa là từ lúc phát hiện lỗi đến khi người dùng truy cập lại được không quá 1 giờ.
Nếu chưa có RPO/RTO, đội vận hành thường backup theo cảm tính: database mỗi ngày một lần, file mỗi tuần một lần, snapshot khi nhớ ra. Cách đó rẻ lúc bình thường nhưng rất đắt khi cần khôi phục.
Mô hình 3-2-1 cho cloud backup strategy
Quy tắc 3-2-1 vẫn rất đáng dùng trong cloud:
- 3 bản dữ liệu: dữ liệu production + ít nhất 2 bản backup.
- 2 loại lưu trữ khác nhau: ví dụ snapshot volume và object storage.
- 1 bản offsite hoặc tách tài khoản: bản backup ở region khác hoặc account/project khác.
Điểm quan trọng là tách quyền. Nếu attacker chiếm được tài khoản production và có quyền xóa backup, backup đó không còn là backup. Với cloud, nên dùng account riêng cho backup vault, bật MFA delete hoặc retention lock nếu nền tảng hỗ trợ.
Thiết kế lớp backup cho workload production
Database: dump logic và snapshot vật lý
Database cần hai lớp backup. Snapshot giúp restore nhanh cả volume hoặc managed database. Dump logic giúp khôi phục một bảng, kiểm tra dữ liệu và migrate khi cần.
# PostgreSQL: tạo dump dạng custom để restore linh hoạt
export PGPASSWORD='***'
pg_dump -h db.example.internal -U app_user -d app_prod -F c -Z 6 -f /backup/app_prod_$(date +%F_%H%M).dump
# Kiểm tra file dump có đọc được không
pg_restore -l /backup/app_prod_2026-05-10_1900.dump | head
Output mẫu của pg_restore -l nên thấy danh sách schema, table, index. Nếu lệnh báo “input file does not appear to be a valid archive”, file backup hỏng hoặc dump chưa hoàn tất.
File upload và object storage
Với thư mục upload của WordPress, ứng dụng nội bộ hoặc tài liệu người dùng, nên đồng bộ sang object storage có versioning.
# Ví dụ đồng bộ thư mục upload lên S3-compatible bucket
aws s3 sync /var/www/app/uploads s3://company-backup-prod/uploads/ --storage-class STANDARD_IA --delete
# Xem nhanh số object sau khi sync
aws s3 ls s3://company-backup-prod/uploads/ --recursive --summarize | tail
Cẩn thận với --delete: nếu thư mục nguồn bị mã hóa bởi ransomware, lần sync tiếp theo có thể xóa bản lành trên bucket. Vì vậy bucket cần bật versioning và lifecycle giữ version cũ đủ lâu.
Server và volume snapshot
Snapshot volume phù hợp cho restore nhanh VM hoặc block storage. Nhưng snapshot không thay thế backup ứng dụng. Nếu snapshot được tạo khi database đang ghi mạnh, cần đảm bảo consistency bằng pre-freeze hook, managed backup hoặc snapshot-aware tool.
Lịch backup mẫu cho môi trường vừa và nhỏ
| Thành phần | Tần suất | Lưu giữ | Mục tiêu |
|---|---|---|---|
| Database snapshot | Mỗi 1 giờ | 7 ngày | Restore nhanh toàn DB |
| Database logical dump | Mỗi ngày | 30 ngày | Restore bảng/schema, kiểm tra dữ liệu |
| Upload/object | Mỗi 15 phút hoặc realtime | 30-90 ngày version | Giảm mất file người dùng |
| Config/IaC | Mỗi commit | Theo Git history | Dựng lại hạ tầng |
| Cross-region copy | Mỗi ngày | 14-30 ngày | DR khi mất region/account |
Script kiểm tra backup tự động
Một cloud backup strategy tốt phải có kiểm tra tự động. Ít nhất hãy verify file tồn tại, kích thước hợp lý, checksum và khả năng restore vào môi trường lab.
#!/usr/bin/env bash
set -euo pipefail
BACKUP_FILE="$1"
MIN_SIZE_MB=100
SIZE_MB=$(du -m "$BACKUP_FILE" | awk '{print $1}')
if [ "$SIZE_MB" -lt "$MIN_SIZE_MB" ]; then
echo "CRITICAL: backup too small: $SIZE_MB MB"
exit 2
fi
sha256sum "$BACKUP_FILE" > "$BACKUP_FILE.sha256"
pg_restore -l "$BACKUP_FILE" > /tmp/restore-list.txt
echo "OK: backup looks valid, size=${SIZE_MB}MB"
Đưa script này vào cron hoặc CI job, gửi alert về email/Slack/Telegram khi exit code khác 0. Đừng chỉ lưu log cục bộ trên chính server cần backup.
Diễn tập restore trong lab
Nhiều đội có backup nhưng chưa từng restore. Khi sự cố thật xảy ra, họ mới phát hiện thiếu quyền IAM, thiếu encryption key, snapshot nằm sai region hoặc bản dump không tương thích version database.
- Tạo môi trường lab tách khỏi production.
- Restore database từ dump gần nhất.
- Restore thư mục upload hoặc bucket bản sao.
- Chạy migration nếu ứng dụng yêu cầu.
- Smoke test các luồng quan trọng: login, tạo dữ liệu, đọc dữ liệu cũ, upload file.
- Ghi lại thời gian restore thực tế để so với RTO.
Lỗi thường gặp khi triển khai cloud backup strategy
Backup cùng account với production
Nếu production bị compromise, attacker có thể xóa cả backup. Cách tốt hơn là dùng backup account riêng, quyền ghi một chiều, retention lock và audit log.
Không backup encryption key
Backup đã mã hóa nhưng mất KMS key hoặc secret thì cũng không restore được. Cần quy trình bảo vệ key, rotation và break-glass access.
Không giám sát job backup
Job backup fail âm thầm trong 2 tuần là kịch bản rất phổ biến. Cần alert khi backup không chạy, backup quá nhỏ, backup quá cũ hoặc copy cross-region bị lỗi.
Chỉ restore toàn hệ thống, không restore từng phần
Thực tế nhiều sự cố chỉ cần khôi phục một bảng, một thư mục hoặc một object. Hãy thiết kế backup để restore granular khi cần.
Troubleshooting nhanh
- Backup database quá chậm: kiểm tra I/O, dùng replica để dump, tăng compression hợp lý, chia lịch ngoài giờ cao điểm.
- Restore lỗi version: giữ tool restore cùng major version với database, kiểm tra compatibility trước.
- Chi phí storage tăng: cấu hình lifecycle, chuyển bản cũ sang cold storage, xóa backup trùng lặp nhưng không phá retention tối thiểu.
- Không thấy file mới trong bucket: kiểm tra quyền IAM, clock skew, prefix sync và log của agent.
Checklist nghiệm thu
- Đã định nghĩa RPO/RTO cho từng workload.
- Backup database có cả snapshot và logical dump.
- Object storage bật versioning/lifecycle.
- Backup quan trọng được copy cross-region hoặc cross-account.
- Retention lock hoặc chính sách chống xóa nhầm đã bật nếu có.
- Monitoring cảnh báo khi backup fail/quá cũ/quá nhỏ.
- Đã restore thử trong lab và ghi nhận thời gian thực tế.
- Runbook restore được lưu trong Git/wiki nội bộ.
Bài tập lab
Dựng một VM nhỏ chạy PostgreSQL và một thư mục upload giả lập. Viết job backup hằng ngày gồm pg_dump, tar thư mục upload, tính checksum, upload lên S3-compatible bucket. Sau đó tạo VM lab mới và restore toàn bộ. Mục tiêu: chứng minh dữ liệu đọc được, ứng dụng kết nối được, và thời gian restore dưới RTO tự đặt ra.
Kết luận: backup không phải việc phụ. Với production, cloud backup strategy là một phần của thiết kế độ tin cậy. Nếu chưa kiểm thử restore, hãy xem backup đó là “chưa được chứng minh”. Bắt đầu từ RPO/RTO, tách quyền, bật versioning, giám sát job và diễn tập restore định kỳ.
