Sao lưu và khôi phục dữ liệu: RPO, RTO, quy tắc 3-2-1 và cách thử khôi phục cho doanh nghiệp vừa và nhỏ

Nhiều doanh nghiệp có bản sao lưu nhưng chưa từng khôi phục thử. Đến khi xóa nhầm dữ liệu, hỏng ổ đĩa hay dính mã độc tống tiền (ransomware), họ mới biết bản sao lưu thiếu, quá cũ hoặc mất nhiều giờ để dựng lại.

Bài này nói về RPO và RTO, quy tắc 3-2-1, bản sao lưu bất biến, khôi phục về thời điểm (PITR), dữ liệu SaaS và cách thử khôi phục. Nguồn chính là NIST, CISA, NCSC, AWS, Google Cloud, Microsoft, PostgreSQL và Supabase, đối chiếu đến ngày 21/10/2026.

Click Star đã có bài về cơ sở dữ liệu, Supabase Select và bảo vệ dữ liệu khách hàng. Bài này chỉ trả lời: khi dữ liệu mất, khôi phục được bao nhiêu và mất bao lâu.

Điểm chính

• RPO là mức mất dữ liệu tối đa chấp nhận được, RTO là thời gian ngừng tối đa chấp nhận được. Lịch sao lưu quyết định RPO, quy trình khôi phục quyết định RTO.
• Mục tiêu nên đặt theo từng hệ thống vì RTO càng ngắn càng đắt (NIST). Khung 4 mức trong bài là của Click Star, không phải số đo.
• CISA khuyến nghị quy tắc 3-2-1. Theo Sophos 2024, 94% tổ chức từng bị ransomware nói kẻ tấn công cố phá bản sao lưu, nên cần thêm bản bất biến hoặc ngoại tuyến.
• PostgreSQL khôi phục về thời điểm bằng bản gốc cộng nhật ký WAL. Trang Supabase ghi PITR có RPO xấu nhất 2 phút, nhưng Storage không nằm trong bản sao lưu.
• Với SaaS, dữ liệu vẫn là trách nhiệm của khách hàng, còn cửa sổ khôi phục gốc chỉ tính bằng ngày. Bản sao lưu chưa thử khôi phục thì chưa thể coi là có.

RPO và RTO là gì

Theo bộ thuật ngữ NIST (đọc 21/10/2026, lấy từ NIST SP 800-34 Rev. 1, công bố 2010), RPO là thời điểm dữ liệu phải được khôi phục về sau sự cố. RTO là thời gian tối đa hệ thống được ở trạng thái khôi phục trước khi hoạt động nghiệp vụ bị ảnh hưởng.

Google Cloud (cập nhật 5/7/2024) nói gần người vận hành hơn: RPO là khoảng mất dữ liệu lâu nhất chấp nhận được, RTO là thời gian ứng dụng được ngoại tuyến lâu nhất. RPO chỉ đo thời gian, không cho biết mất bao nhiêu dữ liệu.

NIST tách thêm MTD, là thời gian gián đoạn nghiệp vụ tối đa mà lãnh đạo chấp nhận. RTO thường phải ngắn hơn MTD, còn RPO không nằm trong MTD. Về chi phí, NIST mô tả điểm cân bằng: RTO càng ngắn, giải pháp càng đắt.

Tài liệu AWS về khôi phục thảm họa (không ghi ngày) nói tần suất sao lưu quyết định điểm khôi phục đạt được. Click Star suy ra: RPO do lịch sao lưu, RTO do quy trình.

Phân cấp hệ thống theo mức quan trọng

NIST mô tả bước phân tích tác động nghiệp vụ (BIA): hỏi người phụ trách từng quy trình dừng bao lâu thì thiệt hại không chịu nổi, rồi mới chọn công nghệ. CISA cũng khuyên kiểm kê dữ liệu và tinh chỉnh RPO, RTO theo nhu cầu kinh doanh.

Khung 4 mức dưới đây là của Click Star, không phải số đo và không lấy từ nguồn ngoài. Hãy chỉnh theo thiệt hại thật.

