Bài 6. Các nguyên tắc backup cốt lõi

1. Backup phải phục vụ phục hồi, không phải phục vụ “cho có”

Nguyên tắc quan trọng nhất:

Backup chỉ có giá trị khi có thể restore thành công trong điều kiện thực tế.

Một bản backup:

• Không restore được

• Restore quá chậm

• Restore sai dữ liệu

→ đều được xem là backup thất bại.

📌 Khi thiết kế backup, phải bắt đầu từ kịch bản restore, không phải từ công cụ backup.

2. Phải xác định rõ dữ liệu nào là sống còn

Không phải mọi dữ liệu đều có giá trị như nhau.

Cần phân loại:

• Dữ liệu nghiệp vụ cốt lõi

• Dữ liệu vận hành

• Dữ liệu có thể tái tạo

Nguyên tắc:

Backup tập trung vào thứ không thể tái tạo.

Backup lan man làm:

• Tốn tài nguyên

• Khó phục hồi

• Tăng rủi ro sai sót

3. Backup phải độc lập với hệ thống đang chạy

Một backup đúng nghĩa:

• Không phụ thuộc server production

• Không phụ thuộc cùng storage

• Không phụ thuộc cùng quyền ghi

📌 Backup phải tồn tại ngay cả khi hệ thống chính không còn.

4. Phải có nhiều bản backup theo thời gian

Backup chỉ có 1 bản là không đủ.

Nguyên tắc:

• Có lịch sử

• Có thể quay lại nhiều mốc

• Không ghi đè mù quáng

📌 Mất dữ liệu hiếm khi được phát hiện ngay lập tức.

5. Backup phải được bảo mật như dữ liệu gốc

Backup thường chứa:

• Toàn bộ dữ liệu nhạy cảm

• Cấu hình hệ thống

• Thông tin truy cập

Nguyên tắc:

• Mã hóa backup

• Phân quyền chặt chẽ

• Không để lộ key

📌 Backup bị lộ = lộ toàn bộ hệ thống.

6. Backup phải được tự động hóa nhưng có kiểm soát

Backup thủ công:

• Dễ quên

• Dễ sai

• Không ổn định

Backup tự động:

• Phải có log

• Phải có cảnh báo

• Phải kiểm soát dung lượng

📌 Tự động hóa không đi kèm giám sát là rủi ro tiềm ẩn.

7. Restore phải được kiểm tra định kỳ

Không test restore:

• Không biết backup có dùng được không

• Không biết thiếu gì khi phục hồi

Nguyên tắc:

Test restore định kỳ là một phần của backup.

8. Backup phải gắn với RPO và RTO

Backup không thể thiết kế trong chân không.

Phải trả lời:

• Chấp nhận mất bao nhiêu dữ liệu?

• Chấp nhận downtime bao lâu?

Nguyên tắc:

• RPO quyết định tần suất backup

• RTO quyết định kiến trúc phục hồi

9. Backup không thay thế các biện pháp khác

Backup:

• Không thay thế HA

• Không thay thế security

• Không thay thế monitoring

Nguyên tắc:

Backup là lớp bảo vệ cuối cùng, không phải lớp duy nhất.

10. Backup phải có người chịu trách nhiệm rõ ràng

Một backup không ai chịu trách nhiệm là backup thất bại.

Nguyên tắc:

• Có owner

• Có tài liệu

• Có người được đào tạo

📌 Backup là năng lực tổ chức, không phải kỹ năng cá nhân.

11. Backup phải phù hợp với quy mô và thực tế vận hành

Không có giải pháp backup “chuẩn cho mọi nơi”.

Nguyên tắc:

• Phù hợp hệ thống

• Phù hợp nhân lực

• Phù hợp ngân sách

Backup phức tạp vượt khả năng vận hành sẽ sớm bị bỏ quên.

Backup không phải là việc sao chép dữ liệu,
mà là xây dựng năng lực phục hồi có kiểm soát.

Mọi công cụ, mọi mô hình backup chỉ có ý nghĩa khi:

• Phục vụ phục hồi

• Được kiểm tra

• Được duy trì lâu dài