WordPress Backup Restore Runbook: Khôi Phục Website Production An Toàn Khi Sự Cố Xảy Ra

WordPress backup restore runbook là tài liệu sống giúp đội quản trị khôi phục website nhanh, đúng thứ tự và có thể kiểm chứng khi production gặp sự cố. Backup không chỉ là “có file .zip ở đâu đó”. Backup chỉ có giá trị khi bạn biết chính xác nó gồm những gì, khôi phục trong bao lâu, dữ liệu có nhất quán không, và ai được quyền bấm nút rollback.

Bài này đi theo góc nhìn vận hành thực tế: một website WordPress production bị lỗi sau khi cập nhật plugin hoặc bị hỏng database. Chúng ta sẽ thiết kế chiến lược backup, viết runbook khôi phục, dùng WP-CLI kiểm tra, xử lý lỗi thường gặp và tạo checklist nghiệm thu trước khi mở lại traffic.

Bối cảnh production: backup không phải là bảo hiểm nếu chưa từng restore

Giả sử hệ thống WordPress có kiến trúc phổ biến:

Nginx hoặc Apache làm web server.
PHP-FPM chạy WordPress core, theme và plugin.
MariaDB/MySQL lưu post, user, option, order, cấu hình plugin.
Thư mục wp-content/uploads chứa ảnh và media.
Plugin cache, CDN hoặc object cache như Redis.
Một môi trường staging để kiểm thử trước khi đưa lên production.

Sự cố có thể đến từ nhiều hướng: plugin update gây fatal error, xóa nhầm media, SQL migration lỗi, tài khoản admin bị chiếm, hoặc máy chủ mất volume. Nếu không có runbook, đội vận hành thường mất thời gian tranh luận: restore bản nào, restore database trước hay file trước, có cần tắt cache không, có mất đơn hàng mới không?

RPO, RTO và câu hỏi quan trọng trước khi backup

Trước khi viết lệnh backup, cần thống nhất hai chỉ số:

RPO – Recovery Point Objective: chấp nhận mất tối đa bao nhiêu dữ liệu. Ví dụ blog cá nhân có thể chấp nhận mất 24 giờ, site bán hàng có thể chỉ chấp nhận 5-15 phút.
RTO – Recovery Time Objective: cần khôi phục dịch vụ trong bao lâu. Ví dụ landing page có thể 2 giờ, còn site thương mại điện tử có thể dưới 30 phút.

Hai chỉ số này quyết định tần suất backup, nơi lưu backup, cách test restore và mức tự động hóa. Một site có RPO 15 phút không thể chỉ dựa vào bản backup thủ công mỗi tối.

Thành phần bắt buộc trong một bản backup WordPress

Một backup WordPress production tối thiểu phải gồm:

Database: bảng post, option, user, taxonomy, plugin data, WooCommerce order nếu có.
wp-content: theme, plugin, uploads, mu-plugins, language file.
wp-config.php: chỉ backup vào nơi bảo mật vì chứa thông tin kết nối database và key.
Cấu hình web server: virtual host, rewrite, SSL, PHP-FPM pool.
Thông tin phiên bản: WordPress core, PHP, MySQL/MariaDB, plugin/theme version.

Không phải lúc nào cũng cần backup toàn bộ WordPress core nếu bạn quản lý bằng source hoặc có thể tải lại đúng phiên bản. Nhưng với incident thật, có một bản snapshot đầy đủ thường giúp rút ngắn thời gian phục hồi.

Thiết kế thư mục backup dễ kiểm soát

Một cấu trúc rõ ràng giúp tránh nhầm bản backup:

/backup/wordpress/
  production/
    2026-07-03T190000+0700/
      db.sql.gz
      wp-content.tar.gz
      wp-config.php.enc
      versions.txt
      checksums.sha256
      restore-notes.md

Không nên đặt file backup ngay dưới web root như /var/www/html/backup.zip. Đây là lỗi bảo mật rất nghiêm trọng vì người ngoài có thể tải database hoặc mã nguồn nếu server cấu hình sai.

Bước 1: kiểm tra trạng thái trước khi backup

Trước khi tạo backup hoặc restore, ghi nhận trạng thái hiện tại để có cơ sở so sánh:

cd /var/www/sysadminskills
wp core version
wp plugin list --status=active
wp theme list --status=active
wp option get siteurl
wp option get home
wp db size --tables

Output mẫu:

