Chính sách lifecycle cho bản backup: giữ bao lâu, xóa khi nào?

Tháng trước, một chủ shop online gọi cho đội kỹ thuật trong hoảng loạn: website bị lỗi sau khi cập nhật plugin, cần khôi phục về bản của 4 tháng trước — đúng thời điểm dữ liệu đơn hàng còn "sạch". Vấn đề là ổ backup đã đầy từ lâu, và theo "quy định miệng" của team, bản backup quá 30 ngày tự động bị xóa. Bản cần nhất thì không còn, bản còn lại thì không dùng được. Đó chính là lúc doanh nghiệp nhận ra: backup mà không có chính sách lifecycle backup rõ ràng thì chẳng khác nào không backup.

Chính sách lifecycle backup là bộ quy tắc xác định vòng đời của mỗi bản sao lưu: tạo ra khi nào, lưu ở đâu, giữ trong bao lâu, và xóa (hoặc chuyển kho lạnh) khi nào. Nó trả lời ba câu hỏi tưởng đơn giản nhưng hầu hết SME Việt Nam chưa từng viết ra giấy: dữ liệu nào quan trọng đến mức phải giữ 1 năm? Bản backup nào được phép xóa sau 30 ngày? Ai là người quyết định xóa?

Bài viết này giúp team kỹ thuật và chủ doanh nghiệp xây dựng chính sách lifecycle backup thực tế: mô hình lưu giữ GFS, cách đặt thời gian giữ theo từng loại dữ liệu, quy định pháp luật Việt Nam, bài toán chi phí, và checklist mẫu áp dụng ngay.

Chính sách lifecycle backup: lifecycle policy cho backup là gì? Vì sao "cứ backup là xong" rất nguy hiểm

Nhiều đội kỹ thuật hiểu backup đơn giản là "chạy cron dump database mỗi đêm rồi đẩy lên ổ cứng". Nhưng backup chỉ là điểm bắt đầu của vòng đời dữ liệu. Một bản backup sau khi sinh ra sẽ đi qua các giai đoạn: tạo mới → lưu trữ nóng (khôi phục nhanh) → chuyển kho lạnh (rẻ hơn, khôi phục chậm hơn) → xóa vĩnh viễn. Chính sách lifecycle chính là "lịch trình" cho từng giai đoạn đó.

Không có lifecycle policy, doanh nghiệp thường rơi vào một trong hai thái cực tốn kém:

Thái cực 1: giữ mãi mãi. Một SME với database 50 GB, backup full mỗi đêm mà không xóa bản cũ, sau 1 năm sẽ "ôm" khoảng 18 TB dữ liệu — trong khi 95% số bản đó không bao giờ được đụng tới. Chi phí lưu trữ đội lên, tốc độ backup chậm dần, và lúc cần tìm một bản cụ thể thì mò kim đáy bể.

Thái cực 2: xóa bừa, giữ quá ngắn. Nhiều nơi đặt cron "xóa bản cũ hơn 7 ngày" cho gọn ổ, đến khi phát hiện dữ liệu bị hỏng âm thầm từ 2 tháng trước (lỗi logic, xóa nhầm, mã độc nằm vùng) thì mọi bản còn lại đều đã chứa... dữ liệu hỏng. Đây là kịch bản kinh điển khiến backup "có như không".

Một lifecycle policy tốt cân bằng ba yếu tố: khả năng khôi phục (RPO/RTO), chi phí lưu trữ, và tuân thủ pháp lý. Nó phải được viết thành văn bản, có người chịu trách nhiệm, và được tự động hóa — chứ không thể trông chờ vào trí nhớ của một anh kỹ thuật.

Chính sách lifecycle backup: mô hình GFS: giữ nhiều bản cũ mà không tốn ổ

GFS (Grandfather-Father-Son) là mô hình luân chuyển backup lâu đời nhất và vẫn được dùng rộng rãi vì đơn giản, hiệu quả. Ý tưởng: không giữ mọi bản backup với "quyền" như nhau, mà phân tầng theo độ tuổi — bản càng cũ, giữ càng thưa.

