Backup và phục hồi

Nên giữ backup trong bao lâu và xoay vòng thế nào?

Cách chọn thời gian lưu backup theo khả năng phát hiện lỗi, nhu cầu đối soát, tốc độ tăng dữ liệu và ngân sách, kèm mô hình xoay vòng GFS.

Thời gian lưu và xoay vòng backup
Mục lục

Khi thiết lập backup cho một website hoặc VPS, câu hỏi khiến nhiều người quản trị phân vân nhất thường là: Nên giữ các bản backup này trong bao lâu? Có nên xóa bớt sau 7 ngày không, hay cứ để đó tích lũy quanh năm cho chắc?

Nếu bạn giữ dữ liệu quá ngắn (ví dụ chỉ giữ 3 ngày gần nhất), bạn sẽ rơi vào thế bị động khi gặp phải một lỗi âm thầm: một đoạn mã lỗi được cập nhật tuần trước làm sai lệch số liệu tồn kho, hoặc một nhân viên vô tình xóa mất một thư mục hợp đồng nhưng 10 ngày sau khách hàng mới khiếu nại. Lúc này, mở danh sách backup ra thì tất cả các bản lưu đều đã chứa dữ liệu sai.

Ngược lại, nếu bạn giữ mọi bản backup ngày này qua tháng khác mà không có cơ chế xoay vòng, ổ đĩa lưu trữ sẽ nhanh chóng bị phình to, hóa đơn cloud tăng vọt mỗi tháng, và bạn sẽ phải đối mặt với một danh sách hàng trăm file backup lộn xộn mà không biết bản nào thực sự giá trị khi cần khôi phục.

Một chính sách lưu trữ (retention policy) chuẩn mực không phải là cố gắng giữ mọi thứ mãi mãi. Đó là việc thiết kế các mốc thời gian quay đầu (look-back window) đủ thông minh để xử lý sự cố trong quá khứ mà chi phí lưu trữ vẫn luôn nằm trong tầm kiểm soát.

Phân biệt rõ giữa tần suất backup và thời gian lưu trữ

Rất nhiều người thường nhầm lẫn giữa hai khái niệm này:

  • Tần suất backup (Frequency): Cho biết bạn tạo ra điểm khôi phục bao lâu một lần (mỗi giờ, mỗi ngày hay mỗi tuần). Tần suất này quyết định chỉ số RPO — lượng dữ liệu tối đa doanh nghiệp có thể bị mất giữa hai lần sao lưu (xem phân tích chuyên sâu tại bài RPO và RTO khác nhau thế nào trong một sự cố thật?).
  • Thời gian lưu trữ (Retention): Cho biết một bản backup sau khi sinh ra sẽ được giữ lại trong bao nhiêu ngày, tuần hoặc tháng trước khi bị xóa tự động. Chỉ số này quyết định bạn có thể quay ngược thời gian về quá khứ bao xa để tìm lại trạng thái dữ liệu nguyên vẹn trước khi lỗi phát sinh.

Nếu bạn đặt lịch backup mỗi giờ nhưng chỉ lưu trong 24 giờ, bạn có thể khôi phục dữ liệu rất sát với hiện tại, nhưng hoàn toàn bất lực nếu cần tìm lại một file bị xóa từ 3 ngày trước.

Ngược lại, nếu bạn backup mỗi ngày một lần và lưu suốt 1 năm, bạn có thể quay lại quá khứ rất xa, nhưng nếu sự cố xảy ra vào 5h chiều, bạn vẫn chấp nhận mất trắng dữ liệu phát sinh từ 2h sáng đến thời điểm đó.

Một hệ thống tốt phải kết hợp hài hòa cả hai: tần suất đủ dày ở các mốc gần để giảm thiểu mất mát dữ liệu, và khoảng cách dãn dần ở các mốc xa để tiết kiệm dung lượng.

4 yếu tố thực tế để xác định thời gian lưu trữ

Trước khi chốt con số lưu bao nhiêu ngày, hãy tự trả lời 4 câu hỏi nghiệp vụ sau:

1. Thời gian phát hiện lỗi trung bình của website là bao lâu?

Một lỗi hiển thị trên trang chủ thường được phát hiện sau vài chục phút. Nhưng một lỗi sai công thức tính khuyến mại, lỗi mất ảnh đại diện của các bài viết cũ, hoặc lỗi cơ sở dữ liệu phát sinh từ một đợt cập nhật phần mềm có thể mất từ 1 đến 2 tuần mới có người nhận ra. Thời gian lưu các bản backup gần nhất (Daily) bắt buộc phải dài hơn thời gian phát hiện lỗi trung bình này.

2. Doanh nghiệp có các mốc đối soát kinh doanh định kỳ nào?

