1. Restore là thao tác nguy hiểm nhất trong backup
Backup sai thường chưa gây hậu quả ngay.
Restore sai có thể làm mất nốt phần dữ liệu còn lại.
Restore là thao tác không được phép thử–sai trên production.
📌 Vì vậy, restore phải có:
Trình tự rõ ràng
Điểm dừng kiểm tra
Quyết định có chủ đích
2. Nguyên tắc chung trước khi restore
Trước khi bắt đầu restore, bắt buộc phải làm rõ:
Restore cái gì? (file, DB, hay cả hai)
Restore đến thời điểm nào?
Restore ở đâu? (test, staging, production)
Restore toàn bộ hay một phần?
📌 Không trả lời được 4 câu hỏi trên → chưa được phép restore.
3. Restore file – những tình huống thường gặp
3.1. Xóa nhầm file / thư mục
Đặc điểm:
Phát hiện sớm
Phạm vi hẹp
Cách làm đúng:
Restore đúng file
Restore đúng vị trí
Không restore dư dữ liệu
📌 Restore thừa có thể ghi đè dữ liệu mới.
3.2. File bị ghi đè hoặc hỏng nội dung
Cần xác định:
File bị hỏng từ thời điểm nào
Chọn bản backup trước thời điểm đó
📌 Không chọn bản mới nhất theo thói quen.
3.3. Restore file upload cho ứng dụng web
Cần chú ý:
Permission
Ownership
Mapping với database
📌 File đúng nhưng DB không khớp → ứng dụng lỗi.
4. Trình tự restore file an toàn
Trình tự khuyến nghị:
Restore sang thư mục tạm
So sánh dữ liệu
Xác nhận đúng phiên bản
Copy sang vị trí chính thức
Kiểm tra ứng dụng
📌 Không restore trực tiếp đè nếu chưa kiểm tra.
5. Restore database – mức độ rủi ro cao hơn file
Database:
Có logic nghiệp vụ
Có quan hệ dữ liệu
Có nhiều người dùng đồng thời
Restore DB sai = lỗi dây chuyền trên toàn hệ thống.
6. Các kịch bản restore database phổ biến
6.1. Restore toàn bộ database
Dùng khi:
DB hỏng nặng
Lỗi logic lan rộng
Ransomware
Yêu cầu:
Downtime
Phối hợp nghiệp vụ
Thông báo người dùng
6.2. Restore một phần (table / schema)
Dùng khi:
Xóa nhầm table
Lỗi dữ liệu cục bộ
Cần:
Kỹ năng dump/restore chọn lọc
Hiểu cấu trúc DB
📌 Restore chọn lọc nguy hiểm nếu không hiểu quan hệ dữ liệu.
7. Trình tự restore database chuẩn
Trình tự khuyến nghị:
Dừng ứng dụng ghi dữ liệu
Backup trạng thái hiện tại (đề phòng)
Restore DB (hoặc schema/table)
Kiểm tra dữ liệu
Mở lại ứng dụng
Giám sát sau restore
📌 Luôn backup trước khi restore.
8. Restore database từ replication và snapshot
Replication: chỉ dùng để chuyển node
Snapshot: dùng rollback ngắn hạn
📌 Với lỗi logic:
Logical backup (dump) là cứu cánh cuối cùng.
9. Restore file + database cho ứng dụng
Với web/app:
File và DB phải cùng thời điểm
Restore lệch thời điểm → lỗi logic
Trình tự:
Restore DB
Restore file
Clear cache
Test nghiệp vụ
📌 Restore đúng kỹ thuật nhưng sai thứ tự vẫn thất bại.
10. Checkpoint và xác nhận nghiệp vụ
Sau restore:
IT kiểm tra kỹ thuật
Nghiệp vụ kiểm tra dữ liệu
Lãnh đạo xác nhận cho phép mở lại dịch vụ
📌 IT không được tự quyết định “đã xong”.
11. Những sai lầm phổ biến khi restore
Restore trực tiếp lên production
Không backup trước khi restore
Restore bản mới nhất một cách máy móc
Không kiểm tra nghiệp vụ
Không ghi nhận quá trình restore
12. Checklist restore file và database
Trước restore
Xác định phạm vi
Xác định thời điểm
Thông báo liên quan
Trong restore
Có checkpoint
Không ghi đè mù
Ghi log
Sau restore
Kiểm tra dữ liệu
Kiểm tra ứng dụng
Ghi biên bản
13. Liên hệ với hệ thống thực tế
Trong hệ thống:
Website người bệnh
Webapp nội bộ
Database nghiệp vụ
Restore đúng giúp:
Tránh downtime kéo dài
Tránh mất dữ liệu thứ cấp
Giữ uy tín tổ chức
Restore không phải là thao tác kỹ thuật đơn thuần,
mà là quyết định ảnh hưởng trực tiếp đến dữ liệu và con người.
Một tổ chức trưởng thành:
Restore có quy trình
Restore có kiểm soát
Restore có xác nhận nghiệp vụ
- Đăng nhập để gửi ý kiến
