Kế hoạch khôi phục VPS sau sự cố, bảo vệ dữ liệu toàn diện

Ba giờ sáng, điện thoại báo VPS không phản hồi. Bạn SSH vào thì thấy ổ đĩa đầy, database báo lỗi corrupt, hoặc tệ hơn là toàn bộ dữ liệu đã bị mã hoá tống tiền. Lúc đó có hai loại sysadmin: người đã có kế hoạch khôi phục VPS và dựng lại dịch vụ trong 30 phút, và người ngồi cầu trời cho may mắn. Bài này là cách mình dựng kế hoạch khôi phục VPS sau sự cố theo hướng thực chiến, áp dụng cho VPS Linux (Ubuntu 24.04, Debian 12/13, AlmaLinux 9) và VPS Windows Server, kèm cách bảo vệ dữ liệu để mỗi lần có biến bạn đều biết chính xác phải làm gì.

• Nguyên tắc nền: một bản backup chưa từng restore thử thì không phải backup, đó là hy vọng.
• Ba con số phải chốt trước: RPO (mất tối đa bao nhiêu dữ liệu), RTO (bao lâu phải sống lại), và ngân sách.
• Backup 3-2-1: 3 bản copy, 2 loại lưu trữ khác nhau, 1 bản nằm ngoài VPS (off-site).
• Snapshot không thay backup: snapshot nằm cùng hệ thống, nhà cung cấp lỗi là mất cả chùm.

Vì sao phải có kế hoạch khôi phục, không chỉ backup

Backup trả lời câu hỏi "dữ liệu còn không". Kế hoạch khôi phục trả lời câu hỏi "bao lâu nữa thì dịch vụ sống lại và phải làm đúng thứ tự nào". Hai thứ khác nhau. Mình từng thấy trường hợp có backup đầy đủ nhưng khi cần phục hồi thì không ai nhớ thứ tự mount, không biết `n8n` cần encryption key nằm ở đâu, hay database dump thiếu schema users. Dữ liệu không mất nhưng service chết cả ngày, thiệt hại còn hơn mất vài giờ dữ liệu.

Kế hoạch khôi phục tốt biến sự cố từ "chuyện động trời" thành "tác vụ có checklist". Bạn không cần suy nghĩ nhiều lúc 3 giờ sáng, chỉ cần làm theo thứ tự đã viết sẵn. Đó là lý do bài này không chỉ nói về backup mà còn về phân loại thảm họa, phân vai, và nhật ký kiểm chứng sau khi phục hồi.

Phân loại thảm họa để biết mình chống cái gì

Không phải sự cố nào cũng cần phản ứng giống nhau. Việc đầu tiên khi lập kế hoạch là liệt kê các loại thảm họa có thể xảy ra và mức độ nghiêm trọng với hệ thống của bạn.

• Mất dữ liệu cục bộ: xoá nhầm file, xoá bảng, `rm -rf` sai thư mục. Cần phục hồi nhanh một phần, RTO tính bằng phút.
• Hỏng hệ điều hành: kernel panic, ổ đĩa lỗi, package update làm hỏng bootloader. Cần dựng lại từ image hoặc snapshot.
• Tấn công: ransomware mã hoá dữ liệu, xâm nhập xoá log, brute force leo thang. Cần cô lập rồi phục hồi từ bản sạch.
• Nhà cung cấp gặp sự cố: host node chết, datacenter mất điện kéo dài. Cần bản off-site và khả năng dựng lại ở nơi khác.
• Lỗi con người: deploy sai, cấu hình nhầm, xoá mất volume Docker. Thường gặp nhất và dễ phòng nhất bằng snapshot trước thay đổi.

Mỗi loại thảm họa sẽ quyết định bạn cần loại backup nào, tần suất ra sao, có cần replica sang VPS khác không. Với ransomware thì bản backup nằm cùng máy qua giao thức mount sẵn sẽ bị mã hoá luôn, nên bản off-site là bắt buộc.

Chốt RPO và RTO trước khi chọn công cụ

RPO (Recovery Point Objective) là lượng dữ liệu tối đa bạn chấp nhận mất, đo bằng thời gian. RTO (Recovery Time Objective) là thời gian tối đa để dịch vụ hoạt động lại. Hai con số này quyết định toàn bộ thiết kế phía sau, và chúng thường xung đột với ngân sách. RPO 5 phút thì phải replica liên tục, tốn tiền. RPO 24 giờ thì một bản dump mỗi ngày là đủ.