Website thương mại hoặc hệ thống nội bộ thường có các kỳ chốt số liệu vào cuối tuần, cuối tháng hoặc cuối quý. Giữ lại một bản backup rơi đúng vào ngày cuối cùng của mỗi tháng sẽ giúp kế toán và đội ngũ vận hành có điểm đối chiếu tin cậy khi cần rà soát lại dữ liệu quá khứ.

3. Tỷ lệ thay đổi dữ liệu (Change rate) và ngân sách lưu trữ

Một website tin tức có dung lượng tăng rất chậm, trong khi một sàn bán hàng có hàng nghìn đơn mỗi ngày và dung lượng ảnh tải lên tăng liên tục. Nếu lưu trữ trên Object Storage (S3, Cloudflare R2), chi phí tính theo từng GB mỗi tháng. Bạn cần tính toán xem việc lưu trữ 20 bản hay 50 bản backup sẽ tiêu tốn bao nhiêu chi phí để cân đối ngân sách.

4. Quy định bảo vệ dữ liệu và bảo mật

Trong một số ngành nghề, dữ liệu giao dịch cần được lưu trữ tối thiểu trong một khoảng thời gian nhất định để phục vụ thanh tra. Tuy nhiên, ở chiều ngược lại, việc lưu trữ thông tin cá nhân của khách hàng cũ quá lâu mà không có lý do chính đáng cũng có thể vi phạm các chính sách bảo mật dữ liệu riêng tư.

Mô hình xoay vòng backup chuẩn: Phương pháp GFS (Grandfather-Father-Son)

Cách quản lý thời gian lưu trữ phổ biến, khoa học và tiết kiệm dung lượng nhất trong ngành quản trị hệ thống là mô hình Grandfather-Father-Son (Ông - Cha - Con):

  • Son (Bản ngày - Daily): Lưu các bản backup chạy mỗi đêm. Giữ trong 7 đến 14 ngày gần nhất. Nhiệm vụ là xử lý các sự cố vừa mới phát sinh hôm qua hoặc trong tuần.
  • Father (Bản tuần - Weekly): Mỗi tuần chọn ra một bản backup của ngày Chủ nhật (hoặc ngày cuối tuần) để giữ lại. Giữ trong 4 đến 8 tuần gần nhất. Nhiệm vụ là xử lý các lỗi âm thầm được phát hiện sau 2 - 3 tuần.
  • Grandfather (Bản tháng - Monthly): Mỗi tháng chọn ra một bản backup vào ngày cuối cùng của tháng để giữ lại. Giữ trong 6 đến 12 tháng gần nhất. Nhiệm vụ là phục vụ đối soát, kiểm toán hoặc khôi phục dữ liệu lịch sử dài hạn.

Bảng cấu hình lưu trữ mẫu cho VPS website nhỏ

Dưới đây là một cấu hình mẫu rất thực tế và cân bằng giữa độ an toàn và chi phí dành cho các website doanh nghiệp vừa và nhỏ:

Phân lớp backupTần suất tạoThời gian giữ lại (Retention)Số lượng bản lưuMục đích sử dụng chính
Daily (Bản ngày)Mỗi đêm lúc 2h00Giữ 14 ngày gần nhất14 bảnKhôi phục sự cố khẩn cấp, lỗi code mới deploy, xóa nhầm gần
Weekly (Bản tuần)2h00 sáng Chủ nhậtGiữ 8 tuần gần nhất8 bảnKhôi phục lỗi dữ liệu âm thầm phát hiện muộn trong tháng
Monthly (Bản tháng)2h00 sáng ngày 01Giữ 12 tháng gần nhất12 bảnĐối chiếu lịch sử năm, kiểm toán, điều tra dữ liệu cũ
Sự kiện (Event-based)Trước khi nâng cấp lớnGiữ 30 ngày sau khi làmTùy nhu cầuĐiểm quay đầu an toàn khi đổi server, nâng cấp hệ điều hành

Với cấu hình này, tổng cộng bạn chỉ cần lưu trữ khoảng 34 bản backup nhưng lại có thể bao phủ toàn bộ lịch sử phục hồi lên tới 1 năm tròn, thay vì phải lưu đủ 365 bản hàng ngày gây lãng phí tài nguyên.

Tự động hóa xoay vòng bằng công cụ, tuyệt đối không xóa thủ công

Một sai lầm rất nguy hiểm là để quản trị viên thỉnh thoảng vào thư mục backup, nhìn thấy ổ đĩa sắp đầy rồi chạy lệnh rm -rf để xóa bớt các file có đuôi ngày cũ.