• Mức 1, lõi doanh thu (cơ sở dữ liệu đơn hàng, CRM đang bán): RPO 15 phút, RTO 4 giờ.
• Mức 2, vận hành hằng ngày (email, tài liệu chung, kế toán): RPO 24 giờ, RTO 24 giờ.
• Mức 3, hỗ trợ (website giới thiệu, dashboard): RPO 24 giờ, RTO 72 giờ.
• Mức 4, lưu trữ (hồ sơ cũ, bản nháp): RPO 7 ngày, RTO 7 ngày.

Mức gắn với dữ liệu, không gắn với phần mềm: trong 1 CRM, danh sách khách hàng là mức 1, tệp đính kèm cũ có thể là mức 3.

Quy tắc 3-2-1 và lớp bất biến chống ransomware

Theo trang Back Up Business Data của CISA (không ghi ngày, đọc 21/10/2026), quy tắc 3-2-1 là 3 bản dữ liệu quan trọng, trên 2 loại phương tiện khác nhau, với 1 bản ngoài địa điểm làm việc. CISA khuyên sao lưu tự động theo lịch, mã hóa và giữ bản ngoại tuyến.

Quy tắc này chưa đủ khi kẻ tấn công nhắm vào bản sao lưu. Theo khảo sát Sophos đặt hàng, Vanson Bourne thực hiện đầu năm 2024 với 2.974 chuyên gia ở tổ chức từng bị ransomware, 94% nói kẻ tấn công cố phá bản sao lưu và 57% lần cố gắng thành công.

Khi bản sao lưu bị phá, 67% tổ chức trả tiền chuộc (so với 36%), và chi phí khôi phục trung vị là 3 triệu USD so với 375.000 USD. Giới hạn: khảo sát do nhà cung cấp bảo mật đặt hàng, chỉ gồm tổ chức đã bị tấn công, chưa có số tương đương cho Việt Nam.

Cảnh báo AvosLocker của CISA (11/10/2023) khuyên sao lưu mã hóa và bất biến (immutable). NCSC của Anh (bài 13/8/2019, trang ghi cập nhật 28/7/2026) khuyên giữ ít nhất 1 bản ngắt kết nối; với đám mây thì dùng xác thực đa yếu tố và không để máy khách sao lưu giữ thông tin đăng nhập khi không dùng.

Tài liệu S3 Object Lock của AWS (không ghi ngày) mô tả mô hình ghi một lần, đọc nhiều lần. Ở chế độ compliance, không ai xóa được trong thời hạn giữ, kể cả tài khoản gốc; cần bật versioning.

Sao chép liên tục không thay được sao lưu. AWS nêu cách này có thể không chống được dữ liệu hỏng hay bị xóa có chủ đích nếu thiếu bản theo thời điểm, và khuyên sao lưu sang tài khoản khác để phòng tài khoản bị chiếm.

Khôi phục về thời điểm với PostgreSQL và Supabase

Theo tài liệu PostgreSQL 18 (mục 25.3, đọc 21/10/2026), PITR kết hợp 1 bản sao lưu gốc với chuỗi nhật ký ghi trước (WAL) lưu trữ liên tục, rồi phát lại WAL đến thời điểm đích. pg_dump không dùng được cho cách này, và việc khôi phục áp dụng cho cả cụm chứ không cho từng phần.

Tệp cấu hình không nằm trong WAL nên phải sao lưu riêng. Cần thử việc lưu trữ WAL trước khi tạo bản gốc đầu tiên.

Trang Database Backups của Supabase (đọc 21/10/2026, không ghi ngày cập nhật) nêu: gói Pro, Team và Enterprise có sao lưu hằng ngày, giữ 7, 14 và tối đa 30 ngày. PITR là tiện ích bổ sung, cần ít nhất compute Small, WAL tải lên khoảng 2 phút 1 lần nên RPO xấu nhất 2 phút. Bật PITR thì sao lưu hằng ngày dừng.

Khi khôi phục, dự án không truy cập được, lâu hơn nếu dữ liệu lớn: RTO này phải tự đo. Sao lưu không gồm đối tượng trong Storage, và xóa dự án là xóa luôn bản sao lưu.

Click Star suy ra: hệ thống mức 1 cần RPO 15 phút thì sao lưu hằng ngày không đạt. Cần PITR hoặc tương đương, cùng đường sao lưu riêng cho tệp tải lên.

