Успешный отчёт резервного копирования ещё не отвечает на вопрос, запустится ли сайт из этой копии. Проверка состоит из трёх частей: прочитать сохранённые данные, сверить комплект файлов с базой и восстановить его на изолированном стенде. Результат стоит фиксировать в протоколе: какую копию проверили, что получилось и сколько занял путь до рабочего сценария.
Кому это актуально
Материал для администратора, которому нужно подтвердить пригодность уже созданного бэкапа сайта. Он пригодится перед обновлением, после смены способа копирования или при приёмке работы подрядчика.
Здесь предполагается, что копия уже есть и администратор вправе с ней работать. Выбор хранилища, расписание выгрузки и план переключения рабочего домена — отдельные задачи. Для проверки нужны доступ к конкретной копии, ключ расшифрования при наличии шифрования и отдельная среда для запуска.
Какие риски закрывает проверка
Ошибки могут обнаружиться на разных уровнях. Архив скачивается, но часть данных не читается. Файлы открываются, но в комплект не попала база. База импортируется, но её структура не подходит к сохранённой версии приложения.
Отдельный риск — проверка затягивается из-за отсутствующего ключа, неизвестной версии окружения или незадокументированного шага. Это время тоже относится к восстановлению. Пока его не измерили, обещание вернуть сайт к определённому сроку остаётся предположением.
Пробное восстановление проводят отдельно от рабочего сайта и его базы. До первого запуска отключают исходящие письма, платежи, обмен с CRM и другие внешние вызовы, а также фоновые задания.
Защита от удаления копии решает другую задачу. Наличие Object Lock в Amazon S3 само по себе не подтверждает, что из сохранённых данных получится рабочий сайт.
Как выполнить три проверки
1. Прочитать данные и проверить целостность
Выберите конкретную копию по идентификатору снимка, времени и составу. Сохраните исходный экземпляр; распаковку и дальнейшие действия выполняйте в отдельном каталоге. Проверьте, что доступны все части архива и ключи, необходимые для расшифрования.
Если при создании архива была сохранена контрольная сумма SHA-256, сравните её с суммой скачанного файла. Эталон должен быть получен из доверенного источника. Совпадение подтверждает неизменность относительно эталона, но не полноту содержимого и не работоспособность сайта.
Для репозитория restic различаются две проверки. По официальному руководству, обычный check проверяет структуру репозитория; чтение всех пакетов данных включается отдельно. В среде с уже настроенным репозиторием и безопасным доступом команды выглядят так:
restic check
restic check --read-dataПолное чтение требует времени, сетевого трафика и может увеличить стоимость скачивания. Выборочная проверка --read-data-subset охватывает только часть данных; её результат нельзя записывать как проверку всего репозитория.
Критерий этого этапа: выбранные данные доступны, проверка завершена без ошибок, а объём проверки указан явно. Если чтение оборвалось или обнаружено повреждение, сохраняйте сведения об ошибке и исходные копии; автоматическую очистку хранилища до разбора ситуации лучше приостановить.
2. Сверить файлы, базу и окружение
Составьте перечень того, без чего сайт не запустится: код нужного выпуска, пользовательские загрузки, база данных, настройки окружения и необходимые зависимости. Для каждого элемента укажите, входит ли он в копию или восстанавливается из другого доступного источника.
Сравните время и способ получения файлов и базы. Близкие отметки времени сами по себе не доказывают согласованность. Например, запись о загруженном документе могла попасть в базу позже, чем была скопирована папка с файлами.
Для MySQL важно знать способ создания дампа — выгрузки базы. Документация MySQL 8.4 ограничивает согласованность mysqldump --single-transaction транзакционными таблицами InnoDB; таблицы других типов могут изменяться во время выгрузки. Изменение структуры таблиц параллельно дампу также способно нарушить результат. Эта опция не синхронизирует базу с файлами сайта.
На отдельном сервере БД выполните импорт способом, подходящим к формату копии. Зафиксируйте ошибки и предупреждения, сравните структуру с требованиями сохранённого выпуска приложения. Затем проверьте несколько связей «запись — файл»: карточку товара и изображение, документ и вложение. В протокол выносите результат проверки, без персональных данных из записей.
Критерий этапа: известен состав комплекта, база импортирована, выбранные связи целы, совместимость приложения и схемы проверена. Несколько удачных примеров дают выборочную проверку; полный охват требует отдельных автоматизированных проверок проекта.
3. Восстановить сайт и пройти рабочий сценарий
Подготовьте стенд с подходящими версиями языка, базы, расширений и системных компонентов. Закройте его от публичного доступа. Ограничения сети и фоновых процессов настройте до запуска приложения: восстановленная конфигурация может содержать адреса рабочих интеграций.
В restic команда restore извлекает выбранный снимок в каталог, указанный через --target. Для испытания используйте явный идентификатор снимка и новый пустой каталог: существующие файлы в месте восстановления по умолчанию могут быть перезаписаны. Успешное извлечение файлов ещё не проверяет импорт БД и поведение приложения.
Начните отсчёт до получения копии и завершите после прохождения согласованного сценария. Отдельно запишите скачивание, распаковку, импорт, подготовку окружения и функциональную проверку. Так станет видно, на каком шаге теряется время.
Для магазина сценарий может включать открытие карточки, добавление товара в корзину и создание тестового заказа на стенде. Для личного кабинета — вход тестового пользователя и открытие документа. Используйте тестовые записи и заглушки внешних сервисов; реальную оплату, письмо клиенту или передачу заказа в рабочую CRM не запускайте.
Критерий этапа: сценарий проходит, тестовая запись сохраняется в базе стенда, связанные файлы открываются, внешних рабочих действий не произошло. Если интеграции заменены заглушками, в отчёте так и укажите: проверена внутренняя часть сценария.
Протокол пробного восстановления
Этот шаблон можно использовать при самостоятельной проверке и при приёмке работ. Он описывает поля отчёта, а не результаты конкретного проекта.
| Поле | Что зафиксировать |
|---|---|
| Копия | Идентификатор снимка или архива, время создания и часовой пояс |
| Комплект | Выпуск приложения, файлы, база, загрузки и исключения |
| Целостность | Инструмент, режим, охват проверки и итог |
| Окружение | Версии языка, сервера БД и необходимых расширений |
| Импорт базы | Способ, результат, предупреждения и нерешённые ошибки |
| Изоляция | Ограничения доступа, отключённые задания и внешние вызовы |
| Сценарий | Действия, ожидаемый результат и фактический итог |
| Время | Начало, окончание и длительность отдельных этапов |
| Решение | Пригодна ли копия для проверенного сценария, ограничения и дата следующего испытания |
Не включайте в общий отчёт пароли, ключи, содержимое клиентских записей и закрытые журналы. Технические подтверждения храните в доступном только ответственным сотрудникам месте.
Успешный тест относится к конкретному комплекту и окружению. После изменения схемы БД, состава файлов, шифрования или способа копирования проверку нужно повторить. Частоту плановых испытаний согласуют с тем, как быстро меняется проект и сколько данных допустимо потерять.
Что запросить у подрядчика
Для приёмки нужен не только скриншот зелёного статуса задания. Запросите:
- точный идентификатор проверенной копии и перечень исключений;
- результат чтения данных с указанием полного или выборочного охвата;
- подтверждение импорта БД и совместимости с версией приложения;
- протокол критичного сценария и перечень заменённых интеграций;
- фактическое время восстановления вместе с подготовительными шагами;
- список ограничений, ответственного за их устранение и дату повторной проверки.
Если подрядчик проверил только открытие главной страницы, пригодность корзины или кабинета остаётся неизвестной. Если не хватило доступа к ключу, испытание не завершено, даже когда сам архив исправен.
FAQ
Достаточно ли того, что архив распаковывается?
Нет. Это полезная проверка чтения, но она не отвечает на вопросы о составе копии, согласованности базы с файлами и выполнении пользовательского сценария.
Нужно ли восстанавливать сайт поверх рабочего?
Для проверки пригодности копии это не требуется. Используют отдельную среду и базу с ограниченными внешними соединениями. Рабочий проект продолжает обслуживать посетителей.
Можно ли считать время распаковки временем восстановления?
Только как отдельный этап. Полный замер включает получение копии, подготовку окружения, импорт базы и проверку согласованного сценария. В отчёте должны быть видны границы замера.
Когда администратор может справиться самостоятельно?
Когда известны состав копии и способ её создания, есть изолированный стенд, доступ к ключам и понятный критерий успеха. Если схема базы неизвестна, комплект неполон или нельзя безопасно отключить интеграции, сначала требуется разбор этих ограничений.
Как это решает OpenStart
Резервные копии входят в задачи сопровождения OpenStart; такой состав работ указан, например, в публичном кейсе поддержки сайта «Доширак». Проверку конкретной копии стоит оформлять как отдельную задачу с согласованным стендом, сценарием и протоколом приёмки.
Если собственный администратор прошёл проверки и зафиксировал ограничения, дополнительный подрядчик для этого этапа может не понадобиться. Когда восстановление останавливается на неизвестном окружении или несогласованном комплекте, полезна техническая диагностика.
Обсудить проверку резервной копии с OpenStart можно с описания CMS, формата копии и шага, на котором возникло затруднение. Менеджер уточнит условия и согласует первый этап и стоимость; архивы с данными и пароли в начальную заявку отправлять не нужно.