6.5.5
+----------------------+--------+---------+
| name                 | status | version |
+----------------------+--------+---------+
| wordpress-seo        | active | 22.9    |
| redis-cache          | active | 2.5.0   |
+----------------------+--------+---------+

Nếu WP-CLI không chạy được vì fatal error, thử bỏ qua plugin/theme:

wp plugin list --skip-plugins --skip-themes
wp option get home --skip-plugins --skip-themes

Bước 2: backup database bằng WP-CLI hoặc mysqldump

Cách dễ nhất với WP-CLI:

mkdir -p /backup/wordpress/production/$(date +%Y-%m-%dT%H%M%S%z)
BACKUP_DIR=/backup/wordpress/production/$(date +%Y-%m-%dT%H%M%S%z)
cd /var/www/sysadminskills
wp db export "$BACKUP_DIR/db.sql" --single-transaction
 gzip "$BACKUP_DIR/db.sql"

--single-transaction giúp dump InnoDB nhất quán hơn mà không khóa bảng lâu. Với site có ghi dữ liệu liên tục như WooCommerce, cần cân nhắc maintenance mode ngắn hoặc backup cấp database/replica để giảm rủi ro dữ liệu lệch.

Nếu dùng mysqldump trực tiếp:

mysqldump --single-transaction --quick --routines --triggers \
  -u wp_user -p wordpress_db | gzip > "$BACKUP_DIR/db.sql.gz"

Bước 3: backup wp-content và cấu hình quan trọng

tar --exclude='cache' --exclude='upgrade' \
  -czf "$BACKUP_DIR/wp-content.tar.gz" \
  -C /var/www/sysadminskills wp-content

Cache thường có thể tái tạo, không nên làm backup phình to nếu không cần. Nhưng uploads, theme tùy biến, plugin tự viết và mu-plugins phải được bảo vệ.

Với wp-config.php, nên mã hóa trước khi đưa ra offsite:

gpg --symmetric --cipher-algo AES256 \
  --output "$BACKUP_DIR/wp-config.php.gpg" \
  /var/www/sysadminskills/wp-config.php

Bước 4: tạo checksum và metadata

Checksum giúp phát hiện file backup bị hỏng trong quá trình upload hoặc lưu trữ:

cd "$BACKUP_DIR"
sha256sum db.sql.gz wp-content.tar.gz wp-config.php.gpg > checksums.sha256
wp core version > versions.txt
php -v >> versions.txt
mysql --version >> versions.txt

Khi restore, luôn chạy:

sha256sum -c checksums.sha256

Nếu checksum fail, không dùng bản backup đó cho production trừ khi đã có phương án xác minh khác.

Bước 5: lưu backup offsite và đặt retention

Backup chỉ nằm cùng máy production không đủ an toàn. Nếu máy bị xóa volume, ransomware hoặc lỗi thao tác, backup cũng mất. Tối thiểu nên có bản offsite ở object storage hoặc server backup riêng.

Ví dụ đồng bộ lên S3-compatible storage:

aws s3 sync "$BACKUP_DIR" s3://company-backup/wordpress/production/$(basename "$BACKUP_DIR")/ \
  --storage-class STANDARD_IA \
  --sse AES256

Chính sách retention tham khảo:

Giữ bản hourly trong 24-48 giờ cho site thay đổi liên tục.
Giữ bản daily trong 14-30 ngày.
Giữ bản monthly trong 6-12 tháng nếu có yêu cầu kiểm toán.

Runbook restore: thứ tự khôi phục an toàn

Khi incident xảy ra, đừng restore ngay lên production nếu chưa đánh giá mất dữ liệu. Thứ tự khuyến nghị:

Thông báo incident và đóng băng thay đổi: không update plugin/theme trong lúc xử lý.
Chụp snapshot trạng thái hiện tại để có đường quay lại.
Khôi phục bản backup vào staging hoặc máy tạm.
Kiểm tra login, post, media, form, checkout nếu có.
Quyết định cutover: restore production trực tiếp, đổi DNS, hoặc promote staging.
Xóa cache, warm cache, kiểm tra monitoring.

Bước 6: restore database trên staging

cd /var/www/staging-site
wp maintenance-mode activate
zcat /backup/wordpress/production/2026-07-03T190000+0700/db.sql.gz | wp db import -
wp search-replace 'https://sysadminskills.com' 'https://staging.sysadminskills.com' --skip-columns=guid
wp cache flush
wp maintenance-mode deactivate

