Backup dữ liệu doanh nghiệp: quy tắc 3-2-1 áp dụng thực tế

Ổ cứng máy chủ hỏng lúc 2 giờ sáng thứ Bảy. Chín giờ sáng, kế toán gọi hỏi vì sao không mở được phần mềm. Đội IT trả lời rất bình tĩnh: "Có backup rồi." Đến 11 giờ, mọi người phát hiện bản sao lưu chạy thành công gần nhất là của ba tháng trước — tác vụ tự động đã lỗi từ lâu, email cảnh báo rơi vào thư mục spam của một tài khoản không ai còn dùng.

Đây là dạng tình huống chúng tôi gặp lại nhiều nhất khi được gọi vào xử lý sự cố. Vấn đề của backup dữ liệu doanh nghiệp gần như không bao giờ là "công ty không có backup". Hầu hết đều có một thứ gì đó gọi là backup. Vấn đề nằm chỗ khác: bản sao đó ở đâu, chạy lần cuối lúc nào, và câu hỏi giết chết nhiều doanh nghiệp nhất — đã có ai từng thử khôi phục nó ra chưa.

Quy tắc 3-2-1 sinh ra để trả lời ba câu đó, và nó không đắt như nhiều người tưởng: với công ty 20-30 người, chi phí cả năm thường nhỏ hơn thiệt hại của hai ngày ngừng bán hàng.

Bốn kiểu mất dữ liệu có thật, không phải kịch bản dọa nhau

Nói tới sao lưu, phần lớn người nghĩ tới hỏng ổ cứng. Thực tế phần cứng chỉ là một trong bốn nguyên nhân, và không phải nguyên nhân phổ biến nhất.

Xóa nhầm và ghi đè. Nhân viên mở file báo giá tháng trước, sửa thẳng lên đó rồi lưu. Bản gốc biến mất, không cảnh báo, không ai biết cho tới lúc cần. Loại này chiếm tỷ trọng cao nhất trong các ca chúng tôi tiếp nhận.

Hỏng phần cứng. SSD chết đột ngột, không báo trước như ổ cơ. Và xin nói rõ: RAID không phải backup. RAID chống hỏng một ổ, nhưng khi bạn xóa nhầm một file, RAID xóa nhầm đồng bộ trên cả hai ổ trong tích tắc.

Ransomware. Mã độc hiện đại mã hóa luôn ổ mạng, ổ ánh xạ và thư mục đồng bộ đám mây — nó ăn cả bản backup nếu bản đó nằm cùng mạng và gắn thường trực. Kịch bản xử lý nằm trong bài phòng chống ransomware cho SME; nguyên tắc gói trong một câu: bản sao lưu nào máy chủ ghi được thì mã độc cũng ghi được.

Nhân sự nghỉ việc. Sale nghỉ, danh sách khách trong máy cá nhân đi theo. Lập trình viên nghỉ, tài khoản quản trị không ai bàn giao. Dữ liệu vẫn còn ở đâu đó nhưng không ai truy cập được — về vận hành cũng như đã mất.

Bốn kiểu này đòi bốn cách phòng khác nhau. Một bản backup duy nhất, đặt cùng chỗ với dữ liệu gốc, chỉ chống được một kiểu.

Quy tắc 3-2-1 giải thích đơn giản

Phát biểu bằng tiếng Việt dễ hiểu:

1. 3 bản dữ liệu: bản đang dùng, cộng hai bản sao lưu.
2. 2 loại phương tiện khác nhau: đừng để cả ba bản trên cùng một loại thiết bị. Ví dụ dữ liệu trên máy chủ, một bản trên NAS hoặc ổ ngoài, một bản trên cloud.
3. 1 bản đặt ở nơi khác: khác tòa nhà, khác hệ thống mạng. Cháy nổ, mất trộm, ngập nước hay ransomware quét cả mạng nội bộ đều không chạm tới bản này.

