Как создать резервную копию сайта на WordPress

Полная резервная копия WordPress — это совокупность двух компонентов, зафиксированных одновременно: файлов и базы данных MySQL. Если упустить хотя бы один из них, восстановление завершится неудачей. В этом руководстве рассматривается надёжный способ создания резервных копий из командной строки — с использованием mysqldump, tar и задания cron, которое отправляет архивы на удалённое хранилище, — чтобы вы полностью контролировали резервное копирование, а не зависели от плагина. Здесь также объективно рассмотрены варианты на основе хостинга и плагинов, а также приведены команды восстановления, которые подтверждают работоспособность резервной копии.

Что входит в полную резервную копию WordPress?

Сайт на WordPress — это две независимые системы, и резервная копия должна охватывать обе. Файлы — это ядро WordPress, всё содержимое директории wp-content (темы, плагины и папка uploads, которая, как правило, занимает наибольший объём), а также корневой файл wp-config.php. На Apache также необходимо сохранять .htaccess; на nginx или Caddy файла .htaccess нет, поскольку правила перезаписи URL задаются в конфигурации сервера за пределами корневой директории сайта. База данных — это база MySQL, в которой хранятся записи, страницы, комментарии, пользователи, таксономии, а также все настройки плагинов и тем.

Самая распространённая ошибка новичков — создание резервной копии файлов через FTP без сохранения базы данных. Темы и ядро можно скачать заново, а вот контент — нет. Если «резервная копия» содержит только файлы, восстановленный сайт запустится без записей и без настроек.

Какие существуют три способа резервного копирования WordPress?

Существует три практических подхода, каждый из которых предполагает компромисс между удобством и степенью контроля.

Резервные копии хостинга удобны, но не должны быть единственным источником данных — срок хранения ограничен, а при компрометации или отказе сервера хранящиеся на нём резервные копии могут быть утеряны вместе с ним. Плагины, такие как UpdraftPlus, обеспечивают планирование и загрузку в облако прямо из панели управления и являются разумным выбором для нетехнических пользователей. Подход через CLI — это то, что разработчик может версионировать, планировать и аудировать.

Резервное копирование WordPress из командной строки

Резервное копирование из командной строки состоит из трёх шагов по SSH: выгрузка базы данных, архивирование файлов и перенос обоих компонентов за пределы сервера. Сначала подключитесь:

ssh user@example.com -p 2222

Затем заархивируйте файлы и выгрузите базу данных:

# Архивирование файлов сайта из директории выше корневой директории веб-сервера
tar -zcf files.tar.gz public_html

# Выгрузка базы данных с созданием согласованного снимка
mysqldump --single-transaction -u DB_USER -p DB_NAME > db.sql

Флаг --single-transaction делает дамп надёжным для работающего сайта. Согласованный снимок создаётся только для таблиц InnoDB; таблицы MyISAM или MEMORY могут изменяться в процессе выгрузки. Поскольку WordPress по умолчанию использует InnoDB, флаг --single-transaction значительно предпочтительнее --lock-tables — он не требует блокировки таблиц, и сайт продолжает работать во время выгрузки. Используйте mysqldump, а не mysqlpump — последний был удалён в MySQL 8.4, поэтому скрипты, вызывающие его, будут завершаться с ошибкой на актуальных серверах.

Скачайте оба файла с помощью scp:

scp -P 2222 user@example.com:~/files.tar.gz .
scp -P 2222 user@example.com:~/db.sql .

Один нюанс, который обычно упускают в руководствах: в scp для указания порта используется заглавная -P, тогда как в ssh и mysqldump строчная -p (порт и пароль соответственно). Путаница между ними — классическая причина неудачного выполнения команды.

Если у вас установлен WP-CLI, команда wp db export удобнее: она запускает утилиту mysqldump, используя учётные данные DB_HOST, DB_NAME, DB_USER и DB_PASSWORD из файла wp-config.php, и принимает любые допустимые флаги mysqldump.

wp db export --single-transaction db.sql

На управляемых хостингах и хостингах с cPanel обычный mysqldump может завершаться с ошибкой привилегии PROCESS при выгрузке табличных пространств. WP-CLI уже решает эту проблему: wp db export по умолчанию добавляет --no-tablespaces к mysqldump. При использовании mysqldump напрямую на управляемом хостинге добавьте --no-tablespaces самостоятельно.

Автоматизация резервного копирования WordPress с помощью cron и rclone

Автоматизируйте весь процесс с помощью короткого shell-скрипта по расписанию cron, который выгружает базу данных, архивирует wp-content с помощью tar и отправляет архив за пределы сервера. rclone — «rsync для облачного хранилища» — поддерживает S3, Backblaze B2, Google Drive и другие сервисы.

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

SITE_DIR="/var/www/example.com"
DEST="b2remote:example-backups"     # настроенный удалённый ресурс rclone
STAMP="$(date +%F)"
WORK="$(mktemp -d)"

cd "$SITE_DIR"

# База данных — WP-CLI считывает учётные данные из wp-config.php
wp db export --single-transaction "$WORK/db-$STAMP.sql"

# Файлы — темы, плагины, загрузки и конфигурация
tar -zcf "$WORK/wp-content-$STAMP.tar.gz" wp-content wp-config.php

# Отправка во внешнее хранилище
rclone copy "$WORK" "$DEST/$STAMP"

rm -rf "$WORK"

Добавьте в crontab строку для ежедневного запуска в 03:15 с записью вывода в лог:

15 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1