• Son (bản con — hàng ngày): backup mỗi ngày, giữ 7 bản gần nhất. Tuyến phòng thủ đầu tiên cho sự cố "mới xảy ra": xóa nhầm file, lỗi cập nhật.
• Father (bản cha — hàng tuần): mỗi tuần "phong" 1 bản daily làm weekly, giữ 4–5 bản. Dùng khi sự cố phát hiện muộn vài tuần — ví dụ dữ liệu bị ghi đè sai từ 20 ngày trước.
• Grandfather (bản ông — hàng tháng): mỗi tháng chọn 1 bản weekly làm monthly, giữ 12 bản (1 năm), thậm chí 3–7 năm với dữ liệu có yêu cầu pháp lý. "Kho sử liệu" cho tranh chấp, kiểm toán, khôi phục sau tấn công nằm vùng lâu ngày.

Ví dụ cụ thể: database bán hàng 80 GB. Nếu backup full mỗi ngày và giữ 365 bản/năm, cần khoảng 29 TB. Với GFS (7 daily + 4 weekly + 12 monthly, dùng incremental cho daily), tổng dung lượng thực tế chỉ khoảng 1–2 TB — giảm hơn 90% mà vẫn có bản khôi phục cho mọi "độ tuổi" sự cố.

Điểm mấu chốt của GFS: bạn không cần mọi bản backup, bạn cần đúng bản backup. Một bản daily từ 200 ngày trước gần như vô giá trị, nhưng một bản monthly từ 6 tháng trước có thể là cứu cánh khi phát hiện gian lận số liệu.

Nhiều hệ thống backup hiện đại (Veeam, Bacula, restic, công cụ cloud-native) đã tích hợp sẵn GFS — bạn chỉ cần cấu hình "giữ 7 daily, 4 weekly, 12 monthly" thay vì tự viết script xoay vòng.

Chính sách lifecycle backup: kết hợp quy tắc 3-2-1 với lifecycle: bản nào ở đâu, giữ bao lâu

Quy tắc 3-2-1 kinh điển: giữ 3 bản sao dữ liệu, trên 2 loại phương tiện khác nhau, 1 bản offsite. Phiên bản hiện đại 3-2-1-1-0 bổ sung 1 bản immutable và 0 lỗi khi khôi phục (đã test restore). Nhưng 3-2-1 chỉ trả lời "giữ ở đâu", còn lifecycle trả lời "giữ bao lâu" — hai thứ phải đi cùng nhau. Cách kết hợp thực tế cho SME:

Lưu ý quan trọng: lifecycle của từng tầng là độc lập. Bản daily ở tầng 1 có thể bị xóa sau 14 ngày, nhưng bản monthly đã "thăng hạng" lên tầng 2 vẫn tồn tại 12 tháng. Sai lầm phổ biến là đặt một chính sách xóa duy nhất cho cả hệ thống — xóa bản daily ở NAS thì vô tình xóa luôn bản monthly duy nhất còn lại.

Với ransomware ngày càng nhắm vào cả hệ thống backup, tầng 3 immutable là "phao cứu sinh" cuối cùng: kể cả khi kẻ tấn công chiếm được quyền admin, chúng vẫn không thể xóa bản backup đã bị khóa — và policy phải ghi rõ không ai được rút ngắn retention lock khi chưa hết hạn.

Giữ bao lâu theo từng loại dữ liệu? Không phải dữ liệu nào cũng như nhau

Sai lầm lớn nhất khi viết lifecycle policy là đặt một con số duy nhất cho mọi thứ ("giữ backup 30 ngày"). Database bán hàng, source code, log hệ thống và ảnh sản phẩm có giá trị hoàn toàn khác nhau. Bảng dưới đây là khung tham khảo cho SME/team kỹ thuật (điều chỉnh theo nghĩa vụ pháp lý ở mục sau):

Nguyên tắc phân loại: hỏi ba câu cho mỗi loại dữ liệu — (1) mất nó thì thiệt hại bao nhiêu tiền? (2) luật có bắt giữ không? (3) khả năng cần khôi phục bản cũ sau X tháng là bao nhiêu? Đừng để "cảm giác an toàn" quyết định con số retention.

Một mẹo thực tế: gắn nhãn (tag) cho từng bản backup ngay khi tạo — ví dụ data:db-prod, retention:90d. Khi chính sách xóa tự động chạy, nó chỉ cần đọc nhãn thay vì đoán. Không có nhãn, automation xóa nhầm là chuyện sớm muộn.

Pháp luật Việt Nam bắt buộc giữ dữ liệu bao lâu?

Đây là phần nhiều team kỹ thuật bỏ qua — cho đến khi kiểm toán hỏi. Lifecycle policy không thể đặt thời gian giữ ngắn hơn quy định pháp luật, dù lý do tiết kiệm chi phí có hấp dẫn đến đâu.

