Резервная копия сайта: что копировать, куда хранить и как восстановить

Резервная копия сайта — это две вещи: архив файлов и дамп базы данных. Только вместе они позволяют вернуть сайт после неудачного обновления, взлома или ошибки хостинга. Бэкапы хостинга — хорошая страховка, но не единственная: их делает тот же сервер, который может сломаться. Разберём, что входит в бэкап сайта, как сделать его вручную и по расписанию, где хранить и как восстановить. Все команды мы проверили на тестовом WordPress 26 сентября 2026 года: сделали копию, удалили запись и плагины, восстановили — выводы ниже настоящие.

Что входит в резервную копию сайта

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

Самое ценное — база и папка загрузок (wp-content/uploads в WordPress): движок и плагины можно скачать заново, а тексты и фото — нет. Файл wp-config.php тоже нужен: в нём доступ к базе и ключи. Храните бэкап так же бережно, как пароли.

Резервная копия на хостинге

На обычном хостинге копии обычно делаются автоматически — проверьте, что это так и у вас, и сколько они хранятся. Условия двух хостингов на дату проверки:

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

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

Если у вас VPS или свой сервер, бэкап — это две команды. Наш тестовый сайт работает в Docker Compose (WordPress + MariaDB, как в статье Docker Compose для начинающих), поэтому команды для базы идут через docker compose exec.

Резервная копия базы сайта

cd /srv/wp
docker compose exec -T db sh -c 'mariadb-dump --single-transaction -u "$MARIADB_USER" -p"$MARIADB_PASSWORD" "$MARIADB_DATABASE"' | gzip > backup/db-$(date +%F).sql.gz

Пароль берётся из переменных окружения внутри контейнера и не попадает в историю команд. --single-transaction снимает согласованную копию без остановки сайта. Без Docker команда та же, только без docker compose exec: mariadb-dump или mysqldump с именем пользователя и базы. На WordPress есть и вариант через WP-CLI: wp db export (описание команды).

Архив файлов

tar -czf backup/files-$(date +%F).tar.gz -C /srv/wp html
ls -lh backup/

total 26M
-rw-r--r-- 1 root root 18K Sep 26 07:31 db-2026-09-26.sql.gz
-rw-r--r-- 1 root root 26M Sep 26 07:31 files-2026-09-26.tar.gz

У свежего WordPress дамп базы весит 18 КБ, а архив файлов — 26 МБ: почти всё это движок. На живом сайте основной объём даст папка загрузок.

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

gzip -t backup/db-2026-09-26.sql.gz && tar -tzf backup/files-2026-09-26.tar.gz >/dev/null && echo "архивы целы"

архивы целы

Бэкап сайта по расписанию

Ручные бэкапы забываются, поэтому соберём всё в скрипт и поставим его в cron. Скрипт делает копию базы и файлов и удаляет архивы старше 14 дней — мы проверили и это: подложенный архив «20-дневной давности» исчез после запуска.

#!/bin/sh
# Ночной бэкап сайта: база + файлы, храним 14 дней
set -e
cd /srv/wp
D=$(date +%F)
docker compose exec -T db sh -c 'mariadb-dump --single-transaction -u "$MARIADB_USER" -p"$MARIADB_PASSWORD" "$MARIADB_DATABASE"' | gzip > backup/db-$D.sql.gz
tar -czf backup/files-$D.tar.gz -C /srv/wp html
find backup -name '*.gz' -mtime +14 -delete

Сохраните как /srv/wp/backup.sh, сделайте исполняемым (chmod +x) и добавьте в crontab запуск каждую ночь, например в 3:30:

30 3 * * * /srv/wp/backup.sh >> /var/log/site-backup.log 2>&1

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

Куда хранить резервные копии

Копия на том же сервере защищает от ошибки в обновлении, но не от поломки диска, взлома или закрытого аккаунта. Документация WordPress советует держать как минимум три последние копии в разных местах. Удобное правило:

• на сервере — несколько последних дней, для быстрого отката;
• на другом сервере или в облачном хранилище — копировать туда архивы по расписанию, например rsync или scp по SSH-ключу;
• дома — раз в месяц скачать свежую копию на компьютер или домашний сервер.

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

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

Проверим на деле. Удаляем запись и всю папку плагинов — имитируем неудачное обновление:

wp post delete 4 --force
rm -rf html/wp-content/plugins

Восстанавливаем базу из дампа:

zcat backup/db-2026-09-26.sql.gz | docker compose exec -T db sh -c 'mariadb -u "$MARIADB_USER" -p"$MARIADB_PASSWORD" "$MARIADB_DATABASE"'

Восстанавливаем файлы. Контейнер перед этим останавливаем — почему, объясним ниже:

docker compose stop wordpress
rm -rf html && tar -xzf backup/files-2026-09-26.tar.gz -C /srv/wp
docker compose up -d

Проверяем — запись и плагины на месте:

ID	post_title
4	Запись до бэкапа
1	Hello world!

akismet
hello.php
index.php

На хостинге восстановление ещё проще: в разделе резервных копий выберите дату и нажмите «Восстановить» для нужных файлов или базы. У REG.RU есть оговорка: база, которую восстанавливаете, должна уже существовать в панели хостинга.

Совет: хотя бы раз попробуйте восстановить сайт из копии на тестовом сервере или в отдельной папке. Бэкап, из которого ни разу не восстанавливали, — это только надежда на бэкап.

Частые ошибки при бэкапе

• Только файлы без базы (или наоборот). Скачали папку сайта по FTP — а все записи были в базе.
• После восстановления файлов сайт отдаёт 403. Мы на это наткнулись: удалили папку html, которая подключена к контейнеру, и распаковали новую. Контейнер остался смотреть на удалённую папку и видел пустоту. Помог docker compose restart — или, как в инструкции выше, остановить контейнер до замены файлов.
• Дамп MariaDB не загружается в MySQL. Новые версии mariadb-dump пишут первой строкой команду включения «sandbox mode» — у нас это /*M!999999\- enable the sandbox mode */. По документации MariaDB, её не понимает клиент MySQL и старые версии клиента MariaDB. При переезде с MariaDB на MySQL удалите эту строку из дампа.
• Большие файлы не попали в хостинговую копию. Как у REG.RU с файлами больше 300 МБ — архивы, видео и старые бэкапы внутри папки сайта нужно копировать отдельно.
• Бэкапы внутри папки сайта. Архив backup.zip в корне сайта может скачать любой, кто угадает адрес, — вместе с паролем к базе из wp-config.php. Храните копии вне публичной папки.
• Нет проверки. Скрипт по cron месяц падал с ошибкой, а вы не знали. Смотрите лог и размер свежих архивов.

Если сайт уже упал и нужно понять, откатываться ли на копию, начните с лога ошибок — как его читать, в статье ошибка 500 и 502 Bad Gateway.

Резервные копии нужны не только сайтам. В умном доме, например, без копии конфигурации Zigbee2MQTT с ключом сети придётся заново подключать все устройства — см. статью про Zigbee2MQTT.

Источники: резервное копирование WordPress, wp db export, mariadb-dump, бэкапы на хостинге Timeweb, бэкапы на хостинге REG.RU. Проверено 26 сентября 2026 года.