Mẹo thực tế: đừng đặt RPO 5 phút cho mọi thứ. Phân tầng dữ liệu rồi mới chọn tần suất. Hệ thống nhỏ thường chỉ cần RPO database 1 giờ cộng file 6 giờ là đủ, chi phí giảm mạnh mà rủi ro chấp nhận được.

Backup 3-2-1: dựng lớp bảo vệ dữ liệu

Nguyên tắc 3-2-1 là chuẩn được hầu hết nhà cung cấp hạ tầng lớn khuyến nghị: giữ 3 bản copy dữ liệu, trên 2 loại phương tiện khác nhau, với 1 bản nằm off-site. Trên một VPS, bạn dựng nó như sau.

# 1) Snapshot tại nhà cung cấp: nhanh, cùng hệ thống (bản copy 1)
#    Dùng snapshot trước mọi thay đổi lớn, giữ tối đa vài ngày.

# 2) Backup csdl ra file rồi đẩy lên object storage off-site (bản copy 2)
mysqldump --single-transaction --routines --triggers \
  -u root -p wordpress_db | gzip > /root/backup/db-$(date +%F).sql.gz

# 3) Đẩy off-site bằng restic (mã hoá, versioned, dedupe)
restic -r s3:s3.example.com/thuevps-backup backup /root/backup /etc /var/www
restic snapshots

# 4) Bản copy 3: giữ một máy/VPS khác hoặc NAS chỉ để nhận backup
rsync -az --delete /root/backup/ [email protected]:/srv/vps-backup/

Điểm quan trọng nhất là bản off-site phải nằm khác tài khoản, khác nhà cung cấp hoặc khác mạng. Nếu mọi bản backup đều nằm trong cùng một tài khoản cloud, một lần lộ credential là mất hết. Với những hệ thống quan trọng, bạn có thể thuê VPS ở nhà cung cấp khác chỉ để làm nơi nhận backup, hoặc dùng máy chủ riêng làm kho lưu trữ nội bộ.

Cũng nên mã hoá trước khi đẩy lên: restic và borgbackup mã hoá client-side, kể cả nhà cung cấp lưu trữ cũng không đọc được nội dung. Cách này đặc biệt quan trọng cho dữ liệu khách hàng trên VPS WordPress hay hệ thống VPS n8n chứa nhiều credential workflow.

Snapshot và backup khác nhau ở đâu

Snapshot là ảnh chụp trạng thái ổ đĩa tại một thời điểm, thường lưu ngay trong hạ tầng của nhà cung cấp. Nó khôi phục cực nhanh, vài phút, nhưng nằm cùng hệ thống với VPS đang chạy, nên không phải bản sao an toàn để chống thảm họa toàn diện.

Cách mình dùng: snapshot như "nút undo" cho mỗi lần nâng cấp kernel, đổi cấu hình Nginx, update database. Còn backup off-site là lưới an toàn cuối. Snapshot không tính là backup trong kế hoạch phục hồi, chỉ là công cụ giảm rủi ro thao tác.

Checklist khôi phục VPS sau sự cố theo thứ tự

Khi sự cố thật xảy ra, đừng sửa ngay. Việc đầu tiên là giữ nguyên hiện trạng để điều tra, rồi mới phục hồi. Quy trình dưới đây áp dụng cho cả VPS Linux lẫn VPS Windows.

1. Cô lập: nếu nghi ngờ bị xâm nhập, chặn luồng tấn công trước khi phục hồi. Đổi mật khẩu/SSH key, siết firewall, hoặc tạm tắt dịch vụ bị ảnh hưởng.
2. Xác định mốc thời gian: dữ liệu cuối cùng còn sạch là khi nào. Đây là mốc để chọn bản backup.
3. Chọn bản backup: kiểm tra tính toàn vẹn bằng checksum hoặc lệnh verify của restic/borg.
4. Khôi phục vào môi trường tạm: đừng ghi đè lên VPS hỏng ngay. Dựng lại vào VPS sạch hoặc thư mục riêng để kiểm tra.
5. Kiểm tra dữ liệu: so sánh số bản ghi, chạy thử ứng dụng, kiểm tra file mới nhất có đúng không.
6. Chuyển traffic: chỉ sau khi môi trường tạm OK mới đổi DNS hoặc trỏ người dùng sang.
7. Ghi nhật ký và rút kinh nghiệm: ghi lại mốc thời gian, nguyên nhân, thời gian phục hồi thực tế so với RTO.