Sao lưu dữ liệu SaaS: Google Workspace, Microsoft 365 và CRM

Theo trang Shared responsibility in the cloud của Microsoft (cập nhật 24/8/2026), với mọi mô hình kể cả SaaS như Microsoft 365, dữ liệu khách hàng thuộc trách nhiệm của khách hàng. Microsoft cũng nêu phần lớn mất dữ liệu do thao tác của khách hàng (tài liệu về khả năng phục hồi, cập nhật 27/1/2026).

Cửa sổ khôi phục có sẵn thì ngắn. Với SharePoint và OneDrive (trang cập nhật 1/7/2026), có lịch sử phiên bản và thùng rác; mục đã xóa khỏi thùng rác của site có thể nhờ hỗ trợ trong 14 ngày, và Files Restore đưa OneDrive về điểm bất kỳ trong 30 ngày qua.

Với Google Workspace (trang trợ giúp quản trị, đọc 21/10/2026, không ghi ngày), quản trị viên cấp cao khôi phục người dùng bị xóa trong 20 ngày, và dữ liệu Drive đã xóa khỏi thùng rác trong 25 ngày, theo khoảng ngày chứ không chọn từng tệp.

Click Star coi đây là tính năng hoàn tác, không phải chính sách sao lưu: hết hạn là hết, và không giúp khi tài khoản quản trị bị chiếm.

Với CRM, Click Star chưa đọc tài liệu sao lưu của từng nhà cung cấp. Hãy hỏi: xuất được toàn bộ dữ liệu gồm tệp đính kèm và lịch sử không, khôi phục từng bản ghi hay cả hệ thống, thùng rác giữ bao lâu.

Thử khôi phục: bản sao lưu chưa thử là chưa có

NIST SP 800-34 Rev. 1 gọi kiểm thử là yếu tố then chốt, nên làm gần điều kiện thật và có tiêu chí thành công; chính sách mẫu của tài liệu ghi thử hằng năm. Tài liệu AWS viết đường khôi phục duy nhất hoạt động là đường được thử thường xuyên.

CISA khuyên thử cả khôi phục toàn bộ và một phần, lùi được ít nhất 7 ngày. Không nguồn nào quy định tần suất cho doanh nghiệp nhỏ. Quy trình 6 bước của Click Star:

• Bước 1: chọn 1 hệ thống và 1 bản sao lưu, ghi RPO và RTO mục tiêu.
• Bước 2: dựng môi trường tách biệt, không khôi phục đè lên hệ thống đang chạy.
• Bước 3: khôi phục theo sổ tay và bấm giờ từng công đoạn.
• Bước 4: kiểm tra số dòng, tổng tiền, vài bản ghi mẫu và việc đăng nhập.
• Bước 5: so thời gian thực tế và tuổi bản sao lưu với RTO, RPO.
• Bước 6: ghi lỗi, sửa sổ tay, đặt ngày thử kế tiếp.

Tần suất Click Star đề xuất, không có trong nguồn: mức 1 mỗi quý, mức 2 mỗi 6 tháng, mức 3 và 4 mỗi năm.

Lưu giữ và xóa dữ liệu cá nhân trong bản sao lưu

Click Star không tư vấn pháp lý. Click Star đọc Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 (thông qua 26/6/2025, hiệu lực 1/1/2026) qua bản chép trên trang thứ cấp, bằng công cụ tóm tắt. Điều 14 nêu các trường hợp xóa (chủ thể yêu cầu, hết mục đích, hết thời hạn lưu), yêu cầu xóa an toàn và cấm cố ý khôi phục dữ liệu đã xóa khi chưa được phép.

Bản chép đọc được không nhắc "sao lưu", nên chưa rõ dữ liệu đã yêu cầu xóa nhưng còn trong bản sao lưu được xử lý ra sao; Nghị định 356/2025/NĐ-CP chưa được đọc. Đề xuất kỹ thuật của Click Star, chờ ý kiến luật sư: đặt thời hạn giữ bản sao lưu hữu hạn, lưu sổ yêu cầu xóa và áp lại sổ này sau mỗi lần khôi phục.

Chi phí

