Một buổi sáng bạn mở website lên và thấy trang trắng, hoặc một plugin vừa cập nhật làm gãy toàn bộ giao diện. Nếu không có bản sao lưu nào gần đó, bạn phải dựng lại từ đầu — mất nội dung, mất đơn hàng, mất thời gian. Sao lưu website WordPress đúng cách là việc phòng ngừa rẻ nhất so với hậu quả khi mất dữ liệu.
Bài này đi vào phần hay bị hiểu nhầm: sao lưu không chỉ là tải file xuống máy, mà cần tách đúng hai phần (tệp và cơ sở dữ liệu), lưu ở nhiều nơi, và phải từng thử khôi phục ít nhất một lần.
Sao lưu website WordPress là làm gì, cần sao lưu những gì
Một website WordPress gồm hai phần tách biệt, và bạn phải sao lưu cả hai:
- Tệp (files): mã lõi WordPress, theme, plugin, thư mục uploads (ảnh, tài liệu khách đã tải lên), và file cấu hình wp-config.php.
- Cơ sở dữ liệu (CSDL/MySQL): toàn bộ bài viết, trang, bình luận, thông tin người dùng, cài đặt plugin — phần này nằm ngoài cấu trúc thư mục, không tải xuống bằng cách kéo-thả file như bình thường được.
Sai lầm hay gặp nhất: chỉ tải thư mục wp-content xuống máy rồi nghĩ đã sao lưu xong, quên mất cơ sở dữ liệu. Khi khôi phục, bạn có đủ ảnh và plugin nhưng mất sạch nội dung bài viết.
Nguyên tắc nhiều bản sao, nhiều nơi lưu trữ
Trong ngành lưu trữ dữ liệu nói chung, nguyên tắc phổ biến là giữ nhiều bản sao ở nhiều loại nơi lưu khác nhau, trong đó ít nhất một bản ở vị trí khác hẳn server chính — để một sự cố (server sập, hosting bị khoá, tài khoản bị hack) không làm mất luôn cả bản sao lưu.
Tài liệu chính thức của WordPress.org khuyên áp dụng tinh thần này theo cách cụ thể: giữ vài bản sao lưu gần nhất, đặt ở nhiều nơi khác nhau — một bản trên chính hosting, một bản ở nơi lưu trữ ngoài (ví dụ dịch vụ lưu trữ mây hoặc ổ cứng riêng), và một bản tải về máy tính cá nhân. Nếu bạn chỉ lưu một bản duy nhất ngay trên server đang chạy website, bản sao lưu đó cũng biến mất khi server gặp sự cố.
Website đang không có lịch sao lưu rõ ràng?
VIDCO rà soát cách website của bạn đang sao lưu hiện tại, chỉ ra điểm thiếu trước khi xảy ra sự cố — không hứa số giờ khôi phục cụ thể, mức xử lý thống nhất theo hợp đồng.
3 cách sao lưu website WordPress phổ biến
Tuỳ vào hosting và mức độ chủ động bạn muốn, có ba cách chính. Nhiều website kết hợp cả ba — ví dụ vẫn bật công cụ tự động của hosting, nhưng mỗi tháng tự tải thêm một bản về máy để chắc chắn có bản dự phòng nằm ngoài hệ thống của một nhà cung cấp duy nhất:
| Cách | Khi nào phù hợp | Điều cần lưu ý |
|---|---|---|
| Công cụ sao lưu tích hợp sẵn trên hosting (cPanel, aaPanel…) | Website mới, chưa quen thao tác kỹ thuật | Tiện nhưng phụ thuộc hoàn toàn vào hosting đó; nên tải thêm một bản về nơi khác, đừng chỉ dựa vào một bên |
| Plugin sao lưu trong WordPress | Muốn lên lịch tự động, chọn lưu lên dịch vụ lưu trữ mây | Cần kiểm tra plugin còn được cập nhật, và thử chạy khôi phục thử ít nhất một lần sau khi cài |
| wp-cli + mysqldump (dòng lệnh) | Có quyền truy cập SSH/terminal, muốn kiểm soát từng bước | Chính xác, dễ đưa vào tác vụ tự động (cron), nhưng cần biết thao tác dòng lệnh |
Không có cách nào là bắt buộc duy nhất. Điều quan trọng hơn tên công cụ là bạn có thật sự kiểm tra bản sao lưu đó còn tồn tại, còn đầy đủ, và có nằm ở ít nhất hai nơi khác nhau hay không.
Tần suất sao lưu hợp lý theo loại website
Không phải website nào cũng cần sao lưu với cùng tần suất. Theo hướng dẫn chính thức của WordPress.org, website ít thay đổi nội dung (ví dụ trang giới thiệu doanh nghiệp, ít đăng bài mới) có thể sao lưu thưa hơn, chẳng hạn mỗi tuần một lần; ngược lại website hoạt động nhiều — nhận đơn hàng, cập nhật sản phẩm, đăng bài liên tục — nên sao lưu dày hơn, có thể mỗi ngày, để nếu có sự cố, phần nội dung mất đi là ít nhất có thể.
Cách xác định tần suất phù hợp đơn giản: nhìn lại một ngày hoặc một tuần bình thường của website, xem có bao nhiêu thay đổi (bài mới, đơn hàng, bình luận, chỉnh sửa trang) xảy ra trong khoảng đó. Nếu mất đi lượng thay đổi đó khiến bạn thấy đáng kể, đó là dấu hiệu cần sao lưu dày hơn khoảng thời gian đó.
Sao lưu bằng wp-cli và mysqldump: lệnh thật dùng được
Nếu website chạy trên server có cài WP-CLI, lệnh xuất cơ sở dữ liệu là:
wp db export backup-2026-10-11.sql
Không ghi tên file, WP-CLI tự đặt tên theo tên cơ sở dữ liệu, ngày, và một mã ngẫu nhiên. Khi cần khôi phục lại, dùng lệnh nhập vào:
wp db import backup-2026-10-11.sql
Nếu server không có WP-CLI nhưng có quyền truy cập dòng lệnh MySQL, mysqldump làm việc tương tự:
mysqldump -u tenuser -p tencsdl > backup.sql
Phần tệp (theme, plugin, uploads, wp-config.php) thì sao lưu bằng cách nén toàn bộ thư mục website (ví dụ lệnh tar hoặc công cụ nén trong cPanel/aaPanel), tách riêng với file .sql của cơ sở dữ liệu. Hai file này — một nén tệp, một xuất CSDL — là đủ để dựng lại toàn bộ website ở nơi khác khi cần.
Thử khôi phục: bước nhiều người bỏ qua
Có bản sao lưu không có nghĩa là bản đó dùng được. File có thể bị lỗi giữa đường, thiếu một phần, hoặc không tương thích phiên bản WordPress mới. Cách chắc chắn duy nhất là thử khôi phục thật, ít nhất một lần, trên một môi trường khác (website thử/staging, hoặc một thư mục con riêng), rồi kiểm tra trang có hiển thị đúng, đăng nhập được, dữ liệu còn đủ không.
Việc này nên lặp lại định kỳ, không chỉ làm một lần rồi để đó — nhất là sau khi đổi plugin sao lưu hoặc đổi hosting. Nếu bạn đang thuê dịch vụ quản trị website, lịch kiểm tra khôi phục nên được ghi rõ trong công việc định kỳ, không để đến lúc gặp sự cố mới biết bản sao lưu không dùng được.
Lỗi hay gặp khi sao lưu website
- Chỉ sao lưu tệp, quên cơ sở dữ liệu: khôi phục xong vẫn mất nội dung bài viết, bình luận, đơn hàng.
- Chỉ giữ một bản sao lưu duy nhất, trên cùng server: mất cả website và bản sao lưu cùng lúc khi server gặp sự cố.
- Không bao giờ thử khôi phục: đến lúc cần mới phát hiện file sao lưu bị lỗi hoặc thiếu phần.
- Sao lưu quá thưa so với tần suất cập nhật nội dung: website bán hàng đăng sản phẩm, nhận đơn hằng ngày mà chỉ sao lưu mỗi tháng một lần là quá thưa.
- Không kiểm tra lại sau khi đổi plugin hoặc đổi hosting: lịch sao lưu cũ có thể ngừng chạy mà không ai để ý.
Nguồn tham khảo
Thông tin trong bài được đối chiếu với các nguồn chính thức dưới đây tại thời điểm biên soạn; văn bản và chính sách có thể thay đổi.
- Sao lưu website WordPress – Hướng dẫn chính thức
- WP-CLI Command: wp db export – Xuất cơ sở dữ liệu
- WP-CLI Command: wp core verify-checksums – Kiểm tra tính toàn vẹn
- Hardening WordPress – Bảo mật và sao lưu
Câu hỏi thường gặp
Sao lưu website WordPress nên làm bao lâu một lần?
Tuỳ mức độ hoạt động: website ít thay đổi nội dung có thể sao lưu thưa hơn, website bán hàng hoặc đăng bài liên tục nên sao lưu dày hơn, theo hướng dẫn chính thức của WordPress.org về backup.
Sao lưu tệp (file) có đủ chưa, có cần sao lưu cơ sở dữ liệu riêng không?
Chưa đủ. Tệp và cơ sở dữ liệu là hai phần tách biệt của WordPress, phải sao lưu cả hai mới khôi phục được đầy đủ website.
wp-cli và mysqldump khác nhau thế nào?
wp-cli là công cụ dòng lệnh riêng của WordPress, lệnh “wp db export” xuất cơ sở dữ liệu; mysqldump là công cụ chuẩn của MySQL, làm cùng việc nhưng không cần cài WP-CLI. Cả hai đều tạo ra file .sql dùng để khôi phục.
Lưu bản sao lưu ngay trên hosting có an toàn không?
Nên có thêm ít nhất một bản ở nơi khác ngoài hosting đang chạy website, vì nếu hosting gặp sự cố hoặc tài khoản bị khoá, bản sao lưu lưu cùng chỗ cũng mất theo.
Làm sao biết bản sao lưu còn dùng được?
Cách chắc chắn nhất là thử khôi phục thật trên một môi trường khác (website thử hoặc thư mục riêng), kiểm tra trang hiển thị và đăng nhập đúng, rồi lặp lại việc này định kỳ.
Muốn có lịch sao lưu và kiểm tra khôi phục định kỳ, không phải tự nhớ làm?
Dịch vụ chăm sóc website của VIDCO đưa việc sao lưu vào lịch định kỳ tuần-tháng-quý, có báo cáo rõ đã làm gì.
Xem thêm: dịch vụ chăm sóc website, website bị hack xử lý thế nào, bảo mật website WordPress theo hardening chính thức, checklist bảo trì website có mẫu lịch sao lưu tải được.
Nguồn đối chiếu: developer.wordpress.org/advanced-administration/security/hardening/ (“Hardening WordPress”), developer.wordpress.org/advanced-administration/security/backup/, developer.wordpress.org/cli/commands/db/export/ và …/core/verify-checksums/, support.google.com/webmasters/answer/9044101 (báo cáo Security Issues) — kiểm tra ngày 11/10/2026. Các bước kỹ thuật có thể thay đổi theo phiên bản WordPress hoặc theo hosting bạn đang dùng; nên đối chiếu lại tài liệu chính thức trước khi áp dụng.
