Резервная копия сайта WordPress: ошибки новичков

Результат, к которому идём: два файла — SQL-дамп базы и архив wp-content вместе с wp-config.php — лежат не на том сервере, где работает сайт, и вы своими руками проверили, что из них поднимается живая копия. Первый проход занимает 30-40 минут на сайте с парой гигабайт медиа. Дальше это делает cron, а вы раз в квартал проверяете разворот. Инструкция написана для WordPress 6.x, WP-CLI 2.x, MySQL 8.0 или MariaDB 10.x на обычном Linux-хостинге с SSH.

Что нужно иметь до начала

• Доступ по SSH к аккаунту хостинга. Если его нет — смотрите раздел «Если SSH нет», но проверить копию всё равно придётся вручную.
• WP-CLI на сервере. Проверяется одной командой: wp --info. Должны увидеть версию PHP и строку с версией WP-CLI. Если команды нет — у многих хостингов она ставится в один клик в панели или доступна как wp-cli.phar.
• Данные базы из wp-config.php: DB_NAME, DB_USER, DB_HOST. Открывать файл не обязательно, WP-CLI читает их сам, но для ручного пути они понадобятся.
• Свободное место на диске — не меньше размера wp-content плюс размер базы. Копия, упавшая на середине из-за квоты, хуже отсутствия копии: она выглядит как файл.
• Место, где копия будет лежать: ваш компьютер, внешний диск, объектное хранилище. Любое, кроме каталога внутри сайта.

Что входит в копию, а что нет

Самая частая ошибка новичка — скопировать файлы и забыть базу. В файлах нет ни одного вашего текста: записи, страницы, товары, настройки, пользователи и комментарии живут в MySQL. Обратная ошибка такая же: дамп базы без uploads даст сайт со всеми текстами и битыми картинками.

SQL-дамп — обычный текстовый файл с командами SQL: создать таблицу, вставить такие-то строки. Его можно открыть редактором и прочитать. Именно поэтому дамп сжимается в 5-10 раз и именно поэтому его нельзя править поиском с заменой: часть значений в базе WordPress хранится в сериализованном виде, где длина строки указана числом рядом с ней.

Шесть шагов

1. Узнайте объёмы. Подставьте свой путь к сайту.

   cd /var/www/example.ru
   du -sh wp-content wp-content/uploads
   wp db size --human-readable

   Проверка: видите три строки с размерами. Если wp db size в вашей сборке не принимает --human-readable, запустите её без флага — получите размер в байтах. Сумма размеров и есть то место, которое нужно найти в хранилище.

2. Снимите дамп базы.

   mkdir -p ~/backups
   wp db export ~/backups/db-$(date +%F).sql --add-drop-table --single-transaction
   ls -lh ~/backups/
   tail -n 2 ~/backups/db-$(date +%F).sql

   Проверка: в конце файла есть строка-комментарий -- Dump completed on с датой. Нет её — дамп обрезан, повторите. Флаги --add-drop-table и --single-transaction WP-CLI передаёт в mysqldump: первый позволит залить дамп в непустую базу, второй снимает слепок без блокировки таблиц InnoDB.

3. Упакуйте файлы. Пароли и ключи в командах не нужны, всё берётся из конфига.

   cd /var/www/example.ru
   tar -czf ~/backups/files-$(date +%F).tar.gz \
     --exclude='wp-content/cache' \
     --exclude='wp-content/upgrade' \
     --exclude='wp-content/backups' \
     wp-content wp-config.php .htaccess

   Проверка: tar -tzf ~/backups/files-$(date +%F).tar.gz | head показывает пути, начинающиеся с wp-content/, а gzip -t на этом файле молчит. Если сайт работает на nginx, .htaccess из списка уберите, иначе tar отдаст ошибку о несуществующем файле.

4. Унесите копию с сервера. Команда запускается на вашем компьютере, не на хостинге.

   mkdir -p ~/wp-backups
   rsync -avz YOUR_SSH_USER@example.ru:~/backups/ ~/wp-backups/
   shasum -a 256 ~/wp-backups/files-*.tar.gz

   Проверка: сравните хеш с тем, что выдаёт sha256sum на сервере. Совпали — файл доехал целиком. Копия, оставшаяся на том же диске, не спасёт ни от удаления аккаунта за неоплату, ни от взлома, при котором злоумышленник чистит и бэкапы.

5. Разверните копию и убедитесь, что она живая. На локальной машине или тестовом поддомене поставьте чистый WordPress той же версии, распакуйте архив поверх и залейте дамп.

   mysql -u YOUR_DB_USER -p -e 'CREATE DATABASE wp_restore_test CHARACTER SET utf8mb4;'
   # в wp-config.php тестовой копии укажите базу wp_restore_test
   wp db import ~/wp-backups/db-2025-06-01.sql
   wp search-replace 'https://example.ru' 'http://example.local' --all-tables-with-prefix --dry-run

   Проверка: wp db import заканчивается строкой об успешном импорте, --dry-run показывает количество найденных замен по таблицам. Уберите --dry-run, откройте тестовый адрес, зайдите в админку, посмотрите список записей и последние загруженные картинки. Только теперь у вас есть резервная копия.

