Бэкап сайта на WordPress своими руками: файлы, база, расписание и проверка

Я пять лет руковожу небольшим digital-агентством: делаем сайты, магазины и рекламу для малого бизнеса. Самый неприятный звонок от клиента звучит так: «сайт сломался после обновления, верните как было». И часто копия вроде бы есть, но старая, неполная или её ни разу не пробовали развернуть.

Разберу, что копировать, как настроить копию по расписанию, где её хранить и как проверить, что она рабочая. Гайд для сайтов на виртуальном хостинге или на своём сервере (VPS) с доступом по SSH.

Почему не стоит полагаться только на копии хостинга

Хорошие хостинги делают копии сами: например, на виртуальном хостинге Timeweb, по данным компании, копии создаются ежедневно и хранятся 30 дней. Но такая копия лежит у того же провайдера, что и сайт: если проблема с аккаунтом или вы переезжаете, она окажется там же, где проблема. И расписанием вы не управляете, а перед большим обновлением хочется снять копию «прямо сейчас».

Поэтому правило простое: копия хостинга плюс своя копия, которая хранится в другом месте.

Что входит в полную копию сайта

Что входит в полную копию сайта на WordPress

Источник: иллюстрация автора статьи (здесь и далее)

Сайт на WordPress состоит из трёх частей, и в копии нужны все три:

Файлы. Главное лежит в папке wp-content: темы, плагины и загруженные картинки. Картинки из uploadsбольше восстановить неоткуда.
База данных. В ней записи, страницы, комментарии, заказы, настройки плагинов. Без базы файлы бесполезны: это пустой шаблон.
Файл wp-config.php. В нём доступы к базе и ключи безопасности. Его удобно сохранить отдельно, чтобы при восстановлении не вспоминать имя базы и пароль.

Способ 1. Вручную через панель хостинга

Подходит, если сайт небольшой и копия нужна раз в месяц или перед обновлением.

В панели хостинга откройте файловый менеджер, выделите папку сайта и создайте архив. Скачайте его к себе.
Откройте phpMyAdmin (обычно он есть в разделе баз данных), выберите базу сайта, вкладка «Экспорт», формат SQL. Скачайте файл.
Положите архив и файл базы в одну папку, в название добавьте дату, например site-2026-10-22.
Загрузите папку в облачное хранилище или на внешний диск.

Минус ручного способа: про него забывают.

Способ 2. Скрипт и расписание на сервере

Если у вас VPS (например, облачный сервер в Timeweb Cloud) или хостинг с доступом по SSH и cron, копию можно поручить серверу. Ниже минимальный скрипт.

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

Создайте файл, например, /root/backup.sh:

#!/bin/bash
D=$(date +%F)
mkdir -p /backup
mysqldump DBNAME > /backup/db-$D.sql
tar -czf /backup/files-$D.tar.gz /var/www/site/wp-content /var/www/site/wp-config.php
find /backup -type f -mtime +14 -delete

Скрипт запоминает дату, выгружает базу (DBNAME замените на имя своей базы), упаковывает wp-content и wp-config.php в архив (путь /var/www/site замените на свой) и удаляет копии старше 14 дней, чтобы диск не переполнился.

Пароль от базы лучше не писать прямо в скрипт. Создайте файл ~/.my.cnf
с правами 600:

[client]
user=USER
password=PASS

Тогда mysqldump возьмёт доступы из него, и пароль не будет виден в списке процессов.

Сделайте скрипт исполняемым и проверьте его вручную:

chmod +x /root/backup.sh
/root/backup.sh
ls -lh /backup

Если появились два файла с сегодняшней датой и ненулевым размером, всё работает. Откройте crontab -e и добавьте строку:

0 3 * * * /root/backup.sh

Копия будет создаваться каждый день в 3 часа ночи по времени сервера, когда на сайте меньше всего посетителей.

Где хранить копию

Копия на том же сервере спасёт от сломанного плагина, но не от проблем с самим сервером. Варианты по возрастанию надёжности:

скачивать к себе на компьютер раз в неделю (работает, пока не забываете);
копировать на второй сервер командой rsync или scp в том же скрипте;
отправлять в объектное хранилище S3. В Timeweb Cloud такое хранилище есть, и к нему можно подключиться утилитой rclone или s3cmd, добавив одну строку в конец скрипта.

Проверка: копия рабочая, только если её развернули

Как проверить, что копия сайта рабочая

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

Скачайте последний архив и файл базы.
Создайте тестовый поддомен (например, test.вашсайт.ru) и пустую базу данных.
Распакуйте файлы, импортируйте базу через phpMyAdmin или командой mysql DBNAME < db-ДАТА.sql.
В wp-config.php укажите доступы к тестовой базе. В таблице wp_options поменяйте поля siteurl и home на тестовый адрес.
Откройте главную, войдите в админку, откройте две-три записи и страницу с картинками.

Если всё открылось, копия рабочая. Если видите ошибку подключения к базе, пустые страницы или пропавшие картинки, значит, в копии чего-то не хватает. Чинить это лучше сегодня, а не в день аварии. После проверки тестовый поддомен и базу удалите.