Backup WordPress tự động: thiết kế lịch sao lưu, kiểm tra restore và giám sát an toàn cho production

Backup WordPress tự động là một yêu cầu sống còn nếu website đang chạy production. Nhiều đội nghĩ rằng “đã có plugin backup” là đủ, nhưng khi gặp sự cố thật như lỗi cập nhật plugin, hỏng database, bị xóa nhầm media hoặc server chết disk, câu hỏi quan trọng không phải là có backup hay không, mà là backup đó có restore được không, mất bao nhiêu thời gian và có mất dữ liệu mới không.

Bài này đi theo hướng thực chiến: thiết kế backup WordPress tự động cho website production, chọn phạm vi sao lưu, lên lịch bằng cron, dùng WP-CLI để export database, nén file, lưu bản backup ra ngoài server, kiểm tra restore định kỳ và xây checklist nghiệm thu. Nếu anh đang vận hành WordPress cho doanh nghiệp, agency hoặc hệ thống nội bộ, đây là một runbook rất đáng có.

1. Backup WordPress production cần bảo vệ những gì?

WordPress không chỉ là mã nguồn. Khi làm backup WordPress tự động, cần tách rõ các thành phần sau:

Database: bài viết, trang, cấu hình plugin, user, menu, metadata.
Media/uploads: ảnh bài viết, file tải lên, thumbnail.
Theme và plugin tùy biến: nhất là child theme, mu-plugins, custom plugin.
File cấu hình: wp-config.php, cấu hình web server liên quan, cron script backup.
Tài nguyên phụ trợ: nếu có Redis object cache, job queue, hoặc tích hợp bên ngoài thì cần ghi chú cách khôi phục.

Điểm hay bị quên nhất là custom code và file cấu hình. Nhiều đội backup database + uploads nhưng quên mất plugin tự viết hoặc file cấu hình rewrite, đến lúc restore site vẫn lỗi.

2. Xác định RPO và RTO trước khi chọn lịch sao lưu

Trước khi viết script, cần chốt hai khái niệm vận hành:

RPO (Recovery Point Objective): chấp nhận mất bao nhiêu dữ liệu gần nhất. Ví dụ 24 giờ.
RTO (Recovery Time Objective): cần khôi phục trong bao lâu. Ví dụ dưới 60 phút.

Nếu site tin tức cập nhật ít, backup database mỗi đêm có thể chấp nhận được. Nếu site bán hàng hoặc form lead chạy liên tục, có thể cần backup database 4 giờ/lần hoặc theo transaction/event. Lịch sao lưu phải phục vụ RPO/RTO, không phải chọn ngẫu hứng.

3. Kiến trúc backup WordPress tự động khuyến nghị

Một mô hình dễ vận hành cho production:

Database backup nhiều lần/ngày hoặc mỗi đêm bằng wp db export hay mysqldump.
File backup hằng ngày cho wp-content/uploads và custom code.
Lưu bản backup ra ngoài server chính: S3/Object Storage/NAS/backup server.
Giữ nhiều phiên bản: 7 bản ngày gần nhất, 4 bản tuần, 3 bản tháng tùy nhu cầu.
Định kỳ restore test sang môi trường lab/staging.

Không nên chỉ backup vào cùng disk với production. Nếu VPS lỗi ổ đĩa hoặc bị xóa nhầm toàn bộ instance, backup cùng máy coi như không có.

4. Bối cảnh lab/production mẫu trong bài

OS: Ubuntu Server 22.04/24.04 hoặc Debian 12.
Web root: /var/www/example.com/public.
Backup local tạm: /backup/example.com.
WordPress quản trị bằng WP-CLI.
Upload ra object storage hoặc backup server sau khi tạo file backup local.

Ví dụ này phù hợp với self-hosted VPS hoặc dedicated server. Nếu anh dùng managed hosting, có thể giữ nguyên nguyên tắc nhưng thay thao tác CLI bằng job backup của panel hoặc API hosting.

5. Chuẩn bị WP-CLI và thư mục backup

Kiểm tra WP-CLI:

cd /var/www/example.com/public
wp --info
wp core version

Tạo thư mục backup riêng, không nằm trong webroot:

sudo mkdir -p /backup/example.com/{db,files,logs}
sudo chown -R deploy:deploy /backup/example.com
chmod 750 /backup/example.com

