Backup của bạn chạy đều mỗi ngày. Snapshot lên lịch tự động, dung lượng lưu trữ luôn dư dả. Nhưng thử đặt câu hỏi: nếu sự cố xảy ra lúc 2 giờ sáng, hệ thống của bạn cần bao lâu để hoạt động trở lại? Với phần lớn doanh nghiệp đang vận hành hệ thống trọng yếu trên cloud, câu trả lời thường là một khoảng lặng.
Đó chính là khoảng trống giữa "có backup" và "có Disaster Recovery". Rất nhiều tổ chức đầu tư nghiêm túc vào backup, nhưng chưa từng kiểm chứng khả năng phục hồi thực sự của mình.
Backup và Disaster Recovery: hai bài toán khác nhau
Backup bảo vệ dữ liệu. Disaster Recovery (DR) bảo vệ khả năng vận hành liên tục của hệ thống sau sự cố.
Hai khái niệm này thường bị gộp chung, nhưng phạm vi hoàn toàn khác nhau. Backup tạo ra bản sao dữ liệu. DR đảm bảo toàn bộ hệ thống, bao gồm ứng dụng, máy chủ, cấu hình mạng, cơ sở dữ liệu để khôi phục đúng và chạy lại đúng thứ tự phụ thuộc. Sự nhầm lẫn này phổ biến vì ba lý do: snapshot cloud trông giống một giải pháp DR hoàn chỉnh, các nhà cung cấp dùng thuật ngữ chồng chéo nhau, và ít doanh nghiệp thực sự kiểm thử quy trình phục hồi trước khi sự cố xảy ra.
Hậu quả chỉ lộ ra đúng lúc bạn cần nó nhất: mở snapshot nhưng không có quyền IAM để restore; restore xong dữ liệu nhưng thiếu secret key nên ứng dụng không khởi động được; khôi phục nhầm region khiến các thành phần hệ thống không kết nối được với nhau. Đây không phải rủi ro lý thuyết, đây là những lỗi lặp lại nhiều nhất trong các sự cố thực tế.
Câu hỏi cần đặt ra ngay hôm nay, không phải khi sự cố xảy ra: "Nếu một sự cố lớn xảy ra ngay lúc này, hệ thống cần bao lâu để hoạt động trở lại? Và bạn chấp nhận mất tối đa bao nhiêu dữ liệu?"
Đọc thêm: Đâu là sự khác biệt giữa Snapshot, Backup và Replication?
RPO và RTO: lượng hóa mức độ "quan trọng"
RPO (Recovery Point Objective) là khoảng dữ liệu tối đa bạn chấp nhận mất. RTO (Recovery Time Objective) là thời gian tối đa hệ thống được phép ngừng hoạt động trước khi khôi phục hoàn tất.
Đây là hai chỉ số vận hành, không phải khái niệm trừu tượng và chúng phải được định nghĩa theo từng workload, không áp dụng một con số chung cho toàn hệ thống:
- Transaction database, hệ thống thanh toán, core banking: RPO dưới 15 phút, RTO dưới 1 giờ
- POS, CRM, ERP bán lẻ: RPO 15–60 phút, RTO 2–4 giờ
- Telesales/call center, hệ thống CRM vận hành: RPO 1–4 giờ, RTO 4–8 giờ
- Hệ thống file, LMS, báo cáo nội bộ: RPO 4–24 giờ, RTO 8–24 giờ
Định nghĩa mục tiêu chỉ là bước đầu. Bước tiếp theo và cũng là bước hay bị bỏ qua nhất là kiểm thử định kỳ để chứng minh con số đó là thật. Một RPO "15 phút" chưa từng được test không khác gì một con số không tồn tại.
Thiết kế kiến trúc: từ snapshot đến failover thực sự
Có 4 mô hình DR phổ biến, chi phí và mức độ tự động hóa tăng dần theo thứ tự:
- Backup + restore: lưu backup định kỳ, restore thủ công khi cần. Triển khai đơn giản, chi phí thấp, nhưng RTO cao — từ vài giờ đến vài ngày.
- Snapshot-based: tạo snapshot VM/database với tần suất cao hơn. RPO tốt hơn, nhưng restore vẫn cần can thiệp thủ công.
- Pilot light / warm standby: duy trì môi trường phụ ở trạng thái tắt hoặc chạy tối thiểu, sẵn sàng kích hoạt khi cần. RTO từ vài chục phút đến vài giờ.
- Active-passive / active-active: hai môi trường chạy song song, failover gần như tức thì. Chi phí cao nhất, nhưng RTO có thể dưới 5 phút.
Bất kể chọn mô hình nào, kiến trúc cần đảm bảo đủ bốn yếu tố: backup vault tách biệt hoàn toàn khỏi môi trường production, cơ chế immutable/lock, mã hóa end-to-end, và phân quyền chặt để không ai có quyền xóa backup ngoại trừ trường hợp đặc biệt có audit log đầy đủ. Object storage là lựa chọn phổ biến cho backup vault nhờ chi phí thấp, dung lượng linh hoạt và khả năng bật chế độ immutable.
Nếu hệ thống của bạn phải đảm bảo data sovereignty tại Việt Nam, vùng lưu trữ backup cũng phải nằm trong nước, không thể tùy tiện replication ra nước ngoài mà chưa kiểm tra quy định.
Về cross-region: đây là lớp bảo vệ cho rủi ro cả một data center bị ảnh hưởng bởi thiên tai, mất điện diện rộng, sự cố mạng khu vực. Nếu hệ thống chính đặt tại Hà Nội, backup cross-region về TP.HCM là mức tối thiểu nên có.
Chống ransomware: đừng để backup cũng bị mã hóa
Ransomware hiện đại không chỉ tấn công dữ liệu production. Chúng nhắm trực tiếp vào backup để xóa hoặc mã hóa, triệt tiêu luôn phương án khôi phục của bạn. Theo CNiC Solutions, các tổ chức có backup nguyên vẹn phục hồi trong vòng một tuần ở mức 46% trường hợp, so với tỷ lệ tổng thể năm 2025 là 53% phục hồi hoàn toàn trong một tuần — tăng từ 35% năm 2024. Sự khác biệt nằm ở đúng một điểm: backup còn dùng được hay không.
Hai cơ chế then chốt cần nắm:
- Immutable backup (WORM/lock retention): một khi đã ghi, không ai sửa hoặc xóa được trong thời gian retention đã set. Phù hợp cho phần lớn trường hợp và dễ triển khai trên cloud.
- Air-gap backup: bản sao tách biệt hoàn toàn về mặt mạng khỏi môi trường chính, không thể truy cập bằng credential hoặc kênh đã bị tấn công. NIST SP 800-209 (IS-SS-R8) khuyến nghị cân nhắc air-gap cho các hệ thống có yêu cầu khôi phục sau tấn công mạng.
Khung tham chiếu 3-2-1-1-0 là điểm khởi đầu đáng tin cậy: 3 bản sao, trên 2 loại media khác nhau, 1 bản off-site, 1 bản immutable hoặc air-gap, và 0 lỗi khi test restore. Vế cuối — "0 lỗi khi test" — là phần bị bỏ qua nhiều nhất, và cũng là phần quan trọng nhất.
DR runbook và lịch kiểm thử: chứng minh khả năng phục hồi
Runbook DR không phải tài liệu để lưu trữ. Đây là kịch bản thao tác từng bước — ai làm gì, theo thứ tự nào — được viết ra để dùng khi hệ thống đang trong khủng hoảng thực sự.
Một bài DR test đạt chuẩn cần kiểm tra tối thiểu ba điều: restore đúng version dữ liệu, hệ thống khởi động lại đúng thứ tự phụ thuộc (dependency), và xác thực tính toàn vẹn dữ liệu sau restore — không chỉ dừng ở "hệ thống có lên được hay không".
Lịch kiểm thử gợi ý:
| Loại test | Tần suất | Đối tượng |
|---|---|---|
| Tabletop walkthrough | Hàng quý | Toàn bộ team vận hành |
| Restore kỹ thuật (partial) | Hàng tháng | DB, file, VM theo rotation |
| Full DR drill | 6 tháng/lần | Workload tier 1 |
Những lỗi phổ biến nhất khi test: restore nhầm region, thiếu quyền IAM, thiếu secret hoặc key vault không mount được, dữ liệu inconsistent giữa DB và storage, cấu hình môi trường không khớp. Mỗi lần test cần được ghi log đầy đủ, bao gồm RTO/RPO thực tế đo được — đây là bằng chứng duy nhất có giá trị, cả với nội bộ và với auditor.
Với hệ thống như PostgreSQL trên Kubernetes, quy trình failover và restore cần được kiểm thử riêng do các đặc thù về leader election và state consistency.
TCO backup/DR: đừng chỉ nhìn vào giá lưu trữ
Giá lưu trữ là phần dễ nhìn thấy nhất trong bài toán chi phí, nhưng hiếm khi là phần lớn nhất. Ba cấu phần thường bị bỏ sót:
- Data egress/replication: chi phí truyền dữ liệu giữa các vùng hoặc ra ngoài, thường tính theo GB.
- Chi phí vận hành và test: thời gian kỹ sư chạy DR drill, duy trì môi trường warm standby, xử lý alert.
- Chi phí downtime: một giờ ngừng hệ thống POS của một chuỗi bán lẻ 300 cửa hàng có thể tương đương hàng trăm triệu đồng doanh thu mất đi.
Minh họa nhanh theo 3 kịch bản RPO:
| Kịch bản | RPO mục tiêu | RTO mục tiêu | Chi phí tương đối |
|---|---|---|---|
| Cơ bản | 24 giờ | 8 giờ | Thấp nhất |
| Trung bình | 4 giờ | 2 giờ | Trung bình (thêm replication) |
| Cao | 15 phút | 30 phút | Cao (warm standby + cross-region) |
Ba bẫy chi phí phổ biến nhất: giữ retention quá dài mà không rà soát lại, không bật deduplication trên backup vault, và không dự báo tốc độ tăng trưởng dữ liệu — dẫn đến bội chi bất ngờ sau 6 tháng. Tham khảo bảng giá cloud để tính toán cụ thể theo dung lượng thực tế của hệ thống.
Tiêu chí chọn nhà cung cấp backup/DR tại Việt Nam và Thái Lan
Bốn nhóm tiêu chí cần đánh giá khi vận hành hệ thống tại khu vực Đông Nam Á:
Kỹ thuật: hỗ trợ những loại workload nào (VM, database, Kubernetes, file), có snapshot tích hợp sẵn với managed database không, cơ chế immutable/lock có sẵn trên backup vault không, mã hóa end-to-end và quản lý khóa có tách biệt không.
Vận hành: SLA khôi phục được cam kết rõ ràng, có hỗ trợ 24/7 từ đội kỹ thuật địa phương không, có kinh nghiệm đồng hành cùng khách hàng trong DR drill không.
Khu vực: có availability zone tại Việt Nam (Hà Nội, TP.HCM) và Thái Lan để triển khai cross-region trong khu vực, độ trễ thấp khi thao tác restore lúc sự cố.
Tuân thủ và bảo mật: phân quyền chi tiết kèm audit log, đảm bảo data sovereignty, dữ liệu không rời lãnh thổ, có các chứng nhận bảo mật được kiểm chứng độc lập.
GreenNode đáp ứng đầy đủ các tiêu chí này với 6 availability zone trải rộng tại Hà Nội, TP.HCM và Bangkok, cùng vBackup cho bảo vệ dữ liệu và khôi phục sau sự cố, vận hành 24/7 bởi đội chuyên gia địa phương. Với doanh nghiệp cần hạ tầng riêng cho workload vận hành tại Việt Nam, đây là điểm khác biệt thực chất so với các provider đặt hạ tầng tại Singapore hay xa hơn.
Checklist triển khai trong 30 ngày
Nếu bạn chưa có chiến lược backup/DR rõ ràng, đây là lộ trình thực tế theo tuần:
Tuần 1: kiểm kê toàn bộ workload, thực hiện Business Impact Analysis (BIA) sơ bộ, chốt RPO/RTO mục tiêu cho từng tier.
Tuần 2: thiết kế kiến trúc backup vault, cấu hình replication, phân quyền theo nguyên tắc least privilege, bật mã hóa và immutable lock.
Tuần 3: triển khai backup policy cho từng workload, xây dựng restore plan và runbook DR cho tối thiểu một workload tier 1.
Tuần 4: chạy pilot DR drill quy mô nhỏ (restore 1 DB + 1 VM vào môi trường test), đo RTO/RPO thực tế, tổng hợp gap và lên kế hoạch mở rộng.
30 ngày không giải quyết hết mọi vấn đề, nhưng đủ để bạn biết chính xác vị trí hiện tại của mình và có bằng chứng đầu tiên về khả năng phục hồi thực sự.
Câu hỏi thường gặp
Backup snapshot có thay thế được DR không?
Không. Snapshot giúp lấy lại dữ liệu tại một điểm thời gian, nhưng không tự động khôi phục toàn bộ hệ thống. Bạn vẫn cần runbook, đúng thứ tự khởi động, và phân quyền đầy đủ để hệ thống vận hành trở lại.
Bị ransomware tấn công có khôi phục được từ backup không?
Có, nếu backup được lưu immutable hoặc air-gap và chưa bị xâm phạm. Nếu backup dùng chung credential với production hoặc không có lock retention, kẻ tấn công có thể xóa hoặc mã hóa backup trước khi bạn phát hiện sự cố.
Cross-region cần triển khai ở mức nào để đạt RTO mong muốn?
Phụ thuộc vào mô hình DR. Với backup + restore cross-region, RTO thường ở mức 4–12 giờ. Với warm standby cross-region, RTO có thể xuống 30–60 phút. Chỉ active-active cross-region mới đạt RTO dưới 5 phút, đi kèm chi phí tăng đáng kể.
Làm sao chứng minh RTO/RPO thực tế của hệ thống?
Chạy DR drill và đo thời gian thực tế. Ghi log đầy đủ: thời điểm bắt đầu restore, thời điểm hệ thống chạy lại, thời điểm xác thực dữ liệu hoàn tất. Đây là bằng chứng duy nhất có giá trị, với cả team nội bộ và auditor bên ngoài.
Nên giữ immutable/air-gap bao lâu? Có ảnh hưởng đến chi phí không?
30–90 ngày cho immutable backup là đủ cho phần lớn trường hợp, đủ thời gian để phát hiện ransomware ủ bệnh chưa kích hoạt. Giữ lâu hơn làm tăng chi phí lưu trữ. Air-gap phát sinh thêm chi phí vận hành cho bản sao tách biệt. Cân bằng giữa retention period và ngân sách là bài toán cần rà soát định kỳ, không phải quyết định một lần.
Bắt đầu từ đâu?
Ba bước thực tế để chuyển từ "có backup" sang "chứng minh phục hồi được":
- Chốt RPO/RTO theo từng workload cụ thể, không dùng một con số chung cho toàn hệ thống.
- Thiết kế kiến trúc có immutable/lock, cross-region nếu cần, và tách biệt kho backup khỏi credential production.
- Chạy DR test đầu tiên, đo thời gian thực tế và ghi lại toàn bộ gap.
Nếu bạn đang vận hành hệ thống trọng yếu như POS, CRM, ERP, core banking hay call center tại Việt Nam hoặc Thái Lan và cần tư vấn kiến trúc backup/DR phù hợp với workload thực tế, liên hệ đội ngũ GreenNode để đặt lịch review hạ tầng.
