Резервная копия сайта: что сохранять и как проверить восстановление
Сообщение «резервная копия создана» подтверждает выполнение операции, но не готовность сайта к восстановлению. Разбираем, что включить в копию, как выбрать частоту и какие проверки провести на отдельной площадке.
Архив с названием сайта может содержать только часть проекта: например, изображения и код без базы данных. Проблема обнаруживается в момент восстановления, когда страницы открываются, но отсутствуют товары, настройки или последние заказы.
Я предлагаю оценивать копирование через конкретный вопрос: получится ли из сохранённых материалов поднять рабочий сайт и сколько времени это займёт? Ответ требует не только архива, но и доступов, инструкции и практической проверки.
Что должно входить в резервную копию
- Код сайта, темы, плагины и собственные доработки.
- База данных с нужными таблицами, если она используется.
- Загруженные изображения, документы и другие пользовательские файлы.
- Конфигурация приложения и сведения о необходимых настройках сервера.
- Отдельные данные во внешнем хранилище, если сайт зависит от них.
Для WordPress необходимость сохранять и файлы, и базу данных прямо объясняется в официальной инструкции по резервному копированию. Скачивание каталога сайта обычно не включает базу: для неё нужен отдельный экспорт или снимок средствами хостинга.
Для статического сайта состав другой: опубликованные файлы, исходники и материалы сборки. Если обращения обрабатывает отдельный сервер, его код и данные нужно учитывать отдельно. Репозиторий исходного кода помогает восстановить программу, но не заменяет копию пользовательских загрузок и рабочих данных.
Как выбрать частоту копирования
Определите, сколько новых данных допустимо потерять. Если копия создаётся ночью, при сбое вечером в ней не окажется изменений за текущий день. Для магазина с постоянными заказами такой промежуток может быть неприемлемым, а для редко меняющейся страницы он может подходить.
Частота зависит от потока данных, а не от размера сайта. Согласуйте расписание для базы и файлов, срок хранения и отдельную копию перед существенными изменениями. Для проектов с активной записью нужен способ получить согласованное состояние: база не должна ссылаться на файлы, которых ещё нет в копии.
Полезно хранить несколько точек восстановления. Если ошибку заметили не сразу, самый свежий архив уже может содержать повреждённые данные. Зеркало, которое немедленно повторяет каждое удаление, не даёт возможности вернуться к состоянию до ошибки.
Где хранить копии и кому дать доступ
Единственная копия на том же сервере может исчезнуть вместе с рабочим сайтом. Предусмотрите отдельное хранилище с ограниченным доступом. Проверьте, кто может скачать архив и что произойдёт при блокировке основного аккаунта хостинга.
В копиях могут находиться клиентские данные, ключи и настройки подключения. Архивы нельзя размещать в публичном каталоге сайта. Для передачи и хранения выбирайте защищённые способы, а сроки удаления старых копий задавайте осознанно.
Инструкция должна указывать расположение копий, состав комплекта и порядок восстановления. Пароли и ключи лучше передавать через согласованное защищённое хранилище, а в инструкции оставить способ получения доступа.
Как проверить восстановление на отдельной площадке
- Выберите конкретную копию и запишите её дату, состав и размер.
- Подготовьте отдельное окружение с подходящими версиями программ и ресурсами.
- Отключите отправку писем, платежи, CRM и другие действия, затрагивающие клиентов.
- Восстановите файлы, базу и настройки подключения по инструкции.
- Проверьте страницы, изображения, вход в административную панель и важные функции.
- Сравните несколько записей и последние данные с выбранной точкой восстановления.
- Зафиксируйте затраченное время, ошибки и необходимые исправления.
Тестовую копию ограничьте по доступу и закройте от индексации. Одного запрета индексации недостаточно для защиты клиентских данных: доступ к самой площадке должен быть ограничен. После проверки определите, как удалить временное окружение.
Формы и обмен данными проверяйте с тестовыми получателями и подключениями. Восстановленная копия не должна повторно отправлять старые письма, создавать сделки или запускать реальные списания. Перед её запуском проверьте также фоновые задания и расписание.
Почему открывшейся главной страницы недостаточно
Проверьте функции, ради которых существует сайт: поиск, каталог, карточки, корзину, сохранение формы и административную панель. Для проекта с личными кабинетами важны вход и доступ к данным нужного пользователя. Отсутствующие загрузки и ошибки настроек часто видны только в этих сценариях.
Пример результата проверки: «Копия от 8 октября восстановлена за 45 минут. Страницы и изображения доступны, тестовая заявка сохранена. Не восстановлены два документа из отдельного хранилища». Время и объём здесь условные; такой формат помогает показать ограничения, а не объявлять весь проект восстановленным по одному экрану.
Что учесть при реальном возврате сайта
Возврат к старой базе может удалить заказы и обращения, появившиеся после копирования. Перед восстановлением сохраните текущее состояние, оцените новые данные и согласуйте способ их переноса. Иногда исправление отдельной ошибки безопаснее полного возврата базы.
Если копия готовится перед обновлениями, полезно заранее согласовать порядок обновления WordPress и плагинов.