В этом и заключается преимущество полного контроля над резервными копиями: никакой панели управления, никаких плагинов, никаких ручных действий. Если WP-CLI не установлен, замените строку экспорта на mysqldump --single-transaction --no-tablespaces -u DB_USER -pPASS DB_NAME > "$WORK/db-$STAMP.sql".

Хранение резервных копий по правилу 3-2-1

Следуйте правилу 3-2-1: храните не менее трёх копий сайта на двух различных типах носителей, при этом одна копия должна находиться за пределами основного места хранения. Никогда не допускайте, чтобы единственная резервная копия хранилась на том же сервере, что и сайт, — взлом или отказ диска уничтожит оба ресурса одновременно. Именно поэтому приведённый выше скрипт автоматизации отправляет данные в объектное хранилище, а не оставляет архив в корневой директории сайта. Поскольку архив содержит полную копию сайта, включая секретные данные из wp-config.php, защитите место назначения надёжными учётными данными и двухфакторной аутентификацией на аккаунте хранилища.

Тестирование восстановления и типичные ошибки

Непроверенная резервная копия — не резервная копия. Периодически восстанавливайте .sql и файловый архив на промежуточном или локальном сайте, чтобы убедиться, что копия действительно позволяет восстановить сайт:

tar -xzf wp-content-2026-07-06.tar.gz
wp db import db-2026-07-06.sql          # или без WP-CLI:
mysql -u DB_USER -p DB_NAME < db-2026-07-06.sql

Три сценария отказа приводят к потере большинства сайтов: резервное копирование файлов без базы данных, хранение резервной копии на том же сервере, что и сайт, и слепое доверие к автоматическому резервному копированию хостинга. Каждый из них можно предотвратить с помощью описанного выше рабочего процесса.

Надёжная схема проста и незаметна: задание cron, которое стабильно выгружает базу данных, архивирует файлы, отправляет оба компонента во внешнее хранилище, — и восстановление, которое вы реально тестируете. Напишите скрипт один раз, направьте его в объектное хранилище, добавьте строку в crontab и выполните тестовое восстановление на этой неделе — это и есть резервная копия, которую вы контролируете, а не та, о которой вы лишь надеетесь, что она работает.

Часто задаваемые вопросы

В чём разница между wp db export и прямым вызовом mysqldump?

wp db export — это тонкая обёртка над mysqldump. Она запускает утилиту mysqldump, используя учётные данные DB_HOST, DB_NAME, DB_USER и DB_PASSWORD, уже хранящиеся в wp-config.php, поэтому вам не нужно искать или передавать параметры подключения вручную; при этом принимаются любые допустимые флаги mysqldump. Кроме того, по умолчанию добавляется флаг --no-tablespaces, что позволяет избежать ошибки привилегии PROCESS, характерной для управляемых хостингов. Прямой вызов mysqldump даёт идентичный дамп, но требует самостоятельного указания учётных данных и флагов.

Почему mysqldump выдаёт ошибку привилегии PROCESS на управляемых хостингах и как её устранить?

На управляемых хостингах и хостингах с cPanel mysqldump пытается выгрузить информацию о табличных пространствах, для чего требуется привилегия PROCESS, которой обычно лишены пользователи общих баз данных. Это приводит к ошибке 'Access denied; you need the PROCESS privilege'. Добавьте флаг --no-tablespaces, чтобы пропустить этот шаг, и выгрузка завершится успешно. WP-CLI автоматически добавляет --no-tablespaces в wp db export. В большинстве случаев экспорт всё равно завершается успешно, несмотря на ошибку, — проверьте дамп, убедившись в наличии всех таблиц.

Можно ли пропустить резервное копирование файлов, если ядро WordPress и плагины можно скачать заново?

Объём архивируемых данных можно сократить, но полностью отказываться от резервного копирования файлов нельзя. Ядро WordPress, темы и плагины можно скачать из соответствующих источников, поэтому некоторые инструменты резервного копирования сохраняют только базу данных и папку uploads. Однако папка uploads содержит все медиафайлы, которые нельзя скачать повторно, в wp-config.php хранятся учётные данные базы данных и ключи безопасности, а любые кастомные или изменённые файлы являются незаменимыми. Резервное копирование wp-content и wp-config.php охватывает именно те части, которые уникальны для вашего сайта.

Как восстановить сайт на WordPress из резервной копии mysqldump и tar?

Распакуйте файловый архив в директорию сайта командой tar -xzf archive.tar.gz, затем импортируйте базу данных. С WP-CLI выполните wp db import db.sql — команда считает учётные данные из wp-config.php. Без WP-CLI выполните mysql -u DB_USER -p DB_NAME < db.sql для существующей базы данных. Восстанавливайте оба компонента вместе, а если домен изменился — выполните поиск и замену в базе данных для обновления сохранённых URL. Всегда проверяйте восстановление на промежуточном или локальном сайте, прежде чем доверять ему в продакшене.

Безопасно ли по-прежнему использовать mysqldump, или стоит перейти на mysqlpump?

Используйте mysqldump, а не mysqlpump. Утилита mysqlpump была объявлена устаревшей в MySQL 8.0.34 и полностью удалена в MySQL 8.4, поэтому скрипты, вызывающие её, завершаются с ошибкой на актуальных серверах. mysqldump по-прежнему поддерживается и актуален; MySQL рекомендует mysqldump или утилиты дампа MySQL Shell в качестве замены. Для создания согласованного снимка работающего сайта на InnoDB запускайте mysqldump с флагом --single-transaction — он позволяет выполнять выгрузку без блокировки таблиц.