نسخهٔ پشتیبان زمانی ارزش دارد که بتوانی آن را بازیابی کنی. امشب دیتابیس، فایل‌ها و تنظیمات لازم را جمع می‌کنیم و اجرای کارهای زمان‌بندی‌شده را از ترافیک بازدیدکننده جدا می‌کنیم.

این جلسه بخشی از دورهٔ آپاچی در ۵۰ شب است. قرارداد نام‌ها، مسیرها و روش اعمال تغییر را در راهنمای دوره بخوان.

محیط: سایت سالم WordPress، کلاینت آزمون و یک Clone بازیابی؛ backup حاوی رمز و دادهٔ خصوصی است و خارج از webroot می‌ماند.

پشتیبان سازگار#

تغییر کد و نوشتن داده را در پنجرهٔ backup کنترل کن. در حساب مدیریتی، برای مسیر تازهٔ خالی:

umask 077
mkdir -p ~/apache-lab/backups/before-update-01
sudo mariadb-dump --single-transaction --routines --triggers apache_wp \
  > ~/apache-lab/backups/before-update-01/database.sql
sudo tar -C /var/www/wordpress -czf - public \
  > ~/apache-lab/backups/before-update-01/files.tar.gz

این نام را برای backup تازه تغییر بده تا نسخهٔ قبلی overwrite نشود. --single-transaction برای جدول‌های transactional snapshot می‌دهد؛ با DDL هم‌زمان یا جدول غیرtransactional همان تضمین را نداری. config Apache، pool FPM، نسخهٔ PHP، گواهی و فهرست افزونه‌ها را نیز خصوصی نگه دار. نسخهٔ خارج از سرور و رمزنگاری‌شده داشته باش.

در Clone مستقل، دیتابیس خالی طبق شب سی‌وهشتم بساز، dump را با sudo mariadb apache_wp < database.sql وارد کن و فایل‌ها را در مسیر آماده استخراج کن. مالکیت، label و راز را بازیابی و از کلاینت ورود، مطلب و تصویر را بررسی کن. انتقال دامنه به search/replace سازگار با دادهٔ serialized نیاز دارد؛ جایگزینی سادهٔ SQL کافی نیست.

cron به‌جای بازدیدکننده#

در wp-config مقدار DISABLE_WP_CRON را true قرار بده. فایل /etc/systemd/system/wordpress-cron.service:

[Unit]
Description=WordPress scheduled events
After=mariadb.service

[Service]
Type=oneshot
User=wordpress
Group=wordpress
WorkingDirectory=/var/www/wordpress/public
ExecStart=/usr/bin/php /var/www/wordpress/public/wp-cron.php

مسیر PHP CLI و تنظیماتش را با شاخهٔ واقعی تطبیق بده. در Cloneهای legacy شب سی‌ونهم، User و Group واحد cron را به کاربر Apache همان Clone تغییر بده تا با مالکیت config و upload آن شاخه سازگار باشد. فایل /etc/systemd/system/wordpress-cron.timer:

[Unit]
Description=Run WordPress scheduled events every five minutes

[Timer]
OnCalendar=*-*-* *:0/5:00
Persistent=true

[Install]
WantedBy=timers.target

بعد از systemd-analyze verify برای هر دو فایل و daemon-reload، با sudo systemctl enable --now wordpress-cron.timer آن را فعال کن. journal و اجرای یک رویداد واقعی WordPress را ببین؛ فعال بودن timer به‌تنهایی کافی نیست.

ارتقای قابل برگشت#

ابزار WP-CLI را تنها از روش رسمی و با نسخهٔ ثبت‌شده نصب کن؛ wp core verify-checksums --path=/var/www/wordpress/public checksumهای هسته را بررسی می‌کند، نه امنیت افزونه‌ها. ارتقا را در Clone با همان PHP و config آزمایش کن، سپس با حساب انتشار کد را تغییر بده؛ runtime لازم نیست مالک کد شود.

بازگشت: اگر schema یا داده تغییر کرده، صرف برگرداندن کد کافی نیست؛ release، دیتابیس و فایل‌ها را به نقطهٔ سازگار بازیابی کن. هدف زمان بازیابی و حداکثر دادهٔ قابل از دست رفتن را از آزمون واقعی ثبت کن.

منبع: backup WordPress ، اتصال WP-Cron به scheduler ، checksum هسته .