Điều kiện thứ ba quan trọng nhất và cũng bị bỏ qua nhiều nhất. Không ít công ty có đủ ba bản nhưng cả ba nằm chung phòng máy, chung dải mạng, chung một tài khoản quản trị. Đó là 3-2-0.

Vài năm gần đây giới bảo mật bổ sung thành 3-2-1-1-0: thêm 1 bản bất biến (không thể ghi đè hay xóa trong thời gian đã đặt) và 0 lỗi khi kiểm tra khôi phục. SME chưa cần chạy theo cả chuỗi, nhưng hai con số thêm vào chỉ đúng hai điểm yếu thật.

Thiết kế backup theo từng loại dữ liệu

Sai lầm phổ biến là đối xử với mọi dữ liệu như nhau: cùng tần suất, cùng nơi lưu. Kết quả là vừa tốn tiền lưu thứ không cần, vừa thiếu bản cho thứ quan trọng. Trước khi bàn kỹ thuật, cần thống nhất hai chỉ số: RPO là được phép mất bao nhiêu dữ liệu tính theo thời gian (RPO 24 giờ là chấp nhận mất tối đa một ngày làm việc), RTO là được phép ngừng bao lâu để khôi phục xong.

Backup website đủ nghĩa gồm ba phần: mã nguồn, database và file người dùng tải lên. Thiếu một phần, bạn khôi phục ra một cái vỏ. Nhiều nơi quảng cáo "backup hằng ngày" nhưng chỉ giữ bản mới nhất và ghi đè liên tục — website bị chèn mã độc từ mười ngày trước thì bản backup cũng đã nhiễm. Chính sách mặc định trên hệ thống chúng tôi vận hành là giữ 30 ngày, đủ để lùi về trước thời điểm mã độc nằm vùng. Nếu bạn dùng shared hosting và không rõ mình được backup ra sao, bài VPS, hosting hay cloud nên chọn gì nói rõ khác biệt về quyền kiểm soát dữ liệu giữa các nền tảng.

Với database, hãy dump đúng chuẩn thay vì copy file thô lúc dịch vụ đang chạy, và bật nhật ký giao dịch (binlog với MySQL, WAL với PostgreSQL) để lùi về đúng phút trước khi lệnh xóa nhầm chạy. Với file làm việc, bật lưu nhiều phiên bản và bắt buộc dữ liệu nằm ở thư mục chung được sao lưu, không phải Desktop máy cá nhân.

Backup không tự chạy là backup sẽ bị quên

Quy trình sao lưu phụ thuộc vào việc ai đó nhớ bấm nút sẽ hỏng trong vòng sáu tuần: tuần nào cũng có việc gấp hơn. Tự động hóa đúng nghĩa gồm bốn phần:

1. Lịch chạy tự động bằng cron hoặc dịch vụ backup có lịch, đặt vào giờ tải thấp.
2. Đẩy bản sao ra ngoài ngay sau khi tạo. Bản nằm lại trên chính máy chủ nguồn không tính là bản thứ ba.
3. Cảnh báo khi thất bại và cả khi không chạy. Hệ thống chỉ gửi mail lúc lỗi thì khi cron bị xóa, bạn không nhận được gì — im lặng bị hiểu nhầm là ổn. Cần báo động khi quá 24 giờ không thấy bản backup mới.
4. Kiểm tra tính toàn vẹn bằng checksum và dung lượng. File dump 40 KB trong khi bình thường là 400 MB nghĩa là lệnh dump đã lỗi nhưng vẫn tạo ra file.

Về tài khoản, hãy tách quyền: tài khoản ghi backup lên kho lưu trữ chỉ nên được tạo mới, không được xóa. Đây là cách rẻ nhất chống kịch bản kẻ tấn công chiếm máy chủ rồi xóa sạch bản sao trước khi mã hóa. Các nguyên tắc phân quyền tương tự cho hạ tầng web nằm trong checklist bảo mật website cho người không biết code.

Thử restore định kỳ — nghi thức 30 phút mỗi quý

