Thông báo “backup thành công” chỉ xác nhận một job đã chạy theo điều kiện của công cụ. Nó chưa chứng minh file có đủ dữ liệu, khóa giải mã còn dùng được, database nhất quán hay đội vận hành biết cách đưa hệ thống trở lại.
Một bản backup chỉ thực sự có giá trị khi doanh nghiệp đã kiểm tra rằng nó có thể khôi phục trong thời gian chấp nhận được.
Backup có thể thất bại dù job báo thành công
Các tình huống thường gặp gồm:
- Job sao chép đúng thư mục nhưng dữ liệu quan trọng nằm ở volume khác.
- Dump database tạo ra file nhưng file rỗng, thiếu quyền hoặc lỗi giữa chừng.
- Bản backup được mã hóa nhưng khóa giải mã chỉ nằm trên VPS đã mất.
- File được lưu nhưng không có cấu hình ứng dụng, secret hoặc hướng dẫn dựng lại.
- Backup nằm trên cùng VPS hoặc cùng tài khoản cloud nên mất cùng lúc với nguồn.
- Retention quá ngắn khiến lỗi âm thầm đã ghi đè mọi bản tốt.
- Phiên bản phần mềm mới không đọc được định dạng backup cũ như kỳ vọng.
Vì vậy, dung lượng file và trạng thái job không phải tiêu chí nghiệm thu cuối cùng.
Xác định điều gì cần được khôi phục
Đừng bắt đầu bằng câu hỏi “dùng công cụ backup nào”. Hãy lập danh sách thành phần cần để dịch vụ hoạt động trở lại:
- Database và dữ liệu upload của người dùng.
- File cấu hình, biến môi trường và secret theo cơ chế lưu trữ an toàn.
- Mã nguồn hoặc artifact có thể triển khai lại.
- Cấu hình reverse proxy, SSL, DNS và firewall.
- Docker Compose, image version hoặc manifest triển khai.
- Tài liệu về thứ tự phục hồi và người có quyền truy cập.
Một số thành phần có thể tái tạo từ Git hoặc automation; số khác là dữ liệu duy nhất và phải được backup. Việc phân loại giúp tránh sao chép dư thừa nhưng bỏ sót phần quan trọng.
RPO và RTO bằng ngôn ngữ thực tế
RPO trả lời câu hỏi: doanh nghiệp chấp nhận mất tối đa bao nhiêu dữ liệu? Nếu backup mỗi 24 giờ, trong tình huống xấu có thể mất gần một ngày dữ liệu.
RTO trả lời câu hỏi: dịch vụ có thể ngừng trong bao lâu trước khi ảnh hưởng vượt mức chấp nhận? RTO hai giờ đòi hỏi quy trình, quyền truy cập và hạ tầng dự phòng khác hẳn RTO hai ngày.
Không nên chọn RPO/RTO chỉ vì con số nghe tốt. Mức càng thấp thường càng tăng chi phí lưu trữ, tự động hóa và nguồn lực trực vận hành.
Cách tổ chức một lần thử khôi phục
1. Chọn phạm vi và tình huống
Bắt đầu với một tình huống có giá trị: mất database, mất toàn bộ VPS hoặc cần khôi phục một file do người dùng xóa nhầm. Ghi rõ điểm thời gian cần phục hồi và tiêu chí thành công.
2. Dùng môi trường cách ly
Không restore đè lên production để “thử”. Dùng VPS tạm, môi trường staging hoặc vị trí cách ly, đồng thời kiểm soát để dữ liệu thật không vô tình gửi email hay gọi tích hợp bên ngoài.
3. Thực hiện theo tài liệu hiện có
Người thực hiện nên làm theo runbook thay vì dựa hoàn toàn vào trí nhớ của người tạo backup. Ghi lại bước thiếu, quyền truy cập không có và thời gian chờ nhà cung cấp.
4. Kiểm tra tính đúng đắn của dữ liệu
Ứng dụng khởi động chưa đủ. Cần kiểm tra số lượng bản ghi, file quan trọng, khả năng đăng nhập, các giao dịch mẫu và quan hệ giữa database với dữ liệu upload.
5. Đo thời gian và cập nhật quy trình
So sánh thời gian thực tế với RTO. Sau lần thử, sửa runbook, bổ sung quyền truy cập dự phòng và lên lịch kiểm tra tiếp theo.
Tần suất kiểm tra phù hợp
Không có một lịch áp dụng cho mọi hệ thống. Hệ thống thay đổi thường xuyên hoặc có dữ liệu quan trọng cần kiểm tra nhiều hơn. Có thể bắt đầu bằng:
- Kiểm tra tự động tính toàn vẹn sau mỗi job nếu công cụ hỗ trợ.
- Khôi phục mẫu một phần theo tháng.
- Thử khôi phục đầy đủ theo quý hoặc sau thay đổi kiến trúc lớn.
- Kiểm tra ngay sau khi đổi công cụ, storage, khóa mã hóa hoặc retention.
Kết quả cần được lưu cùng ngày thử, bản backup đã dùng, thời gian hoàn thành và vấn đề phát hiện.
Checklist đánh giá backup
- ☐ Biết rõ dữ liệu và cấu hình nào được bảo vệ.
- ☐ Có ít nhất một bản sao tách khỏi hệ thống nguồn.
- ☐ Có cảnh báo khi job lỗi hoặc không chạy đúng lịch.
- ☐ Retention phù hợp với loại lỗi cần phục hồi.
- ☐ Khóa mã hóa và quyền truy cập có phương án dự phòng.
- ☐ Runbook restore đã được một người khác kiểm tra.
- ☐ Đã đo thời gian phục hồi và đối chiếu với RTO.
- ☐ Lịch thử khôi phục tiếp theo đã được xác định.
Server Health Check có thể giúp doanh nghiệp rà soát cấu hình backup hiện tại và chỉ ra những điểm chưa thể kiểm chứng trước khi xây một kế hoạch phục hồi đầy đủ hơn.