Bài 2. Backup ≠ Restore ≠ Disaster Recovery

1. Ba khái niệm quen thuộc nhưng thường bị đánh đồng

Trong rất nhiều hệ thống CNTT, khi hỏi:

“Hệ thống có an toàn không?”

Câu trả lời thường là:

“Có backup rồi.”

Câu trả lời này chưa đủ, thậm chí có thể gây ảo tưởng an toàn, bởi vì:

Backup, Restore và Disaster Recovery là ba năng lực hoàn toàn khác nhau.

Việc nhầm lẫn ba khái niệm này là nguyên nhân trực tiếp dẫn đến thất bại khi sự cố thực sự xảy ra.

2. Backup là gì – và giới hạn của backup

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

Backup là:

• Tạo bản sao dữ liệu hoặc cấu hình

• Lưu trữ ở vị trí khác

• Với mục tiêu phục hồi về sau

Backup chỉ trả lời một câu hỏi:

“Chúng ta có bản sao dữ liệu hay không?”

Backup không trả lời:

• Dựng lại hệ thống thế nào

• Ai thực hiện restore

• Mất bao lâu để hệ thống hoạt động lại

📌 Backup là điều kiện cần, nhưng hoàn toàn chưa đủ.

2.2. Một hệ thống “có backup” nhưng vẫn thất bại

Ví dụ thực tế:

• Có file dump database

• Có bản sao thư mục files

• Nhưng:

  • Không có server sẵn sàng

  • Không có cấu hình web server

  • Không nhớ phiên bản PHP

  • Không có SSL

→ Backup tồn tại, nhưng hệ thống không thể hoạt động lại.

3. Restore là gì – và vì sao restore mới là thước đo thật

3.1. Restore là hành động, không phải khái niệm

Restore là:

• Quá trình sử dụng backup

• Để khôi phục dữ liệu hoặc dịch vụ

• Trong điều kiện hệ thống cụ thể

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

“Chúng ta có thể dùng backup để quay lại trạng thái chấp nhận được hay không?”

3.2. Restore luôn gắn với thời gian

Restore không chỉ là “có làm được hay không”, mà là:

• Restore trong bao lâu

• Restore với mức độ đầy đủ nào

Hai chỉ số bắt buộc:

• RPO (Recovery Point Objective)
  → Mất dữ liệu tối đa bao lâu?

• RTO (Recovery Time Objective)
  → Bao lâu thì hệ thống chạy lại?

📌 Một bản restore mất 2 ngày có thể là thảm họa với hệ thống 24/7, dù backup hoàn hảo.

3.3. Không test restore = không có restore

Rất nhiều tổ chức:

• Có backup hàng ngày

• Nhưng chưa từng:

  • Dựng lại hệ thống từ đầu

  • Restore trên server khác

  • Diễn tập sự cố thật

📌 Khi chưa test restore, restore chỉ tồn tại trong suy nghĩ.

4. Disaster Recovery (DR) là gì – và vì sao đây là cấp độ cao hơn

4.1. DR không phải là restore lớn hơn

Disaster Recovery không phải:

• Restore toàn bộ dữ liệu

• Hay backup nhiều hơn

DR là:

Khả năng duy trì hoặc khôi phục dịch vụ khi xảy ra thảm họa lớn.

Ví dụ thảm họa:

• Mất toàn bộ server

• Cháy trung tâm dữ liệu

• Mất điện, mất mạng diện rộng

• Ransomware toàn hệ thống

4.2. DR tập trung vào dịch vụ, không chỉ dữ liệu

Khác với backup:

• Backup quan tâm đến dữ liệu

• DR quan tâm đến:

  • Người dùng có truy cập được không

  • Dịch vụ có tiếp tục hay không

  • Hệ thống có thể chuyển sang nơi khác không

DR bao gồm:

• Kiến trúc dự phòng

• Failover

• Reverse proxy

• Replication

• Kịch bản vận hành khi khủng hoảng

5. So sánh trực tiếp: Backup – Restore – DR

6. Một hệ thống an toàn phải có đủ cả ba

Một hệ thống trưởng thành cần:

1. Backup tốt
   → Có dữ liệu để quay lại

2. Restore được
   → Có khả năng phục hồi thực tế

3. DR phù hợp
   → Có thể tiếp tục phục vụ khi sự cố lớn

Thiếu một trong ba:

• Có backup nhưng không restore → thất bại

• Restore được nhưng không DR → downtime kéo dài

• DR nhưng backup kém → phục hồi sai dữ liệu

7. Liên hệ với hệ thống thực tế (bệnh viện, dịch vụ công)

Trong môi trường:

• Phục vụ người bệnh

• Phục vụ cán bộ

• Hoạt động liên tục

Thực tế cần:

• Backup để bảo toàn dữ liệu

• Restore để xử lý sự cố kỹ thuật

• DR để đảm bảo không gián đoạn dịch vụ thiết yếu

📌 DR không phải xa xỉ, mà là mức tối thiểu cho hệ thống quan trọng.

Backup là điều kiện cần.
Restore là năng lực bắt buộc.
Disaster Recovery là sự trưởng thành của hệ thống.

Nếu chỉ dừng ở backup, hệ thống mới chỉ ở mức “hy vọng”.
Khi có restore và DR, hệ thống mới thực sự “chủ động trước rủi ro”.