Tài liệu kế toán: Theo Luật Kế toán 2015 và Nghị định 174/2016/NĐ-CP, chứng từ kế toán lưu tối thiểu 5 năm; sổ kế toán, báo cáo tài chính tối thiểu 10 năm; tài liệu có tính sử liệu lưu vĩnh viễn. Hóa đơn điện tử (Nghị định 123/2020/NĐ-CP) cũng thuộc diện 10 năm. Bản backup chứa dữ liệu kế toán không được xóa trước các mốc này.

Dữ liệu cá nhân: Nghị định 13/2023/NĐ-CP quy định dữ liệu cá nhân chỉ được lưu trữ trong khoảng thời gian phù hợp với mục đích xử lý — và phải xóa, hủy khi hết mục đích hoặc khi chủ thể rút lại sự đồng ý. Với dữ liệu khách hàng, policy phải có cả quy trình xóa theo yêu cầu, không chỉ lịch xóa định kỳ.

Thực tế cho SME: lập một bảng "nghĩa vụ lưu trữ pháp lý" riêng trong policy — loại dữ liệu nào chịu văn bản nào, mốc tối thiểu bao lâu. Khi automation chuẩn bị xóa, bước kiểm tra cuối cùng luôn là: bản này có chứa dữ liệu đang trong thời hạn lưu trữ bắt buộc không? Nếu có — giữ lại, không bàn cãi.

Bài toán chi phí: giữ thêm 1 năm tốn bao nhiêu, mất dữ liệu tốn bao nhiêu?

Lifecycle policy suy cho cùng là bài toán kinh tế: chi phí lưu trữ thêm so với chi phí khi mất dữ liệu. Làm phép tính minh họa với một SME điển hình: 2 TB dữ liệu backup, object storage giá minh họa khoảng 500.000đ/TB/tháng (tầng tiêu chuẩn) và 150.000đ/TB/tháng (kho lạnh):

*Đã tính nén và incremental; số liệu minh họa, thực tế tùy tỷ lệ thay đổi dữ liệu.

Điểm đáng chú ý: giữ 12 tháng kèm archive chỉ đắt hơn giữ 90 ngày một chút, vì bản cũ được chuyển sang tầng lưu trữ rẻ. Trong khi đó, chi phí của một lần mất dữ liệu không khôi phục được với SME thường tính bằng trăm triệu: doanh thu những ngày gián đoạn, phạt vi phạm SLA, chi phí thuê ngoài khôi phục, và tổn thất uy tín khó đo đếm.

Quy tắc ra quyết định: chi phí retention 1 năm của dữ liệu lõi hiếm khi vượt quá 1% doanh thu năm của SME, trong khi một sự cố mất dữ liệu nghiêm trọng có thể "ăn" 5–10% doanh thu. Đừng tiết kiệm vài triệu tiền ổ cứng để đánh cược cả công ty. Ngược lại, với dữ liệu ít giá trị (log cũ, file tạm), hãy mạnh dạn đặt retention ngắn — đó mới là chỗ tiết kiệm đúng.

Tự động hóa: xóa theo lịch, anonymize, và "ai được phép xóa"

Chính sách viết trên giấy mà thực thi bằng tay thì sớm muộn cũng hỏng — người quên, người nghỉ việc, người "để mai xóa". Lifecycle policy hiện đại phải được tự động hóa ở ba khâu:

1. Xóa theo lịch. Mọi nền tảng lưu trữ lớn hiện nay đều hỗ trợ lifecycle rules: S3, Google Cloud Storage hay object storage tương thích S3 đều cho phép đặt quy tắc "object quá 30 ngày → chuyển archive; quá 365 ngày → xóa". Khai báo một lần, hệ thống tự thực thi.

2. Anonymize thay vì xóa hẳn. Với dữ liệu cá nhân hết mục đích sử dụng nhưng vẫn muốn giữ số liệu thống kê: ẩn danh hóa — xóa tên, số điện thoại, email, chỉ giữ trường phân tích. Vừa tuân thủ Nghị định 13/2023, vừa không mất dữ liệu kinh doanh.

3. Phân quyền xóa chặt chẽ. Quy tắc vàng: người vận hành backup hàng ngày không nên là người duy nhất có quyền xóa backup. Tách quyền: kỹ thuật viên được tạo và khôi phục; xóa bản archive cần phê duyệt của quản lý. Mọi hành động xóa phải ghi log: ai xóa, bản nào, lý do gì.