# Kiểm tra toàn vẹn backup restic trước khi restore
restic -r s3:s3.example.com/thuevps-backup check --read-data

# Xem danh sách snapshot để chọn mốc thời gian
restic snapshots --latest 20

# Restore vào thư mục riêng để kiểm tra, chưa ghi đè
restic restore latest --target /srv/restore-test

# Nếu khôi phục VM từ snapshot provider: tạo VPS mới từ snapshot,
# mount / kiểm tra /etc, /var/www, database trước khi đổi DNS.

Sau khi phục hồi xong, luôn kiểm tra log hệ thống xem có dấu hiệu tấn công còn sót, và xoay toàn bộ credential (SSH key, mật khẩu database, API token) vì bản backup có thể chứa credential cũ đã bị lộ. Với VPS Windows, kiểm tra thêm user local, scheduled task ẩn và rule firewall lạ.

Diễn tập restore định kỳ, phần ai cũng bỏ qua

Đây là chỗ 90% kế hoạch khôi phục thất bại. Bạn có backup, nhưng chưa từng restore, nên không biết script nào lỗi, key nào thiếu, hay dung lượng thực tế lớn hơn dự kiến. Cách chữa rất đơn giản: mỗi quý một lần, dựng một VPS tạm và restore thật.

# Diễn tập: restore vào VPS tạm, đo thời gian thực tế
time restic restore latest --target /srv/drill

# Xác nhận dịch vụ chạy được sau restore
systemctl start mariadb nginx
curl -I http://localhost
mysql -e "SELECT COUNT(*) FROM wordpress_db.wp_posts;"

Ghi lại thời gian restore thực tế, so với RTO bạn đặt. Nếu chậm hơn, hoặc thiếu dữ liệu, đó chính là lúc phát hiện chứ không phải 3 giờ sáng ngày có sự cố thật. Diễn tập xong nên cập nhật lại checklist, vì quy trình luôn có chi tiết mới lộ ra khi làm thật.

Một mẹo mình hay dùng: gắn nhãn cho backup theo ngày và theo phiên bản ứng dụng. Khi cần quay về bản cũ do lỗi deploy, bạn biết ngay bản nào khớp với phiên bản code nào, không phải mò.

Vài lưu ý để kế hoạch không chết trên giấy

Kế hoạch khôi phục VPS chỉ hiệu quả khi nó đơn giản và được kiểm tra thường xuyên. Mình đúc kết vài điểm sau từ những lần phải phục hồi thật.

• Tách quyền: tài khoản chạy backup không nên có quyền xoá bản backup. Với object storage, bật versioning và object lock nếu có, để ransomware không xoá được bản cũ.
• Giám sát chính việc backup: job backup lỗi âm thầm là kịch bản tồi nhất. Cho script backup báo Telegram/email khi thành công và thất bại.
• Đừng phụ thuộc một thứ: nhiều bạn chỉ dựa vào snapshot của nhà cung cấp. Host node lỗi hoặc tài khoản bị tạm khoá là hết đường. Luôn có ít nhất một bản off-site.
• Ghi lại mọi thứ cần thiết để dựng lại: danh sách package, cấu hình service, cron/systemd timer, biến môi trường. Với các hệ thống như GitLab hay WordPress, nhớ cả file config và encryption key.

Nếu bạn cần một máy riêng đóng vai kho backup và môi trường diễn tập restore, chọn hạ tầng đúng chỗ sẽ giúp ích. Một VPS Linux có snapshot và IPv4 riêng đặt tại Việt Nam, hoặc VPS Windows với RDP Administrator toàn quyền, đều đủ để vừa chạy dịch vụ vừa giữ bản backup tách biệt. Quan trọng hơn cả cấu hình là thói quen kiểm tra restore đều đặn.

Câu hỏi thường gặp

Bài viết liên quan

• Cách tạo snapshot và khôi phục VPS an toàn
• Cách backup VPS trước khi nâng cấp an toàn
• Hướng dẫn backup tự động VPS lên S3 với restic
• Cách xử lý VPS bị full disk hiệu quả trên Linux