search-replace cần xử lý serialized data đúng cách, vì vậy WP-CLI an toàn hơn lệnh SQL replace thủ công. Không nên đổi cột guid nếu không có lý do rõ ràng.

Bước 7: restore wp-content

cd /var/www/staging-site
mv wp-content wp-content.before-restore.$(date +%s)
tar -xzf /backup/wordpress/production/2026-07-03T190000+0700/wp-content.tar.gz -C /var/www/staging-site
chown -R www-data:www-data wp-content
find wp-content -type d -exec chmod 755 {} \;
find wp-content -type f -exec chmod 644 {} \;

Sau khi restore, kiểm tra quyền file. Lỗi permission là nguyên nhân phổ biến khiến media không hiển thị hoặc plugin không ghi được cache.

Bước 8: kiểm tra site sau restore

Dùng cả CLI và HTTP:

wp core verify-checksums
wp plugin verify-checksums --all
wp db check
curl -I https://staging.sysadminskills.com/
curl -I https://staging.sysadminskills.com/wp-login.php

Nếu wp plugin verify-checksums báo plugin thương mại không có checksum, ghi chú lại thay vì xem ngay là lỗi. Với plugin tự viết, nên so sánh với Git hoặc artifact CI/CD.

Rollback plugin update gây lỗi trắng trang

Nếu nguyên nhân là plugin update, có thể rollback ít xâm lấn hơn restore toàn bộ site:

wp plugin deactivate plugin-bi-loi --skip-plugins --skip-themes
wp plugin install plugin-bi-loi --version=1.2.3 --force
wp plugin activate plugin-bi-loi

Nếu không vào được WP-CLI, đổi tên thư mục plugin:

mv wp-content/plugins/plugin-bi-loi wp-content/plugins/plugin-bi-loi.disabled

Sau đó xem log PHP-FPM hoặc web server:

tail -n 100 /var/log/nginx/error.log
tail -n 100 /var/log/php*-fpm.log

Lỗi thường gặp khi backup và restore WordPress

Backup thiếu uploads: bài viết còn trong database nhưng ảnh 404.
Restore nhầm domain: site staging redirect về production do home/siteurl chưa đổi.
Không tắt cache: người dùng thấy nội dung cũ hoặc lỗi cũ sau khi restore.
Không kiểm tra serialized data: replace URL bằng SQL thô làm hỏng option của plugin.
Không có checksum: không biết file backup có bị hỏng hay không.
Lưu backup trong public web root: rò rỉ database và credential.
Chưa thử restore bao giờ: đến lúc incident mới phát hiện thiếu quyền, thiếu file, thiếu mật khẩu giải mã.

Checklist nghiệm thu trước khi mở lại production

Trang chủ, bài viết, category, search trả HTTP 200.
Đăng nhập admin thành công bằng tài khoản được phép.
Media mới và cũ hiển thị đúng.
Form liên hệ, checkout hoặc chức năng nghiệp vụ chính hoạt động.
Không còn fatal error trong PHP/web server log.
Cache/CDN đã purge và warm lại các trang quan trọng.
Backup dùng để restore có checksum hợp lệ.
Đã ghi nhận dữ liệu có thể mất theo RPO và thông báo cho bên liên quan.
Monitoring sau restore không báo lỗi 5xx, latency hoặc database connection bất thường.

Lab thực hành: diễn tập restore mỗi tháng

Một bài lab đơn giản nhưng rất đáng làm:

Tạo một WordPress staging bằng dữ liệu giả.
Viết script backup database, wp-content và checksum.
Xóa thử một plugin hoặc đổi sai option siteurl.
Restore vào thư mục staging mới.
Chạy kiểm tra HTTP, WP-CLI và log.
Ghi thời gian restore thực tế để so với RTO.

Nếu đội của bạn chưa từng diễn tập restore, hãy xem backup hiện tại là “chưa được chứng minh”. Một buổi diễn tập 30-60 phút có thể cứu nhiều giờ downtime trong incident thật.

Kết luận

WordPress backup restore runbook tốt phải trả lời được ba câu hỏi: backup có đủ dữ liệu không, restore có chạy được không, và sau restore làm sao biết website đã an toàn để mở lại. Khi kết hợp WP-CLI, checksum, offsite storage, retention rõ ràng và diễn tập định kỳ, backup không còn là niềm tin mơ hồ mà trở thành năng lực phục hồi có thể đo lường.