Перед обновлением WordPress подрядчик сообщает: «Резервная копия сделана». Владельцу сайта полезно уточнить, удалось ли из неё восстановить работающий сайт. Архив может существовать, а процедура восстановления — завершаться ошибкой.
Это реальный вопрос из поддержки: в обращении на WordPress.org пользователь сделал копию сайта клиента перед обновлением плагинов, а после сбоя не смог её восстановить. Одно обращение не показывает, насколько часто это происходит. Оно показывает, какой результат стоит проверять до начала работ.
Что именно сохранено
У типичного WordPress-сайта база данных и файлы — разные части резервной копии. Документация WordPress поясняет: для полного восстановления нужны обе. В базе находятся записи и другие данные сайта; в файлах — в том числе темы, плагины и загруженные изображения.
Поэтому в отчёте подрядчика нужны состав копии, время её создания и место хранения. Формулировка «скачали папку сайта» сама по себе не подтверждает, что сохранена база. Уточните также, сможет ли ответственный получить копию, если основной сайт и его панель управления не открываются.
Для небольшого сайта без заказов можно начать со встроенного резервного копирования хостинга или подходящего плагина. Самостоятельная задача владельца — прочитать условия услуги: что сохраняется, как долго хранятся версии и кто выполняет восстановление. Покупать отдельную систему до этой проверки преждевременно. Наличие кнопки восстановления всё равно стоит подтвердить пробным запуском.
Показать восстановленный сайт
Я рекомендую включить в приёмку перед обновлением пробное восстановление на отдельной закрытой площадке. Действующий сайт при такой проверке не заменяют. Это рекомендация для организации работ, а не универсальная инструкция для любого хостинга.
Попросите специалиста заранее ограничить доступ к тестовой копии и отключить реальные платежи, рассылки и передачу заявок во внешние системы. Если копия содержит персональные данные, доступ к ней получают только сотрудники, которым он нужен для проверки. Пароли и архивы с данными не отправляют в общую переписку.
Владельцу не нужно смотреть, как загружаются таблицы базы. Полезнее вместе с подрядчиком проверить результат:
- открываются важные страницы и изображения;
- ответственный сотрудник может войти в панель;
- доступны нужные карточки, записи и вложения;
- согласованный тест формы проходит через безопасный тестовый маршрут.
Если на сайте есть заказы, отдельно проверьте их наличие и состояния на момент копии. Работающая главная страница не подтверждает сохранность заказов. В отчёте нужны дата использованной копии, обнаруженные ошибки и фактическое время восстановления. Это время относится к проверенным условиям; при другой аварии срок может отличаться.
Что будет с заявками после создания копии
Предположим, копия создана утром, а обновление сломало сайт вечером. Это условный пример. Если вернуть утреннюю базу целиком, изменения, записанные в неё позже, не сохранятся автоматически. У бизнеса могли появиться новые заявки, заказы или правки сотрудников.
До обновления договоритесь, как поступать с такими данными. Для сайта с редкими правками может подойти короткое согласованное окно без изменений и свежая копия перед работами. Если заказы поступают постоянно, способ их сохранения и сверки должен предложить специалист с учётом устройства сайта. Нельзя обещать сохранность всех новых заказов только на основании наличия архива.
Здесь разработчик нужен для проверки связей между базой, файлами и внешними сервисами. Самостоятельный откат базы на работающем магазине без такого плана может создать дополнительные расхождения.
Как сформулировать задачу подрядчику
Можно передать такое условие приёмки:
До обновления восстановить согласованную резервную копию на закрытой тестовой площадке. Зафиксировать её состав и дату, проверить страницы, файлы, вход сотрудника и согласованный сценарий заявки. Указать, кто выполняет восстановление при сбое и как сохраняются изменения после момента копии.
Отдельно согласуйте стоимость этой проверки, хранения копий и дальнейшего сопровождения. Не всякая услуга резервного копирования включает работу специалиста по восстановлению. Повторная проверка особенно полезна после смены хостинга или способа хранения данных: прежний результат не подтверждает работу новой схемы.
Если перед обновлением непонятно, что именно сохранено и кто сможет вернуть сайт в работу, можно обсудить проверку в Telegram. Для первого разговора достаточно адреса сайта и описания текущего резервного копирования. Доступы и сам архив присылать не нужно.