Бэкап сайта на хостинге: правило 3-2-1, инструменты и проверка восстановления

Полный бэкап сайта состоит из дампа базы данных и архива файлов вместе с каталогом uploads, сделанных согласованно, сохранённых минимум в двух местах, одно из которых за пределами сервера сайта, и проверенных пробным восстановлением. На нашем тестовом стенде большинство типичных ошибок давали копию, которая создавалась без единого предупреждения, а проблема всплывала только при восстановлении. Ниже: правило 3-2-1 простыми словами, таблица «что бэкапить, чем, как часто и как проверять», замеры mysqldump, сжатия и restic и пошаговая проверка восстановления.

Правило 3-2-1 для сайта на хостинге

Правило 3-2-1 означает: три копии данных, на двух разных носителях или системах, одна из них в другом месте. Для сайта на виртуальном хостинге это выглядит так. Первая копия: сам рабочий сайт. Вторая: резервная копия, которую делает хостинг и хранит за пределами сервера сайта. Третья: ваша собственная копия у другого провайдера, в облачном хранилище или на вашем компьютере. Важно не количество копий, а их независимость: если все три лежат на одном диске или доступны из одной учётной записи, это одна копия, просто трижды.

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

Что бэкапить, чем, как часто и как проверять

Таблицы логов, статистики и кеша плагинов часто весят больше всего контента. На стенде таблица логов давала примерно 350 МБ из 404 МБ дампа. Если её чистить, копии становятся меньше и быстрее; подробнее об этом в разборе оптимизации базы данных на хостинге.

База данных: почему важен --single-transaction

Мы запускали скрипт, который непрерывно создавал «заказы»: одна строка в wp_posts и четыре строки в wp_postmeta в одной транзакции, около 45 заказов в секунду. Через две секунды стартовал дамп в трёх режимах.

Без блокировок дамп читает таблицы по очереди: wp_postmeta раньше, чем wp_posts. Заказы, сохранённые между этими двумя чтениями, попали в копию без суммы, почты и способа оплаты. Такой дамп импортируется без ошибок, и проблема видна только тогда, когда клиент спрашивает о своём заказе. Режим по умолчанию копию не портит, но на время дампа останавливает запись: на большой базе это минуты, когда магазин не может принять заказ. --single-transaction снимает согласованный снимок InnoDB без блокировки. На таблицах MyISAM он не помогает, поэтому старые таблицы стоит перевести на InnoDB.

mariadb-dump --single-transaction --quick --default-character-set=utf8mb4 wp > db.sql
tail -1 db.sql
-- Dump completed on 2026-11-10 14:51:46

Без нагрузки оба режима работали одинаково: 3,2-3,9 секунды на 404 МБ. Разница проявляется только тогда, когда в базу пишут, то есть как раз в рабочее время магазина.

Файлы: чем сжимать архив

Каждый компрессор работал в один поток на одних и тех же данных.

Фото в формате JPEG уже сжаты, поэтому архив файлов почти не уменьшается, каким бы компрессором вы ни пользовались. Дамп базы сжимается в пять раз. zstd -3 показал лучшее соотношение: в 5-11 раз быстрее gzip и чуть меньший файл. Максимальные уровни zstd и xz сэкономили ещё около 15 МБ на дампе ценой пяти минут процессорного времени; на общем хостинге это лишняя нагрузка.

Инкрементные копии: что даёт дедупликация restic

restic и borg делят данные на фрагменты и сохраняют только новые. Первая копия сайта с дампом весила 791 МБ (в хранилище 427 МБ, потому что restic сжимает данные). Что было дальше:

• Добавили одну запись, одно фото на 454 КБ и 20 заказов: вторая копия добавила 4,6 МБ.
• Удалили 1000 самых старых строк таблицы логов, как это делают плагины при чистке: третья копия добавила 359,6 МБ, почти весь дамп.
• То же изменение, но дамп с одной строкой на INSERT (--skip-extended-insert): добавилось 7,6 МБ.

Причина в том, что обычный дамп упаковывает сотни строк в одну команду INSERT. Удаление строк в начале таблицы сдвигает границы всех следующих команд, и для restic весь дальнейший файл выглядит новым. Дамп с отдельной строкой на INSERT дедуплицируется хорошо, но у этого есть цена: на стенде он импортировался 507 секунд против 35. Если копии лежат в хранилище с оплатой за объём, а восстановление случается редко, такой обмен оправдан; если важна скорость восстановления, оставьте обычный дамп и храните меньше версий. Для borg мы этих замеров не делали: в контейнере стенда он не запустился из-за несовместимой версии Python, поэтому цифры относятся только к restic.

export RESTIC_REPOSITORY=sftp:backup@storage.example.net:/restic
export RESTIC_PASSWORD_FILE=~/.restic-pass
restic init
restic backup ~/backup/db.sql ~/web/example.com/public_html
restic forget --keep-daily 14 --keep-weekly 8 --prune
restic check

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

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

Мы воспроизвели худший случай: остановили базу, удалили весь каталог «сервера» вместе с локальными копиями и восстановили сайт из копии restic в новый экземпляр MariaDB с пустой папкой сайта.