Một bản backup chưa từng được khôi phục thử không phải backup, nó là một file bạn hy vọng dùng được. Chúng tôi đã gặp đủ kiểu hỏng chỉ lộ ra đúng lúc cần: file nén thiếu byte cuối, dump database thiếu bảng vì tài khoản backup không đủ quyền đọc, bản sao còn nguyên nhưng không ai biết mật khẩu giải mã, và trường hợp đau nhất — khôi phục được nhưng mất gần một ngày vì phải kéo hàng trăm GB qua đường truyền văn phòng.

Quy trình thử khôi phục mỗi quý, làm gọn trong 30 phút:

1. Phút 0-3 — chọn ngẫu nhiên. Không lấy bản mới nhất, lấy bản của một ngày bất kỳ trong 30 ngày qua, vì sự cố thật thường buộc bạn lùi xa hơn.
2. Phút 3-8 — tải về môi trường sạch. Tải xuống một máy hoặc VPS tạm, không phải máy chủ đang chạy. Bấm giờ bước này: tốc độ tải quyết định RTO thật.
3. Phút 8-18 — khôi phục thật. Bung file, nạp database vào instance riêng, dựng site lên một tên miền phụ. Không phải mở file ra xem, mà phải chạy được.
4. Phút 18-25 — kiểm tra bằng ba câu hỏi nghiệp vụ. Đăng nhập được bằng tài khoản quản trị không? Đơn hàng gần nhất trước thời điểm backup có đúng số tiền không? Ảnh sản phẩm và file đính kèm mở được không?
5. Phút 25-30 — ghi biên bản. Một trang: ngày thử, bản nào, ai làm, tổng thời gian tới lúc hệ thống chạy lại, vấn đề phát hiện được. Con số thời gian đó chính là RTO thật, thường lớn hơn 2-3 lần con số mọi người tưởng.

Nếu công ty bạn không có người phụ trách, hãy đưa hạng mục này vào hợp đồng vận hành với đơn vị kỹ thuật, kèm yêu cầu nộp biên bản mỗi quý.

Chi phí thực tế cho SME theo dung lượng

Khoảng giá dưới đây là tham khảo thị trường tại thời điểm viết (08/2026), chưa gồm VAT, tính cho mô hình 3-2-1 đầy đủ: bản thứ hai lưu tại chỗ, bản thứ ba lưu trên cloud khác vùng.

Hai lưu ý khi đọc bảng. Giá cloud chênh nhau rất xa tùy loại lưu trữ: object storage dạng nguội có thể chỉ vài trăm đồng mỗi GB mỗi tháng, ổ đĩa hiệu năng cao gắn kèm máy chủ đắt gấp nhiều lần. Đừng quên phí tải dữ liệu ra: một số nhà cung cấp quốc tế tính tiền băng thông chiều lấy về, đúng ngày sự cố kéo cả terabyte thì hóa đơn mới xuất hiện.

Đặt cạnh chi phí ngừng hoạt động thì đây là khoản nhỏ: một công ty thương mại 30 người, doanh thu 6 tỷ mỗi năm, ngừng bán hai ngày đã mất khoảng 45-50 triệu doanh thu.

Với doanh nghiệp chưa muốn đầu tư NAS, một VPS nhỏ làm điểm nhận backup là phương án tiết kiệm: gói VPS của chúng tôi khởi điểm từ 199.000đ/tháng, đủ cho vai trò kho lưu bản sao website và database — cách chọn cấu hình theo tải thật có trong bài chi phí thuê VPS cho doanh nghiệp. Nếu muốn giao trọn phần này cho đội bên ngoài, dịch vụ máy chủ của chúng tôi gồm backup hằng ngày lưu 30 ngày, giám sát 24/7, uptime cam kết 99.9% và phản hồi sự cố P1 trong 15 phút.

Muốn ai đó soi lại hiện trạng sao lưu và chỉ ra chỗ thủng trước khi sự cố xảy ra, gọi hotline 0919 788 815 hoặc để lại thông tin trên microads.vn. Chúng tôi tư vấn miễn phí, kể cả khi kết luận là hệ thống của bạn chưa cần đầu tư thêm gì.