Mở đầu — vì sao bài này quan trọng
Có một câu nói cay đắng trong giới vận hành hệ thống: "Không có ai thực sự quan tâm đến backup, họ chỉ quan tâm đến restore." Nghe qua thì buồn cười, nhưng nó phản ánh đúng một sự thật đau lòng mà rất nhiều đội ngũ kỹ thuật ở Việt Nam đã phải trả giá: họ cấu hình sao lưu đầy đủ, để cron chạy đều đặn mỗi đêm, dashboard báo "backup thành công" suốt hai năm — nhưng đến ngày dữ liệu thật sự mất, mở file backup ra thì nó rỗng, hoặc hỏng, hoặc đã bị mã hóa cùng với dữ liệu gốc bởi ransomware.
Trong thời đại cloud, nhiều bạn kỹ sư trẻ có một niềm tin nguy hiểm: "Dữ liệu đã lên AWS/GCP rồi thì an toàn tuyệt đối, đâu cần backup nữa." Đây là hiểu lầm chết người. Cloud provider cam kết độ bền (durability) của hạ tầng — ví dụ S3 có độ bền 99.999999999% (11 số 9) — nhưng đó là cam kết rằng ổ đĩa của họ không hỏng, chứ không phải cam kết bảo vệ bạn khỏi chính bạn. Nếu một kỹ sư gõ nhầm lệnh terraform destroy, nếu một tài khoản bị hack, nếu một đoạn code bug ghi đè toàn bộ bảng khách hàng, hay nếu một nhân viên bất mãn cố tình xóa dữ liệu — thì độ bền 11 số 9 chẳng cứu được bạn. Cloud hoạt động theo mô hình trách nhiệm chia sẻ (shared responsibility): provider lo hạ tầng, còn bảo vệ dữ liệu của bạn là việc của bạn.
Bài học này sẽ trang bị cho bạn một khung tư duy vững chắc để xây dựng chiến lược backup và restore trên cloud, khởi đầu từ nguyên tắc kinh điển 3-2-1 và cách nó được "phiên dịch" sang ngôn ngữ đám mây. Đây là kỹ năng nền tảng của bất kỳ ai làm DevOps hay SRE nghiêm túc.
Khái niệm cốt lõi
Nguyên tắc 3-2-1 — xương sống của mọi chiến lược backup
Quy tắc 3-2-1 ra đời từ nhiếp ảnh gia Peter Krogh và đã trở thành chuẩn mực toàn ngành. Nó nói rằng bạn nên có:
- 3 bản sao dữ liệu (1 bản gốc đang dùng + 2 bản backup).
- 2 loại phương tiện lưu trữ khác nhau (different storage types).
- 1 bản đặt ở nơi khác về mặt địa lý (off-site).
Phiên bản cloud của quy tắc 3-2-1
Trên đám mây, "loại phương tiện" và "off-site" mang ý nghĩa hơi khác so với thời còn ổ cứng vật lý và băng từ. Cách diễn giải thực dụng nhất là:
- 3 bản sao: dữ liệu production + snapshot/backup gần đây + bản lưu trữ dài hạn.
- 2 storage class khác nhau: ví dụ dữ liệu nóng nằm trên block storage (EBS), còn backup nằm trên object storage (S3 Standard), và bản archive nằm trên S3 Glacier. Việc dùng nhiều lớp lưu trữ khác cơ chế giúp giảm rủi ro một lỗi hệ thống chung.
- 1 region khác: đây chính là "off-site" của kỷ nguyên cloud. Bản backup phải được cross-region replication sang một region khác (ví dụ từ Singapore
ap-southeast-1sang Tokyoap-northeast-1), để nếu cả một region gặp thảm họa, bạn vẫn còn dữ liệu.
Các loại backup: full, incremental, differential
Bạn cần phân biệt ba kiểu để tối ưu chi phí và tốc độ:
- Full backup: sao chép toàn bộ dữ liệu mỗi lần. An toàn nhất, khôi phục nhanh nhất, nhưng tốn dung lượng và thời gian nhất.
- Incremental backup: chỉ sao chép phần thay đổi kể từ lần backup gần nhất (dù full hay incremental). Tiết kiệm nhất, nhưng khi khôi phục phải ghép nối cả chuỗi, chậm và dễ đứt gãy nếu một mắt xích hỏng.
- Differential backup: chỉ sao chép phần thay đổi kể từ lần full gần nhất. Nằm ở giữa hai loại trên.
Immutability và WORM — lá chắn chống ransomware
Ransomware hiện đại rất tinh vi: sau khi xâm nhập, chúng thường tìm và xóa/mã hóa cả bản backup trước khi ra tay với dữ liệu chính, để nạn nhân không còn đường lui và buộc phải trả tiền chuộc. Vì thế backup phải immutable — không ai, kể cả tài khoản admin, được phép sửa hay xóa trong một khoảng thời gian nhất định. AWS gọi cơ chế này là S3 Object Lock (chế độ WORM — Write Once Read Many); GCP có Bucket Lock; Azure có Immutable Blob Storage. Đây là ranh giới giữa một chiến lược backup "cho có" và một chiến lược thực sự cứu được doanh nghiệp.
RPO và RTO — hai con số quyết định thiết kế
Dù bài 32 đã đi sâu về Disaster Recovery, bạn vẫn cần nắm hai chỉ số này ở góc độ backup:
- RPO (Recovery Point Objective): bạn chấp nhận mất bao nhiêu dữ liệu (tính bằng thời gian). RPO 1 giờ nghĩa là backup phải chạy ít nhất mỗi giờ.
- RTO (Recovery Time Objective): bạn cần khôi phục xong trong bao lâu.
Tình huống thực tế
Tình huống 1 — Sàn thương mại điện tử ở TP.HCM và cú xóa nhầm database
Một công ty thương mại điện tử tầm trung tại TP.HCM (gọi là "ShopViet") chạy toàn bộ hệ thống trên AWS region Singapore. Database chính là RDS MySQL chứa 8 triệu đơn hàng. Một tối thứ Sáu, một kỹ sư mới vào chạy script dọn dữ liệu test trên môi trường staging, nhưng do biến môi trường bị cấu hình sai, script kết nối nhầm vào production và chạy DELETE không có mệnh đề WHERE đúng — xóa mất bảng order_items của hai tháng gần nhất.
May mắn là ShopViet đã bật RDS Automated Backups với retention 7 ngày và Point-in-Time Recovery (PITR). Đội SRE khôi phục database về đúng thời điểm 3 phút trước khi script chạy, tạo một instance mới từ bản khôi phục, đối chiếu dữ liệu, rồi chuyển traffic sang. Tổng thời gian downtime khoảng 40 phút, gần như không mất đơn hàng nào.
Bài học rút ra: PITR là "cỗ máy thời gian" quý giá cho database quan hệ, nhưng nó chỉ hoạt động nếu bạn đã bật trước sự cố. Ngoài ra, thảm họa lần này bắt nguồn từ việc staging và production dùng chung dây nối — nguyên nhân gốc là thiếu tách biệt môi trường, không chỉ là thiếu backup.
Tình huống 2 — Startup fintech và bài học immutability
Một startup fintech ở Hà Nội lưu log giao dịch và tài liệu KYC trên S3. Họ tự tin vì đã bật versioning và cross-region replication sang Tokyo. Nhưng một ngày, credential của một service account bị lộ qua một repo GitHub public. Kẻ tấn công dùng credential đó, và vì service account có quyền quá rộng, chúng chạy lệnh xóa hàng loạt kèm xóa cả các version cũ trong bucket. Cross-region replication vô tình nhân bản luôn thao tác xóa sang Tokyo.
Rất may, đội bảo mật đã bật S3 Object Lock ở chế độ Compliance cho bucket chứa tài liệu KYC với thời hạn giữ 90 ngày — nghĩa là trong 90 ngày, không một ai xóa được, kể cả root account. Nhờ đó toàn bộ hồ sơ KYC được giữ nguyên vẹn, đáp ứng cả yêu cầu pháp lý về lưu trữ. Phần log giao dịch không được Object Lock thì mất một phần và họ phải dựng lại từ nguồn thứ cấp.
Bài học rút ra: Versioning và replication không phải là chống ransomware/xóa độc hại — chúng nhân bản cả hành vi phá hoại. Chỉ immutability (Object Lock/WORM) mới là lá chắn thật sự. Và replication không thay thế backup, vì nó đồng bộ mọi thay đổi, bao gồm cả những thay đổi sai.
Tình huống 3 — Doanh nghiệp giáo dục và backup không bao giờ khôi phục được
Một nền tảng học trực tuyến chạy trên GCP có nhu cầu tuân thủ nội bộ nên cấu hình backup rất đầy đủ: snapshot Persistent Disk hằng đêm, export Cloud SQL sang Cloud Storage, retention 30 ngày. Dashboard xanh suốt một năm. Rồi một sự cố hỏng dữ liệu buộc họ phải khôi phục — và họ phát hiện file export Cloud SQL bị lỗi encoding do một thay đổi charset từ nhiều tháng trước, khôi phục lên là hỏng ký tự tiếng Việt hàng loạt. Không ai từng thử restore, nên không ai biết.
Bài học rút ra: Một backup chưa từng được kiểm tra khôi phục thì chỉ là hy vọng, không phải bảo hiểm. Con số "0" trong 3-2-1-1-0 (0 lỗi khi verify) chính là để tránh cái bẫy này. Hãy lên lịch restore drill định kỳ.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để thiết lập một chiến lược backup 3-2-1 trên cloud, minh họa theo AWS nhưng tư duy áp dụng được cho GCP và Azure.
Bước 1 — Phân loại dữ liệu và xác định RPO/RTO. Lập bảng kê từng loại dữ liệu (database giao dịch, file người dùng, log, cấu hình hạ tầng). Với mỗi loại, hỏi: mất bao nhiêu là chấp nhận được (RPO)? Cần khôi phục nhanh cỡ nào (RTO)? Database thanh toán có thể cần RPO vài phút, còn log truy cập có thể chấp nhận RPO 24 giờ. Đừng đối xử mọi dữ liệu như nhau — sẽ vừa lãng phí vừa thiếu chỗ cần.
Bước 2 — Bật backup gốc cho từng dịch vụ. Với database, bật Automated Backups + Point-in-Time Recovery (RDS, Cloud SQL). Với block storage, lên lịch snapshot tự động (AWS Data Lifecycle Manager hoặc AWS Backup, GCP snapshot schedule). Với object storage, bật versioning.
Bước 3 — Dùng một dịch vụ backup tập trung. Thay vì mỗi dịch vụ một kiểu, hãy dùng AWS Backup (hoặc tương đương) để quản lý policy tập trung: định nghĩa backup plan với tần suất, retention, và vault đích cho cả EC2, EBS, RDS, DynamoDB, EFS trong một chỗ. Việc này giảm sai sót và dễ audit.
Bước 4 — Thiết lập lớp thứ hai và off-site (2 và 1). Cấu hình cross-region backup: copy backup vault sang một region khác. Đồng thời chuyển bản cũ sang storage class rẻ hơn (S3 Glacier / Archive) qua lifecycle policy để đạt "2 loại storage" và tối ưu chi phí.
Bước 5 — Bật immutability. Với vault chứa backup quan trọng, bật AWS Backup Vault Lock (hoặc S3 Object Lock cho bucket backup) để chống xóa. Chọn thời hạn giữ phù hợp yêu cầu tuân thủ.
Bước 6 — Tách biệt tài khoản (account isolation). Đặt backup vault ở một AWS account riêng mà tài khoản production không có quyền xóa. Đây là chốt chặn cuối: kể cả khi account production bị chiếm, kẻ tấn công không chạm được vào backup.
Bước 7 — Giám sát và cảnh báo. Cấu hình alert khi một job backup thất bại. "Không có tin gì" không đồng nghĩa "mọi thứ ổn" — phải chủ động báo khi backup fail.
Bước 8 — Lên lịch restore drill. Định kỳ (ví dụ hằng quý) khôi phục thử vào môi trường cách ly, kiểm tra dữ liệu toàn vẹn, đo thời gian thực tế so với RTO cam kết. Ghi lại kết quả.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi replication là backup. Đây là lỗi phổ biến nhất. Replication (nhân bản đồng bộ/bất đồng bộ) chống được sự cố phần cứng và mất region, nhưng nó nhân bản cả thao tác xóa nhầm và mã hóa độc hại gần như tức thì. Backup có độ trễ và có lịch sử version — đó mới là thứ cho bạn quay ngược thời gian.
Lỗi 2 — Không kiểm tra khôi phục. Như tình huống 3 đã cho thấy, backup không verify là backup ảo. Mẹo: tự động hóa một restore test nhẹ hằng tuần (ví dụ restore một bảng nhỏ và chạy checksum).
Lỗi 3 — Backup cùng chỗ, cùng account, cùng credential với production. Nếu backup dùng chung "chìa khóa" với dữ liệu gốc, một cú xâm nhập là mất cả hai. Hãy tách account, tách quyền, bật immutability.
Lỗi 4 — Quên backup dữ liệu "vô hình". Nhiều đội chỉ backup database mà quên: cấu hình hạ tầng (nên đưa vào IaC/Terraform và Git), secrets, cấu hình DNS, IAM policy. Khi thảm họa xảy ra, không có những thứ này thì có dữ liệu cũng chưa dựng lại được hệ thống.
Lỗi 5 — Retention không khớp yêu cầu tuân thủ. Ở Việt Nam, một số ngành (tài chính, y tế) có yêu cầu lưu trữ dữ liệu nhiều năm theo quy định pháp luật và PDPL. Đặt retention quá ngắn có thể vi phạm; quá dài lại tốn chi phí. Hãy đối chiếu với bộ phận pháp lý.
Mẹo tối ưu chi phí: Dùng lifecycle policy để tự động chuyển backup cũ xuống lớp lạnh (Glacier Deep Archive rẻ hơn Standard hàng chục lần). Nhưng nhớ: lớp lạnh có thời gian "rã đông" (retrieval) hàng giờ — đừng đặt dữ liệu cần RTO thấp vào đó.
Mẹo gắn thẻ (tagging): Gắn tag backup-policy cho mọi tài nguyên để AWS Backup tự động áp policy dựa trên tag. Tài nguyên mới tạo đúng tag sẽ tự được backup, tránh bỏ sót.
Bài tập thực hành
- Vẽ sơ đồ 3-2-1 cho hệ thống của bạn. Chọn một ứng dụng thật hoặc giả định (ví dụ blog có database MySQL + ảnh trên object storage). Liệt kê rõ: đâu là 3 bản sao, 2 loại storage class, và bản nào ở region khác. Chỉ ra chỗ nào hiện đang thiếu.
- Thiết lập backup thật. Trên tài khoản free-tier của AWS (hoặc GCP), tạo một RDS/Cloud SQL nhỏ, bật automated backup, tạo một snapshot thủ công, rồi khôi phục snapshot đó thành instance mới. Ghi lại thời gian khôi phục thực tế — đó là RTO thực nghiệm của bạn.
- Tình huống ransomware. Cho một bucket S3 chứa backup. Viết ra (hoặc cấu hình thật) các biện pháp để nếu account production bị chiếm, backup vẫn còn nguyên: Object Lock ở chế độ nào, retention bao lâu, có nên đặt ở account riêng không, và vì sao versioning một mình là chưa đủ.
- Thiết kế RPO/RTO. Cho ba loại dữ liệu: (a) database thanh toán, (b) ảnh sản phẩm, (c) log truy cập. Đề xuất RPO, RTO, tần suất backup và storage class cho từng loại, kèm lý giải về chi phí.
Tóm tắt
- Cloud cam kết độ bền hạ tầng, không cam kết bảo vệ bạn khỏi xóa nhầm, bug, hay tấn công. Backup là trách nhiệm của bạn theo mô hình shared responsibility.
- Quy tắc 3-2-1: 3 bản sao, 2 loại storage, 1 bản off-site. Phiên bản cloud: 3 bản sao, 2 storage class, 1 region khác — và nên nâng lên 3-2-1-1-0 (thêm 1 bản immutable, 0 lỗi khi verify).
- Hiểu rõ ba loại backup (full/incremental/differential) và tận dụng snapshot incremental của cloud để cân bằng chi phí và tốc độ.
- Replication không phải backup: nó nhân bản cả thao tác phá hoại. Chỉ immutability (Object Lock/WORM/Vault Lock) và tách biệt account mới thực sự chống ransomware.
- Backup chưa từng restore là backup ảo: hãy lên lịch restore drill định kỳ và cảnh báo khi job thất bại.
- Đừng quên backup dữ liệu "vô hình": cấu hình hạ tầng, secrets, IAM, DNS — và luôn khớp retention với yêu cầu tuân thủ như PDPL.