Đừng quên ngoại lệ: khi công ty đang trong vụ kiện, kiểm toán hoặc điều tra sự cố, phải có cơ chế legal hold — tạm dừng mọi lịch xóa tự động cho dữ liệu liên quan. Rất nhiều doanh nghiệp để cron xóa "đúng lịch" ngay giữa lúc kiểm toán yêu cầu số liệu 2 năm trước.

Immutable backup: khi lifecycle gặp ransomware

Ransomware hiện đại không chỉ mã hóa dữ liệu chính — chúng chủ động tìm và xóa backup trước khi tống tiền. Kịch bản quen thuộc: mã độc nằm vùng 2–3 tháng, leo thang lấy quyền admin backup, xóa sạch bản sao lưu, rồi mới mã hóa hệ thống chính.

Immutable backup (bản sao lưu bất biến) là câu trả lời: bản backup sau khi ghi sẽ bị khóa chống sửa/xóa trong một khoảng thời gian định trước — kể cả admin cũng không xóa được. Các công nghệ phổ biến:

• Object Lock / retention lock trên object storage (chuẩn S3 Object Lock): đặt chế độ Compliance, object không thể bị xóa cho đến hết hạn.
• WORM tape (Write Once Read Many): băng từ ghi một lần, vật lý không thể ghi đè.
• Air-gapped backup: bản sao lưu ngắt kết nối hoàn toàn khỏi mạng — mã độc không "chạm" tới được.

Mối quan hệ giữa immutable và lifecycle rất tinh tế: thời gian khóa immutable chính là một phần của lifecycle policy. Ví dụ: bản monthly bị khóa 12 tháng — trong 12 tháng đó không ai xóa được; hết 12 tháng, khóa tự gỡ và lifecycle rule bình thường tiếp quản. Đặt khóa quá ngắn thì mất tác dụng chống ransomware nằm vùng; quá dài thì tốn chi phí. Mốc 3–12 tháng cho bản monthly là điểm cân bằng phổ biến.

Lưu ý: immutable chỉ bảo vệ khỏi xóa/sửa sau khi backup đã an toàn. Nếu mã độc đã nằm trong dữ liệu trước khi backup chạy, bản immutable sẽ "khóa" luôn cả dữ liệu nhiễm độc. Vì vậy immutable phải đi kèm test restore định kỳ và giải pháp phát hiện bất thường trước khi backup.

6 sai lầm thường gặp khi đặt lifecycle cho backup

1. Một con số cho tất cả. Đặt "giữ 30 ngày" cho cả database, log, ảnh và chứng từ kế toán. Kết quả: dữ liệu quan trọng giữ quá ngắn, dữ liệu rác giữ quá dài. Luôn phân loại trước khi đặt số.

2. Giữ "mãi mãi cho chắc". Bản backup quá 1–2 năm mà chưa từng được đụng tới thì xác suất cần đến nó cực thấp — trừ khi luật bắt giữ. Hãy để rủi ro và pháp lý quyết định con số, không phải nỗi sợ.

3. Lifecycle chỉ có "xóa", không có "chuyển tầng". Xóa thẳng bản 90 ngày tuổi trong khi có thể chuyển sang archive rẻ gấp 3–4 lần. Quy trình chuẩn là nóng → lạnh → xóa, không phải nóng → xóa.

4. Không test restore. Policy đẹp trên giấy nhưng chưa ai thử khôi phục thật. Quy định bắt buộc: test restore mỗi quý cho dữ liệu lõi, mỗi 6 tháng cho dữ liệu còn lại — và ghi kết quả vào báo cáo.

5. Để một người "ôm" cả tạo lẫn xóa. Vừa chạy backup vừa có quyền xóa toàn bộ kho là rủi ro nhân sự và bảo mật. Tách quyền, bật log xóa, và có người thứ hai phê duyệt khi xóa bản archive.

6. Quên cập nhật policy. Công ty mở thêm chi nhánh, triển khai phần mềm mới — nhưng policy vẫn là bản viết từ 3 năm trước. Rà soát mỗi 6–12 tháng, hoặc ngay khi có thay đổi lớn.

Checklist xây dựng chính sách lifecycle backup mẫu

Dưới đây là khung policy tối giản mà một SME/team kỹ thuật 3–10 người có thể áp dụng ngay. Điền vào bảng, in ra, để ở nơi cả team cùng thấy:

Bước 1: Kiểm kê và phân loại dữ liệu. Liệt kê mọi nguồn dữ liệu, đánh dấu mức độ quan trọng (sống còn / quan trọng / ít quan trọng) và nghĩa vụ pháp lý đi kèm.

