Bài 32.1. Backup database và đồng bộ hóa (Replication vs Backup)

1. Vì sao Replication và Backup thường bị nhầm lẫn?

Trong nhiều hệ thống database hiện nay:

• Có primary – replica

• Có failover

• Có HA

Và từ đó xuất hiện suy nghĩ rất nguy hiểm:

“Database đã replication rồi, không cần backup nữa.”

Thực tế cho thấy:

• Rất nhiều sự cố nghiêm trọng

• Xảy ra trên hệ thống có replication đầy đủ

• Nhưng không thể phục hồi dữ liệu

📌 Nguyên nhân cốt lõi là nhầm lẫn giữa hai khái niệm hoàn toàn khác nhau:

• Tính sẵn sàng (Availability)

• Khả năng phục hồi (Recoverability)

2. Replication là gì trong bối cảnh database?

2.1. Bản chất của replication

Replication là:

• Đồng bộ dữ liệu gần như thời gian thực

• Giữa các database node

• Phục vụ tính sẵn sàng và hiệu năng

Ví dụ:

• MySQL replication

• PostgreSQL streaming replication

• Multi-node cluster

📌 Replication trả lời câu hỏi:

“Nếu một node chết, hệ thống còn chạy không?”

2.2. Replication KHÔNG làm được gì?

Replication:

• Không giữ lịch sử lâu dài

• Không bảo vệ khỏi lỗi logic

• Không chống được xóa nhầm

• Không chống được ransomware

• Không phục hồi được dữ liệu quá khứ

📌 Replication nhân bản cả lỗi.

3. Backup database là gì trong bối cảnh kiến trúc hệ thống?

Backup database:

• Lưu trạng thái dữ liệu tại một thời điểm

• Tạo bản sao độc lập

• Giữ được lịch sử

Backup trả lời câu hỏi:

“Nếu dữ liệu bị hỏng, tôi có thể quay lại trạng thái trước đó không?”

📌 Backup là nền tảng của khả năng phục hồi.

4. So sánh Replication và Backup

📌 Replication không bao giờ thay thế backup.

5. Các kịch bản mà replication thất bại hoàn toàn

5.1. Xóa nhầm dữ liệu

• DELETE nhầm bảng

• UPDATE sai điều kiện

→ Replication nhân bản lỗi sang tất cả node

5.2. Lỗi ứng dụng

• Bug logic ghi dữ liệu sai

• Ghi đè dữ liệu hợp lệ

→ Replication làm lỗi lan nhanh hơn

5.3. Ransomware / phá hoại nội bộ

• Dữ liệu bị mã hóa

• Replication đồng bộ mã hóa sang replica

5.4. Lỗi nghiệp vụ phát hiện muộn

• Phát hiện sau vài ngày / vài tuần

→ Replication không có điểm quay lại

6. Khi nào replication là cần thiết?

Replication rất cần thiết khi:

• Yêu cầu uptime cao

• Không được downtime

• Cần đọc phân tán

• Giảm tải node chính

📌 Replication phục vụ vận hành liên tục, không phục vụ phục hồi dữ liệu.

7. Khi nào backup là không thể thiếu?

Backup database là bắt buộc khi:

• Có dữ liệu nghiệp vụ

• Có yêu cầu pháp lý

• Có nguy cơ lỗi logic

• Có rủi ro con người

• Có ransomware

📌 Hệ thống không có backup = hệ thống không có khả năng phục hồi.

8. Mô hình kiến trúc đúng: Replication + Backup

Một kiến trúc database đúng không chọn một trong hai, mà kết hợp:

8.1. Replication để:

• Duy trì dịch vụ

• Giảm downtime

• Tăng availability

8.2. Backup để:

• Phục hồi dữ liệu

• Quay lại quá khứ

• Đáp ứng DR, audit, legal

📌 Hai vai trò bổ sung, không cạnh tranh.

9. Backup nên lấy từ đâu trong hệ thống replication?

Thực tế tốt:

• Backup từ replica

• Không backup trực tiếp primary

Lợi ích:

• Giảm tải production

• An toàn hơn

• Dễ quản lý lịch backup

📌 Nhưng replica vẫn cần backup logic đầy đủ.

10. Replication không có retention – Backup thì có

Replication:

• Không có khái niệm “giữ 7 ngày trước”

• Không có snapshot logic lịch sử

Backup:

• Có retention policy

• Có version

• Có khả năng chọn thời điểm restore

📌 Retention = Backup, không phải Replication.

11. Sai lầm phổ biến trong kiến trúc database

• Dùng replication thay backup

• Tin rằng cluster là đủ

• Không có dump logic

• Không test restore

📌 Rất nhiều hệ thống HA vẫn mất dữ liệu vĩnh viễn vì không có backup.

12. Checklist phân biệt nhanh

Replication dùng để

• Giữ hệ thống chạy

• Chuyển node nhanh

• Giảm downtime

Backup dùng để

• Khôi phục dữ liệu

• Quay lại quá khứ

• Chống lỗi logic & ransomware

Replication giúp hệ thống không ngừng chạy.
Backup giúp dữ liệu không biến mất.

Một kiến trúc database trưởng thành:

• Luôn có replication và

• Luôn có backup logic, off-site, có retention

Nếu phải chọn:

Thà downtime còn hơn mất dữ liệu.

Và chỉ backup đúng nghĩa mới bảo đảm điều đó.