Trang Supabase liệt kê PITR giữ 7, 14 và 28 ngày khoảng 100, 200 và 400 USD mỗi tháng, chưa gồm compute Small. Trang giá Backblaze B2 (không ghi ngày) ghi từ 6,95 USD mỗi TB mỗi tháng cho lưu trữ ngoài địa điểm, chỉ làm ví dụ.

Click Star khuyên so chi phí hằng tháng với thiệt hại của 1 giờ hệ thống mức 1 ngừng chạy, tính bằng số liệu của chính doanh nghiệp.

Kịch bản sự cố mẫu

Kịch bản minh họa, không phải ca thật. Một câu lệnh cập nhật sai làm đổi giá toàn bộ sản phẩm; 45 phút sau mới phát hiện, trong lúc đó vẫn có đơn mới.

• Ngừng ghi vào bảng giá, lấy từ nhật ký thời điểm ngay trước câu lệnh.
• Khôi phục về thời điểm đó vào cơ sở dữ liệu mới, vì khôi phục đè sẽ làm mất đơn phát sinh sau đó.
• Nạp lại bảng giá đúng vào hệ thống đang chạy, đối chiếu vài sản phẩm mẫu, ghi thời gian so với RTO mức 1.

Nếu thay vào đó tài khoản quản trị bị chiếm và bản sao lưu cùng tài khoản bị xóa, chỉ bản ngoại tuyến hoặc bất biến ở tài khoản khác mới cứu được.

Cách đo

• Thời gian khôi phục thực tế so với RTO.
• Tuổi bản sao lưu gần nhất khôi phục được so với RPO.
• Tỷ lệ thử khôi phục thành công: số lần đạt chia số lần thử trong kỳ.
• Tỷ lệ hệ thống mức 1 và 2 đã được thử trong kỳ.

Đánh giá của Click Star. Rủi ro lớn nhất là chưa ai đo được RTO thật, không phải công nghệ sao lưu. Hãy phân mức trước khi mua công cụ: thường chỉ ít hệ thống cần RPO tính bằng phút. Click Star có làm CRM, CDP, dashboard và phần mềm theo yêu cầu nên có thể được thuê thiết kế sao lưu; hãy đối chiếu với nguồn ngoài.

Lộ trình 30 ngày

• Tuần 1: kiểm kê hệ thống và dữ liệu, xếp mức 1 đến 4, ghi RPO, RTO và người chịu trách nhiệm.
• Tuần 2: kiểm tra từng hệ thống có sao lưu thật chưa; thêm bản bất biến ngoài địa điểm cho mức 1 và 2; bật xác thực đa yếu tố cho tài khoản quản trị.
• Tuần 3: thử khôi phục 1 hệ thống mức 1 vào môi trường tách biệt, bấm giờ, ghi lỗi.
• Tuần 4: sửa sổ tay, đặt lịch thử định kỳ.

Những sai lầm thường gặp

1. Có bản sao lưu nhưng chưa từng khôi phục thử, nên không biết RTO thật.
2. Nhầm sao chép liên tục với sao lưu, nên lỗi cũng được chép sang bản kia.
3. Để bản sao lưu và hệ thống chính dùng chung tài khoản quản trị.
4. Tin rằng SaaS đã sao lưu giúp, trong khi cửa sổ khôi phục chỉ tính bằng ngày.
5. Đặt 1 mục tiêu chung cho mọi hệ thống, gây tốn kém hoặc thiếu bảo vệ.
6. Quên phần ngoài bản sao lưu như tệp Storage và tệp cấu hình.

Điều chưa biết

Click Star chưa có số đo về mức độ doanh nghiệp nhỏ ở Việt Nam đặt RPO, RTO hay thử khôi phục, và chưa có số liệu ransomware riêng cho Việt Nam. Trang Supabase, AWS, CISA và Backblaze không ghi ngày cập nhật, nên tính năng và giá có thể đã đổi.

Luật đọc qua bản chép thứ cấp, Nghị định 356/2025/NĐ-CP chưa đọc, và chưa rõ luật áp dụng ra sao cho dữ liệu nằm trong bản sao lưu. Khung 4 mức và tần suất thử là đề xuất của Click Star.