Trả lời nhanh: Sau khi WordPress bị nhiễm malware, không nên restore ngay từ backup nếu chưa biết thời điểm nhiễm và chưa kiểm tra bản backup. Cách an toàn là xác định mốc nhiễm, restore trên staging, quét file/database/uploads/user/cron, kiểm thử chức năng, rồi mới quyết định phục hồi production.
Bài này nối tiếp bước theo dõi WordPress sau khi xử lý malware. Backup là phao cứu sinh, nhưng nếu chọn sai bản backup, doanh nghiệp có thể khôi phục lại chính backdoor, user lạ, URL spam hoặc redirect độc hại đã khiến website bị nhiễm từ đầu.
Vì sao không nên restore mù từ backup?
Restore vội có thể làm mất bằng chứng điều tra, ghi đè log, xóa dấu hiệu về tài khoản bị lộ và đưa mã độc quay lại. Nhiều website bị nhiễm trong nhiều ngày hoặc nhiều tuần trước khi chủ site phát hiện, nên bản backup gần nhất chưa chắc là bản sạch.
Các loại backup cần kiểm tra
| Loại backup | Cần kiểm tra | Vì sao quan trọng |
|---|---|---|
| File backup | wp-content, theme, plugin, file PHP lạ, file mới sửa | Backup file có thể đã chứa backdoor hoặc mã chèn lại |
| Database backup | users, options, posts, widgets, redirect, cron/action scheduler | Mã độc có thể nằm trong database chứ không chỉ trong file |
| Uploads/media | PHP trong uploads, file lạ, ảnh/JS bị đổi tên | Uploads thường bị lợi dụng vì ít người kiểm tra |
| Plugin/theme | phiên bản, nguồn tải, license, file sửa tay | Restore lại plugin/theme nhiễm sẽ tái nhiễm |
| Backup offsite | ngày tạo, retention, khả năng tải về, log backup | Cần bản nằm ngoài hosting nếu hosting đã bị xâm nhập |
Bước 1: xác định thời điểm bắt đầu nhiễm
Cần so sánh ngày file bị sửa, log đăng nhập, log upload, cảnh báo hosting, Search Console, thời điểm Google index URL lạ và phản hồi của khách hàng. Mốc này giúp chọn bản backup trước khi nhiễm, thay vì chọn bản mới nhất nhưng đã bẩn.
Bước 2: restore trên staging trước
Không nên restore trực tiếp lên website đang chạy. Hãy đưa bản backup lên staging hoặc môi trường tách biệt, tắt index, chặn gửi email ra ngoài, rồi kiểm tra file, database, user, cron và các chức năng chính. Staging giúp thử restore mà không gây thêm rủi ro cho khách truy cập.
Bước 3: quét file, database và uploads
File backup cần được quét backdoor, file PHP lạ, mã obfuscate, file mới sửa và plugin/theme không rõ nguồn. Database cần rà user admin, option lạ, script trong post/widget, redirect, cron/action scheduler và URL spam. Thư mục uploads cần kiểm tra riêng vì đây là nơi mã độc hay ẩn nấp.
Bước 4: test chức năng sau restore
Sau khi staging sạch, cần test đăng nhập, form liên hệ, đơn hàng, thanh toán, email SMTP, cache, sitemap, robots, canonical, chuyển hướng và các landing page quan trọng. Một bản restore sạch về bảo mật nhưng hỏng form hoặc mất đơn hàng vẫn không đạt yêu cầu vận hành.
Khi nào nên tạo backup sạch mới?
Sau khi website đã sạch, đã đổi mật khẩu, cập nhật plugin/theme, siết quyền file và theo dõi ổn định, hãy tạo một bản backup sạch mới. Bản này nên lưu offsite để dùng làm điểm khôi phục tin cậy cho các sự cố sau.
Kế hoạch backup sau sự cố
Website doanh nghiệp nên có backup file + database, retention đủ dài, bản offsite, kiểm thử restore định kỳ và người chịu trách nhiệm rõ ràng. Nếu website có lead, bán hàng hoặc chạy quảng cáo, backup nên đi cùng bảo trì WordPress và bảo mật WordPress.
Dấu hiệu bản backup không an toàn
Cần nghi ngờ nếu backup chứa file PHP trong uploads, user admin lạ, option có script lạ, sitemap có URL spam, plugin/theme nulled, file vừa sửa hàng loạt, hoặc restore xong lại xuất hiện redirect/cảnh báo bảo mật. Những dấu hiệu này cho thấy bản backup chưa đủ sạch để đưa lên production.
FAQ
Có nên restore bản backup mới nhất không?
Chỉ nên restore nếu đã xác nhận bản đó được tạo trước thời điểm nhiễm hoặc đã kiểm tra sạch trên staging.
Backup có thể chứa malware không?
Có. Nếu backup được tạo sau khi site đã bị nhiễm, nó có thể chứa backdoor, user lạ, URL spam hoặc mã redirect.
Có cần test restore định kỳ không?
Có. Backup chỉ thật sự có giá trị khi có thể restore được và dữ liệu sau restore hoạt động đúng.
Sau cleanup nên giữ backup cũ không?
Nên giữ có kiểm soát để đối chiếu điều tra, nhưng không dùng làm điểm khôi phục tin cậy nếu chưa xác minh sạch.
Cần kiểm tra backup trước khi restore WordPress?
IT Systems kiểm tra thời điểm nhiễm, restore staging, database, uploads và backup sạch để tránh khôi phục lại mã độc.