6. Поставьте это на расписание. Скрипт ~/scripts/wp-backup.sh:

   #!/bin/bash
   set -euo pipefail
   
   SITE=/var/www/example.ru
   DEST=/home/YOUR_SSH_USER/backups
   STAMP=$(date +%F-%H%M)
   
   mkdir -p "$DEST"
   wp --path="$SITE" db export "$DEST/db-$STAMP.sql"
   gzip -f "$DEST/db-$STAMP.sql"
   tar -czf "$DEST/files-$STAMP.tar.gz" -C "$SITE" \
     --exclude='wp-content/cache' \
     --exclude='wp-content/upgrade' \
     wp-content wp-config.php
   
   # держим копии за неделю
   find "$DEST" -name '*.gz' -mtime +7 -delete

   Дальше chmod +x ~/scripts/wp-backup.sh и строка в crontab -e:

   15 4 * * * /home/YOUR_SSH_USER/scripts/wp-backup.sh >> /home/YOUR_SSH_USER/backup.log 2>&1

   Проверка: на следующее утро в каталоге лежат два файла со свежей датой, а backup.log пустой. Непустой лог — читайте его, там написана причина. Выгрузку в хранилище добавьте в конец скрипта тем же rsync по ключу без пароля.

Если SSH нет

Порядок тот же, меняются инструменты. База: phpMyAdmin в панели хостинга, вкладка «Экспорт», формат SQL, сжатие gzip — скачанный файл должен быть не «0 байт» и не 1 КБ. Файлы: архив wp-content и wp-config.php через файловый менеджер панели, затем скачать. Либо плагин-бэкапер вроде UpdraftPlus или All-in-One WP Migration с выгрузкой в облако — у обоих есть бесплатные версии с ограничениями, и у обоих есть общая засада: расписание они вешают на WP-Cron, который на сайте без посетителей просто не запускается. Если копий по расписанию нет неделями, причина чаще всего эта: отключите WP-Cron константой DISABLE_WP_CRON и дёргайте wp-cron.php системным cron хостинга.

Копия, которую ни разу не разворачивали, — это не копия, а файл неизвестного содержания. Узнать, что в нём, вы успеете только в тот день, когда уже ничего другого не осталось.

Если не получилось

• mysqldump: command not found или WP-CLI жалуется, что не нашёл mysqldump. На части шаред-хостингов клиентские утилиты MySQL недоступны. Выход: экспорт через phpMyAdmin или плагин, который работает средствами PHP.
• Error: This does not seem to be a WordPress installation. Вы запустили wp не из каталога сайта. Перейдите в корень, где лежит wp-config.php, или добавьте --path=/var/www/example.ru — в скрипте для cron это обязательно, у cron нет вашего текущего каталога.
• Error establishing a database connection после разворота копии. В wp-config.php остались данные боевой базы: имя базы, пользователь, DB_HOST. Для тестовой копии правьте их вручную, в localhost против 127.0.0.1:3306 тоже упираются регулярно.
• No space left on device или архив вдруг весит столько же, сколько весь аккаунт. Почти всегда это папка бэкап-плагина внутри wp-content: вы пакуете старые архивы в новый архив. Добавьте её в --exclude и удалите то, что уже уехало в хранилище.
• MySQL server has gone away при импорте большого дампа. Обрывается соединение из-за лимита max_allowed_packet на сервере, куда вы заливаете. Либо поднимите лимит там, где к нему есть доступ, либо импортируйте через консоль, а не через phpMyAdmin с его ограничением на размер загружаемого файла.
• Белый экран или вёрстка без картинок после разворота на другом адресе. Домен меняли запросом UPDATE или поиском с заменой в .sql — сериализованные значения в wp_options сломались. Делайте только через wp search-replace, он пересчитывает длины строк.

Что делать дальше

Привяжите частоту копий к тому, сколько работы вы готовы потерять: блог с парой постов в неделю переживёт суточную копию, магазин с заказами — нет, ему нужны и ежедневный дамп, и бинлоги на стороне хостинга. Отдельно поставьте копию перед каждым обновлением ядра и плагинов — не после, когда сайт уже лежит. Запишите в текстовый файл рядом с архивами версию WordPress, версию PHP и порядок разворота в пяти строках: в стрессовой ситуации вы не будете вспоминать флаги. Раз в квартал поднимайте копию на тестовом поддомене и смотрите на два показателя: размер свежих файлов относительно прошлой недели и дату последнего успешного разворота. Если размер дампа внезапно упал вдвое — что-то уже сломалось, и лучше узнать об этом сейчас.