11. Tổng kết mô hình backup thực tế

1. Mục tiêu của mô hình backup

Mô hình backup này không nhằm đạt:

• Zero downtime

• Hạ tầng phức tạp

• Công nghệ đắt tiền

Mục tiêu thực sự là:

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

• Duy trì được dịch vụ

• Xử lý được sự cố thật

• Phù hợp với điều kiện vận hành thực tế

Đây là mô hình dành cho hệ thống đang chạy, không phải môi trường lab.

2. Tổng quan kiến trúc backup đã triển khai

Mô hình được xây dựng dựa trên kiến trúc nhiều lớp:

• CMC (public services)

  • Tách code và database

  • Backup nhẹ, không lưu dài hạn

• Bệnh viện (internal services)

  • Primary – Standby (BV1 – BV2)

  • Failover nhanh

• Desktop Windows + WSL

  • Backup độc lập

  • Tuyến phòng thủ cuối cùng

Toàn bộ được liên kết bằng:

• Backup

• Replication

• Failover
  nhưng không đánh đồng vai trò của chúng.

3. Những điểm mạnh của mô hình

3.1. Phân lớp rõ ràng

• Vận hành (on-site)

• An toàn (on-site + off-site)

• Thảm họa (off-site độc lập)

Mỗi lớp có:

• Mục tiêu riêng

• Dữ liệu riêng

• Retention riêng

3.2. Áp dụng 3-2-1 đúng nghĩa

• 3 bản sao

• 2 loại lưu trữ

• 1 bản ngoài hệ thống

Không hình thức, không chạy theo khẩu hiệu.

3.3. Không phụ thuộc một điểm duy nhất

• Không phụ thuộc:

  • BV2

  • RAID

  • Replication

• Desktop backup là đường lui cuối cùng

3.4. Phù hợp với nhân sự CNTT bệnh viện

• Không yêu cầu:

  • Cluster phức tạp

  • SAN / DR Site đắt tiền

• Có thể vận hành bằng:

  • Script

  • SOP

  • Checklist

4. Những điểm cần kiểm soát chặt

4.1. Backup ≠ Replication

• BV2 không phải backup

• RAID không phải backup

• Replication không thay thế backup

Nhầm lẫn ở đây là rủi ro lớn nhất.

4.2. Desktop backup phải được bảo vệ

• Không dùng Desktop như máy làm việc

• Không mount ngược

• Không cho server push backup

Desktop an toàn → toàn hệ thống còn cơ hội.

4.3. Dung lượng và retention

• 12TB tại BV:

  • Dễ đầy nếu không kiểm soát

• 2×2TB tại Desktop:

  • Buộc phải backup chọn lọc

Backup càng nhiều chưa chắc càng an toàn.

4.4. Test restore định kỳ

• Backup không test = backup giả

• Test restore phải:

  • Có lịch

  • Có biên bản

  • Có cải tiến sau test

5. Giá trị thực tế của mô hình

Mô hình này giúp:

• Giảm phụ thuộc cá nhân

• Giảm hoảng loạn khi sự cố

• Chủ động xử lý ransomware

• Khôi phục hệ thống trong điều kiện xấu nhất

Đặc biệt:

Không cần đầu tư lớn nhưng vẫn có khả năng phục hồi thảm họa.

6. Khi nào cần mở rộng mô hình?

Mô hình hiện tại đủ tốt cho:

• Hệ thống quy mô vừa

• Đội CNTT gọn

• Ngân sách hạn chế

Chỉ nên mở rộng khi:

• Dữ liệu tăng mạnh

• RPO/RTO yêu cầu cao hơn

• Có DR site chuyên biệt

7. Bài học rút ra quan trọng nhất

1. Backup là quy trình, không phải thiết bị

2. Failover giúp chạy tiếp, không cứu dữ liệu

3. Ransomware chỉ sợ backup độc lập

4. Kịch bản sự cố phải viết trước khi cần dùng

5. Desktop backup nhỏ nhưng cứu cả hệ thống

Kết luận cuối cùng

Mô hình backup thực tế này:

• Không hoàn hảo

• Nhưng thực dụng

• Có thể vận hành lâu dài

• Và có thể cứu hệ thống khi cần

Đây chính là mục tiêu cao nhất của backup.