1. Mục tiêu backup cho cụm CMC
Cụm CMC là khu vực Internet-facing, chứa dữ liệu người bệnh và dịch vụ public. Chiến lược backup tại đây tập trung vào:
Bảo vệ dữ liệu database (quan trọng nhất)
Khôi phục nhanh dịch vụ web khi có sự cố
Giảm tối đa rủi ro lan truyền lỗi và ransomware
Không phụ thuộc vào một máy hay một vị trí lưu trữ duy nhất
Nguyên tắc:
Backup tại CMC chỉ là tuyến đầu, không phải tuyến cuối.
2. Phân tách vai trò backup trong cụm CMC
2.1. CMC1C – máy chủ chạy code
Vai trò chính:
Chạy website, web service
Tiếp nhận request từ Internet
Có:
01 ổ 2TB dùng làm backup on-site ngắn hạn
CMC1C không phải nơi lưu trữ backup dài hạn.
2.2. CMC2D – máy chủ database
Vai trò chính:
Lưu trữ dữ liệu người bệnh
Đặc điểm:
Dữ liệu thay đổi liên tục
Mức độ quan trọng cao nhất trong cụm CMC
Tổng dung lượng: 800GB
Đã sử dụng: ~75%
Không đủ an toàn để:
Giữ nhiều file dump
Thực hiện dump lớn, kéo dài
Chịu rủi ro spike dung lượng
Dump chạy trên CMC1C
CMC2D chỉ cung cấp dữ liệu qua kết nối DB
File dump chỉ tồn tại trên ổ 2TB của CMC1C
Không dump và lưu backup lâu trên CMC2D.
3. Backup CMC1C – máy chủ chạy code
3.1. Đối tượng backup
Trên CMC1C chỉ backup những thành phần khó tái tạo, bao gồm:
Cấu hình web server (Nginx/Apache)
Cấu hình PHP, service liên quan
Script vận hành, cronjob
Code đang chạy (để restore nhanh)
dump database của CMC2D
Không coi Git/VCS là backup duy nhất.
3.2. Vị trí và retention backup
Vị trí: ổ 2TB trên chính CMC1C
Mục đích: backup on-site, khôi phục nhanh
Retention khuyến nghị:
Daily: 3–5 bản
Không giữ weekly/monthly tại CMC
Backup cũ sẽ được:
Đẩy sang BV/Desktop
Sau đó xoá khỏi CMC để giảm rủi ro
3.3. Luồng backup CMC1C
Backup cấu hình & code & database (CMC2D) → ổ 2TB local
Kiểm tra checksum / log
Đồng bộ backup sang:
BV (on-site bệnh viện)
Desktop (off-site)
4. Backup CMC2D – máy chủ database
4.1. Chiến lược backup database
Backup database không thực hiện trực tiếp sang Desktop mà theo luồng an toàn:
Dump tại CMC1C --> lưu tại ổ 2T của CMC1C
Từ đó mới đẩy off-site (Bệnh viện)
Mục tiêu:
Tránh mở quyền rộng trên DB server
Giảm rủi ro expose dữ liệu
4.2. Hình thức backup
Logical backup:
mysqldump(mình dùng mariadb)Có timestamp
Có thể bổ sung:
Compression
Encryption (nếu cần)
4.3. Lịch và retention
Lịch dump:
Hourly (đối với DB quan trọng)
Hoặc Daily (tuỳ RPO đã xác định)
Retention tại CMC2D:
Rất ngắn (1–2 bản)
Retention chính:
Tại BV
Tại Desktop
Mình đang cân nhắc replication database trên ổ 2T hoặc trên ổ đag chạy OS (1.3T). Nhưng cần chuyển bớt các site archive/giặc site có file lớn đi chỗ khác.
Mục đích: cần continuously
4.4. Luồng backup database
Dump DB thực hiện tại CMC1C nhưng kết nối qua LAN tới CMC2D
Đồng bộ dump sang:
BV
Desktop
Xoá dump cũ tại CMC1C
5. Phân tách backup code và data giữa CMC1C – CMC2D
5.1. Nguyên tắc bắt buộc
Không backup chéo:
Không dump DB trên CMC1D, Không lưu code trên CMC2D.
Lợi ích:
Giảm bề mặt tấn công
Dễ khoanh vùng sự cố
Dễ restore từng phần
5.2. Kịch bản phục hồi mẫu
CMC1C lỗi:
Dựng máy mới
Restore cấu hình + code từ backup
Kết nối lại DB
CMC2D lỗi:
Dựng DB server mới
Restore DB từ bản dump an toàn
Không cần thay đổi CMC1C
6. Backup từ cụm CMC sang các tuyến sau
6.1. Sang hệ thống bệnh viện (BV)
Mục đích:
Có bản backup on-site thứ hai
Phục hồi nhanh hơn Desktop
Dữ liệu chuyển:
DB dump
Config
Script
6.2. Sang Desktop Windows + WSL
Mục đích:
Bản sao độc lập
Chống ransomware
Nguyên tắc:
Desktop pull backup
Không cho CMC push ngược
7. Kiểm soát an toàn và vận hành
Backup user riêng, không dùng root
SSH key riêng cho backup
Log đầy đủ:
Thời gian
Dung lượng
Trạng thái
Cảnh báo khi:
Backup fail
Thiếu dung lượng
Tổng kết
Backup cho cụm CMC được thiết kế theo hướng:
Nhẹ tại CMC
An toàn ở tuyến sau
Không giữ dữ liệu lâu tại vùng Internet-facing
Cụm CMC:
Không phải kho backup
Chỉ là điểm tạo dữ liệu và điểm tạo bản sao tạm thời
- Đăng nhập để gửi ý kiến