restic restore latest --target /srv/restore
Summary: Restored 3523 files/dirs (789.971 MiB) in 0:02
mariadb -e "CREATE DATABASE wp"
mariadb wp < db.sql
curl -s -o /dev/null -w "%{http_code}\n" http://bench.test:8122/
200
curl -sI "http://bench.test:8122/wp-json/wp/v2/posts?per_page=1" | grep -i x-wp-total
X-WP-Total: 6002

От запуска до ответа 200 прошло 23 секунды: 4 на файлы, 19 на импорт базы. Количество записей, заказов и наибольший ID совпали с рабочим сайтом, новое фото отдалось с той же контрольной суммой, кириллица в заголовках не пострадала. Первая попытка, кстати, провалилась из-за нашей же ошибки: restic сохранил пути так, как мы их передали, и файлы развернулись не в ту папку, которую ждал скрипт. Именно такие мелочи и показывает пробное восстановление.

Минимальная проверка, которую стоит делать раз в месяц:

1. Проверьте целостность архивов: zstd -t, gzip -t или restic check.
2. Убедитесь, что дамп заканчивается строкой «Dump completed».
3. Импортируйте дамп в отдельную тестовую базу и сравните количество записей, заказов и пользователей с рабочим сайтом.
4. Разверните файлы на тестовом поддомене, проверьте код 200, вход в админку и несколько старых картинок.
5. Запишите, сколько времени это заняло: это ваше реальное время восстановления.

По сути, это та же процедура, что и перенос WordPress на другой хостинг, только без переключения домена.

Четыре сбоя, которые мы воспроизвели на стенде

Копия без каталога uploads

Архив, сделанный с --exclude=wp-content/uploads, весил 15 МБ вместо 361 МБ. После восстановления главная страница отвечала 200, REST API показывал все 6002 записи, но каждое фото давало 404: в базе 450 вложений, в папке 0 файлов. Такой сайт выглядит живым, пока вы не откроете любую запись. Каталог uploads часто исключают, чтобы копия поместилась в лимит, поэтому проверяйте количество файлов в копии.

Копии только на том же сервере

После удаления каталога «сервера» вместе с сайтом исчезли и дамп, и архив файлов, и контрольные суммы, лежавшие рядом: No such file or directory. Сайт спасла только копия в отдельном хранилище. К тому же архивы на сервере нельзя держать в корневой папке сайта: их можно скачать по прямой ссылке. Для каталога с копиями достаточно прав доступа 700 и 600 на файлы.

Обрезанный файл

Копия, оборванная на 60% (переполненный диск или прерванная передача), не проходит zstd -t: «Read error (39) : premature end»; gzip пишет «unexpected end of file». Хуже с несжатым дампом: импорт остановился с ERROR 1064, но перед этим успел создать 7 таблиц из 13 и 3825 строк wp_posts из 9304. Таблиц пользователей и рубрик не было, то есть войти в админку уже нельзя. Признак обрезанного дампа простой: в конце нет строки «Dump completed».

Неправильная кодировка или сопоставление

Дамп с --default-character-set=latin1 завершился без ошибок, но в 5986 заголовках из 6001 кириллица превратилась в вопросительные знаки. Это необратимая потеря: в файле просто нет правильных байтов. Другой вариант: дамп без строки SET NAMES, импортированный клиентом, работающим в latin1 (так вёл себя клиент mariadb на стенде в сессии без UTF-8 локали). Заголовок, начинавшийся со слова «Доставка», превратился в «Ð”Ð¾Ñтавка», а с --default-character-set=utf8mb4 тот же файл импортировался правильно. Третий случай мы эмулировали, заменив в дампе сопоставление (collation) на то, которое обычно создаёт MySQL 8: MariaDB 10.11 ответила ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci' и не создала ни одной таблицы. Решение: заменить сопоставление на поддерживаемое, например utf8mb4_unicode_520_ci, и повторить импорт.

Если ситуация такая, делайте так

Если сайт уже лежит, начните с диагностики проблем хостинга: часто причина в плагине или переполненном диске, и откат к вчерашней копии лишь сотрёт новые заказы. Скрипт резервного копирования удобно запускать по расписанию через cron; добавьте в него проверку строки «Dump completed» и zstd -t, а о сбое пусть сообщает мониторинг сервера и сайта.

Бэкапы на хостинге RichHost

На всех тарифах RichHost есть постоянные бэкапы в облако: это копия, которая хранится за пределами сервера сайта. По правилу 3-2-1 к ней стоит добавить собственную копию в другом месте и время от времени проверять её восстановлением на тестовом поддомене. Вопросы о резервных копиях можно задать поддержке: она работает с 10:00 до 20:00 по Киеву и отвечает примерно за 30 минут.

Частые вопросы

Достаточно ли бэкапов, которые делает хостинг?

Для большинства сбоев да, но правило 3-2-1 требует ещё одной независимой копии. Она спасает, когда проблема с учётной записью, оплатой или когда нужна версия старше той, что хранится.

Как часто делать бэкап сайта?

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

Можно ли копировать базу, когда сайт работает?

Да, с --single-transaction для таблиц InnoDB. На стенде такой дамп не потерял ни одного заказа и не останавливал запись, а дамп без блокировок терял данные 3-7 заказов за запуск.

Как проверить бэкап, не сломав рабочий сайт?

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