Giải thích:

db/: chứa file export database.
files/: chứa tar.gz của uploads hoặc custom code.
logs/: lưu log chạy backup để giám sát và troubleshooting.

Không đặt backup ở /var/www/example.com/public/backup. Đó là lỗi nghiêm trọng vì file .sql hoặc .zip có thể bị truy cập trực tiếp từ web.

6. Backup database bằng WP-CLI

Lệnh cơ bản:

cd /var/www/example.com/public
wp db export /backup/example.com/db/db-$(date +%F-%H%M).sql

Output mẫu:

Success: Exported to '/backup/example.com/db/db-2026-05-21-1905.sql'.

Sau đó nén lại để tiết kiệm dung lượng:

gzip /backup/example.com/db/db-$(date +%F-%H%M).sql

Nếu muốn dùng mysqldump trực tiếp để tinh chỉnh hiệu năng hoặc consistency, vẫn được. Nhưng với WordPress, WP-CLI giúp thao tác thuận tiện và đồng bộ ngữ cảnh dự án hơn.

7. Backup file: uploads, child theme, plugin tùy biến

Đừng nén cả cây WordPress mỗi lần nếu không cần. Thực tế nhất là backup những phần thay đổi thường xuyên và có giá trị khôi phục:

cd /var/www/example.com/public
tar -czf /backup/example.com/files/uploads-$(date +%F).tar.gz wp-content/uploads

tar -czf /backup/example.com/files/custom-code-$(date +%F).tar.gz   wp-content/themes/my-child-theme   wp-content/mu-plugins   wp-content/plugins/my-custom-plugin

Nếu site có nhiều upload lớn, có thể chuyển sang incremental backup bằng rsync hoặc snapshot theo filesystem/storage layer. Nhưng với đa số site vừa và nhỏ, tar.gz hằng ngày là điểm khởi đầu tốt.

8. Viết script backup WordPress tự động

Một script shell mẫu:

#!/usr/bin/env bash
set -euo pipefail

SITE_ROOT="/var/www/example.com/public"
BACKUP_ROOT="/backup/example.com"
NOW="$(date +%F-%H%M)"
LOG_FILE="$BACKUP_ROOT/logs/backup-$NOW.log"

mkdir -p "$BACKUP_ROOT/db" "$BACKUP_ROOT/files" "$BACKUP_ROOT/logs"

{
  echo "[$(date)] START backup"
  cd "$SITE_ROOT"

  wp db export "$BACKUP_ROOT/db/db-$NOW.sql"
  gzip "$BACKUP_ROOT/db/db-$NOW.sql"

  tar -czf "$BACKUP_ROOT/files/uploads-$NOW.tar.gz" wp-content/uploads

  echo "[$(date)] DONE backup"
} >> "$LOG_FILE" 2>&1

Ý nghĩa thực chiến:

set -euo pipefail giúp script dừng khi có lỗi thay vì im lặng chạy tiếp.
Ghi log riêng theo từng lần chạy để dễ theo dõi.
Tách database và file để restore linh hoạt hơn.

9. Lên lịch bằng cron

Ví dụ backup database mỗi ngày lúc 01:10, backup uploads lúc 01:30:

crontab -e

10 1 * * * /usr/local/bin/wp-backup-example.sh
30 1 * * * find /backup/example.com -type f -mtime +14 -delete

Nên tránh chạy backup đúng lúc traffic cao hoặc trùng giờ job nặng khác như optimize database, reindex tìm kiếm, backup VM snapshot, hoặc cron của plugin.

Kiểm tra cron đã vào lịch:

crontab -l

10. Lưu bản backup ra ngoài server

Đây là phần cực kỳ quan trọng của backup WordPress tự động. Backup local chỉ là lớp đầu tiên. Cần có offsite copy. Ví dụ với rclone đẩy sang object storage:

rclone copy /backup/example.com remote:wp-backups/example.com --progress

Hoặc dùng rsync sang backup server nội bộ:

rsync -avz /backup/example.com/ backup@10.0.0.20:/data/backups/example.com/

Checklist khi lưu offsite:

Bật mã hóa nếu backup chứa dữ liệu nhạy cảm.
Giới hạn quyền truy cập bucket/storage.
Không dùng chung credential backup với credential ứng dụng.
Ghi log kết quả upload offsite.