Nếu hệ thống backup của bạn sử dụng cơ chế nén vi sai (incremental backup) — tức là bản sau chỉ lưu phần dữ liệu thay đổi dựa trên bản trước — thì việc bạn vô tình xóa mất một file "bản gốc" (full base) sẽ khiến toàn bộ chuỗi các bản backup phía sau bị hỏng hoàn toàn và không thể khôi phục được nữa.

Cách làm chuẩn mực là giao việc xoay vòng cho các công cụ tự động quản trị vòng đời dữ liệu (Lifecycle Policy):

1. Nếu dùng công cụ backup chuyên dụng (Restic, BorgBackup)

Các công cụ này có sẵn tính năng dọn dẹp (pruning) thông minh, tự động hiểu được mối liên hệ giữa các khối dữ liệu:

bash
# Giữ lại 14 bản ngày, 8 bản tuần, 12 bản tháng và tự động dọn dẹp phần còn lại
restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

Công cụ sẽ tự tính toán để xóa các khối dữ liệu thừa mà không bao giờ làm ảnh hưởng đến tính toàn vẹn của các mốc thời gian còn giữ lại.

2. Nếu đẩy file nén lên Cloud Storage (S3, Cloudflare R2)

Bạn có thể cấu hình Lifecycle Rules trực tiếp trên bảng điều khiển của dịch vụ cloud:

  • Các file trong thư mục daily/ tự động hết hạn và xóa sau 14 ngày.
  • Các file trong thư mục weekly/ tự động xóa sau 60 ngày.
  • Các file trong thư mục monthly/ tự động chuyển sang lớp lưu trữ giá rẻ (Glacier hoặc Deep Archive) sau 30 ngày để tiết kiệm đến 80% chi phí.

Khóa bảo vệ bản lưu trữ trước nguy cơ bị xóa sớm (Retention Lock)

Một rủi ro bảo mật lớn hiện nay là khi kẻ tấn công xâm nhập được vào tài khoản quản trị cloud, việc đầu tiên chúng làm là xóa sạch toàn bộ các bản backup hoặc sửa chính sách retention về 0 ngày để tống tiền doanh nghiệp.

Để ngăn chặn kịch bản này, các dịch vụ cloud cung cấp tính năng Object Lock / Retention Lock:

  • Khi bật chế độ này, bạn thiết lập một thời gian khóa cố định (ví dụ: các bản monthly bị khóa cứng trong 90 ngày).
  • Trong khoảng thời gian đã khóa, không một ai (kể cả tài khoản Root hay lập trình viên) có quyền xóa file hoặc rút ngắn thời gian lưu trữ.
  • Đây là chiếc khóa bảo hiểm tối thượng bảo vệ doanh nghiệp trước cả mã độc tống tiền lẫn các thao tác sai lầm của con người.

Checklist rà soát chính sách lưu trữ backup của bạn

Hãy dành ít phút đối chiếu chính sách backup hiện tại của hệ thống bạn với các câu hỏi sau:

  • ☐ Bạn có biết bản backup cũ nhất hiện còn lưu trên hệ thống là từ ngày nào không?
  • ☐ Thời gian lưu các bản gần nhất (Daily) có đủ dài để bao phủ những ngày cuối tuần và dịp nghỉ lễ không?
  • ☐ Các bản backup có được tự động dọn dẹp theo chính sách (GFS) hay đang phụ thuộc vào việc nhớ xóa bằng tay?
  • ☐ Bạn đã từng thử tải về và restore thử một bản backup cũ từ 3 tháng trước theo Checklist thử restore website trên môi trường tách biệt để đảm bảo dữ liệu quá khứ vẫn đọc được bình thường không?
  • ☐ Bản sao lưu có được phân tán theo Quy tắc backup 3-2-1 cho VPS nhỏ để tránh bị xóa đồng thời không?
  • ☐ Chi phí lưu trữ backup trên hóa đơn cloud hàng tháng có đang tăng trưởng ổn định hay đang tăng phi mã?
  • ☐ Các bản backup quan trọng đã được cấu hình khóa chống xóa (Object Lock) chưa?

Một chiến lược lưu trữ backup thông minh không đo lường bằng việc bạn có bao nhiêu terabyte dữ liệu trong kho, mà bằng việc khi sự cố xảy ra, bạn luôn có một điểm khôi phục sạch sẽ, toàn vẹn và đúng mốc thời gian doanh nghiệp cần. Hãy kết hợp chính sách retention này với một chiến lược backup VPS tổng thể để bảo vệ an toàn cho hệ thống của bạn.

Chia sẻ bài viết hữu ích

Gửi bài viết này cho đồng nghiệp

Đọc tiếp

Bài nên đọc tiếp

Xem tất cả bài về Backup và phục hồi