Bước 2: Điền bảng retention chuẩn cho từng loại.

*Nếu luật yêu cầu giữ lâu hơn, tuân theo luật.

Bước 3: Tự động hóa. Cấu hình lifecycle rules trên storage (S3 lifecycle, object storage), bật retention lock cho bản monthly quan trọng, tách quyền xóa và bật log.

Bước 4: Test restore định kỳ. Lên lịch test khôi phục mỗi quý, đo thời gian khôi phục thực tế (RTO) và lượng dữ liệu mất (RPO) so với mục tiêu.

Bước 5: Rà soát. Review policy 6 tháng/lần; cập nhật ngay khi có hệ thống mới hoặc quy định pháp luật thay đổi.

Với hạ tầng cloud trong nước, SME có thể triển khai gọn nhẹ: thuê Cloud Server đặt tại datacenter Tier III để chạy workload chính, bật backup tự động theo lịch, và dùng thêm object storage làm tầng archive giá rẻ. Các gói Cloud Server của SunCloud có backup tự động hàng tuần, uptime cam kết 99,98%, dữ liệu lưu trữ trong nước. Gọi hotline 083 979 3434 hoặc xem tại suncloud.vn để được tư vấn cấu hình backup phù hợp.

Kết luận

Chính sách lifecycle backup là ranh giới giữa khôi phục được và mất trắng khi sự cố xảy ra. Nhớ bốn nguyên tắc: phân loại dữ liệu trước khi đặt số, kết hợp GFS với 3-2-1, tự động hóa và tách quyền xóa, không giữ ngắn hơn luật định.

Bắt đầu ngay với checklist 5 bước ở trên: kiểm kê dữ liệu, điền bảng retention, bật automation, lên lịch test restore, hẹn ngày review. Một buổi chiều làm policy nghiêm túc có thể cứu cả công ty khỏi một buổi sáng hoảng loạn vì mất dữ liệu. Cần hạ tầng backup đáng tin cậy trong nước, liên hệ SunCloud qua hotline 083 979 3434 hoặc email sales@suncloud.vn hoặc suncloud.vn.

Bài viết liên quan

• Dịch vụ lưu trữ đám mây SunCloud
• Mã hóa bản backup: đừng để backup thành điểm rò rỉ dữ liệu
• Chiến lược backup 3-2-1 cho doanh nghiệp SME: bắt đầu từ đâu?

Câu hỏi thường gặp

Có nên giữ backup "mãi mãi cho chắc" không?

Không nên, trừ dữ liệu luật bắt giữ vĩnh viễn. Giữ mãi mãi khiến chi phí phình vô hạn và khó quản lý. Hãy đặt retention dựa trên ba căn cứ: mức độ quan trọng, khả năng cần khôi phục bản cũ, và nghĩa vụ pháp lý.

Xóa backup cũ có vi phạm pháp luật không?

Không, nếu thời gian giữ đáp ứng mức tối thiểu luật định (chứng từ kế toán 5–10 năm) và không có legal hold đang hiệu lực. Ngược lại, giữ dữ liệu cá nhân quá thời gian cần thiết có thể vi phạm Nghị định 13/2023/NĐ-CP.

Backup bị ransomware mã hóa thì lifecycle policy có giúp gì không?

Policy thông thường không đủ, vì ransomware có thể xóa cả backup. Cần bổ sung immutable backup (khóa chống xóa) cho bản monthly/quarterly và ít nhất một bản air-gapped ngắt mạng hoàn toàn.

Nên test restore bao lâu một lần?

Dữ liệu lõi: mỗi quý một lần. Dữ liệu còn lại: 6 tháng một lần. Mỗi lần test phải đo RTO/RPO thực tế và ghi báo cáo — backup chưa từng restore thành công thì coi như chưa có backup.

SME 10 người có cần viết policy chính thức không?

Có, và không cần cầu kỳ. Một bảng retention 1 trang A4 (loại dữ liệu – giữ bao lâu – ai duyệt xóa) cộng lifecycle rules tự động trên storage đã là một chính sách hoàn chỉnh ở quy mô SME. Quan trọng là viết ra và cả team cùng tuân thủ.

Log hệ thống nên giữ bao lâu?

Phổ biến là 30–90 ngày online cho vận hành và điều tra sự cố. Nếu thuộc diện chịu Luật An ninh mạng hoặc yêu cầu kiểm toán đặc thù, giữ lâu hơn theo quy định ngành.