11. Restore test: phần quan trọng hơn cả việc tạo backup

Nhiều đội có backup nhưng chưa từng restore thử. Cách làm an toàn là restore sang môi trường lab/staging:

Tạo database test.
Giải nén file database.
Import database.
Giải nén uploads/custom code.
Chỉnh lại wp-config.php hoặc dùng file cấu hình lab.
Chạy wp search-replace nếu đổi domain.

Ví dụ:

gunzip /backup/example.com/db/db-2026-05-21-0100.sql.gz
mysql -u wpuser -p wp_lab < /backup/example.com/db/db-2026-05-21-0100.sql

cd /var/www/lab.example.com/public
wp search-replace 'https://example.com' 'https://lab.example.com' --skip-columns=guid

Output mẫu:

Success: Made 128 replacements.

Không có restore test thì backup mới chỉ là niềm tin, chưa phải phương án DR.

12. Kiểm tra tính toàn vẹn và dung lượng backup

Sau khi tạo file, nên có bước verify cơ bản:

ls -lh /backup/example.com/db
ls -lh /backup/example.com/files
gzip -t /backup/example.com/db/db-2026-05-21-0100.sql.gz
tar -tzf /backup/example.com/files/uploads-2026-05-21.tar.gz | head

Nếu file backup nhỏ bất thường, rỗng hoặc nén lỗi, script phải báo fail thay vì coi như thành công.

13. Giám sát job backup và cảnh báo lỗi

Một job backup production nên có ít nhất một cách cảnh báo khi fail:

Gửi mail nội bộ khi cron lỗi.
Đẩy log sang hệ thống giám sát như Grafana Loki, ELK, hoặc journal tập trung.
Kiểm tra kích thước file backup mới nhất và alert nếu không có file trong 24 giờ.

Nếu dùng systemd timer thay vì cron, có thể đọc log dễ hơn bằng journalctl. Nếu vẫn dùng cron, nên redirect log rõ ràng như trong script ở trên.

14. Troubleshooting lỗi thường gặp khi backup WordPress tự động

WP-CLI báo lỗi kết nối database

Kiểm tra wp-config.php có đúng credential không.
Kiểm tra MySQL/MariaDB đang chạy.
Thử wp db check để phát hiện lỗi database.

wp db check
systemctl status mariadb

Backup chạy xong nhưng file rất nhỏ

Có thể script export sai path hoặc job bị fail giữa chừng.
Kiểm tra log trong /backup/example.com/logs.
Kiểm tra disk full bằng df -h.

Tar uploads lỗi permission denied

Kiểm tra user chạy cron có quyền đọc toàn bộ uploads không.
Kiểm tra file owner/group.
Không nên chạy backup bằng root nếu không cần, nhưng cũng phải đảm bảo đủ quyền đọc.

Restore xong nhưng site lỗi CSS/ảnh

Thường do thiếu thư mục uploads hoặc path/domain sai.
Kiểm tra siteurl, home, plugin cache/CDN và file permission.
Xóa cache và regenerate thumbnail nếu cần.

15. Tài liệu chính thống nên tham khảo

16. Checklist nghiệm thu backup WordPress production

Có backup database theo lịch rõ ràng.
Có backup uploads và custom code quan trọng.
Backup không nằm trong webroot public.
Có ít nhất một bản backup offsite ngoài server production.
Có chính sách retention và dọn bản cũ.
Có log cho từng lần chạy backup.
Có cảnh báo nếu job fail hoặc không sinh file mới.
Đã restore test trong 30-90 ngày gần nhất.
Biết rõ RPO/RTO của website.

17. Bài tập lab cuối bài

Dựng một site WordPress lab.
Viết script backup database + uploads như mẫu trong bài.
Tạo cron chạy tự động mỗi đêm.
Đẩy backup sang một thư mục/offsite khác.
Thực hiện restore sang site lab thứ hai.
Đo thời gian khôi phục và ghi lại RTO thực tế.
Viết checklist failover/restore nội bộ cho team.

Kết luận: backup WordPress tự động chỉ thật sự có giá trị khi đi kèm restore test, giám sát và lưu bản ngoài server. Làm đúng từ đầu sẽ giúp anh tránh rất nhiều giờ hoảng loạn khi production gặp sự cố thật.