-
Задача
Что сломалось или должно измениться
-
Подготовка
Доступы, копия и безопасный тестовый контур
-
Проверка
Основной сценарий и соседние функции
-
Передача
Описание изменений и порядок отката
Проверять резервную копию Битрикса нужно восстановлением на изолированном стенде. Наличие архива и сообщение «копирование завершено» не доказывают, что магазин запустится, изображения откроются, а заказы сохранятся. Рабочий сайт при такой репетиции продолжает обслуживать клиентов: его базу, файлы и домен не переключают на тестовую копию.
Хороший результат проверки — восстановленный стенд, протокол контрольных действий и измеренное время работы. Если копия неполная, пароль неизвестен или окружение несовместимо, проблему лучше обнаружить до аварии. Ниже — план для владельца сайта и администратора, а не инструкция по перезаписи действующего сервера.
Определите, что именно нужно восстановить
Составьте перечень частей проекта: база данных, файлы приложения, пользовательские загрузки, настройки окружения, расписания, интеграции и внешние хранилища. Не считайте, что один архив автоматически содержит всё. Например, фотографии могут храниться отдельно, а конфигурация сервера — вне каталога сайта. Для каждой части укажите место хранения и ответственного за доступ.
В документации Битрикса по резервному копированию рассматриваются создание архивов и восстановление. Состав конкретной копии зависит от выбранных параметров. Проверьте дату, успешное завершение задания, наличие всех частей многотомного архива и доступность файлов. Запишите контрольные суммы, если ваша система хранения позволяет их получить.
Согласуйте две бизнес-величины: сколько последних изменений допустимо потерять и за какое время нужно вернуть работу. Это разные требования. Ежедневная копия может восстановиться быстро, но не содержать заказы после момента её создания. Отдельно решите, как будут сверяться недавние оплаты, обращения и изменения остатков с внешними системами.
Подготовьте изолированный тестовый контур
Используйте отдельные каталог, базу, пользователя базы данных и домен либо закрытый адрес стенда. Проверьте фактические пути и подключения перед запуском восстановления. Название базы с суффиксом «test» не является защитой, если конфигурация всё ещё указывает на рабочий сервер. Доступ к стенду ограничьте авторизацией или сетью; одного robots.txt для защиты данных недостаточно.
До первого запуска отключите исходящие письма, SMS, вебхуки, обмен с 1С, отправку в CRM, боевые платежи и автоматические задания. Лучше ограничить исходящие соединения самого стенда и разрешать только необходимые тестовые направления. Копия может содержать действующие ключи: простая замена адреса сайта не делает её безопасной для клиентов.
Вместо реальной почты подключите тестовый приёмник, вместо боевых платёжных настроек — разрешённый тестовый режим. Для обмена используйте специально подготовленную базу или заглушку. Сохраните перечень отключённых интеграций: иначе команда примет намеренно остановленную отправку за неисправность восстановленного проекта. Не публикуйте этот перечень вместе с секретами.
Проверьте доступы и совместимость окружения
Сверьте версии PHP, базы данных, модулей и расширений, права на каталоги и доступный объём диска. Окружение стенда должно соответствовать проверяемому сценарию. Если одновременно обновить сервер, CMS и собственный код, будет трудно понять, почему восстановление не работает. Сначала воспроизведите известную конфигурацию, обновление проверяйте отдельным этапом.
Для зашифрованной копии заранее проверьте пароль и процедуру его получения ответственным сотрудником. Официальная справка об облачных резервных копиях объясняет особенности хранения и шифрования. Пароли не должны зависеть от памяти одного человека; храните их в согласованном защищённом хранилище с контролем доступа.
Не передавайте архив в публичные онлайн-проверки. В нём могут находиться контакты клиентов, история заказов и ключи интеграций. Для работы подрядчика используйте разрешённый канал, ограниченный доступ и оговорённый срок хранения. Если для сценария достаточно обезличенных данных, подготовьте их до функциональных тестов.
Восстановите копию и пройдите контрольный маршрут
Запишите время начала, выбранный архив и настройки стенда. Восстановите файлы и базу по процедуре для вашей версии продукта. После запуска проверьте конфигурацию подключений ещё раз: особенно адрес базы, пути загрузок, домены и обработчики фоновых задач. Только затем переходите к просмотру страниц.
- Откройте главную, категорию, карточку, поиск и информационную страницу.
- Проверьте изображения, документы, фильтры и предусмотренные роли пользователей.
- Создайте помеченный тестовый заказ без реального списания и отправки клиенту.
- Убедитесь, что заказ записался в тестовую базу с товарами, количеством и суммой.
- Проверьте административный вход, журналы ошибок и возможность изменить тестовый товар.
- Сопоставьте несколько записей до даты архива: наличие данных важнее открытия одной страницы.
HTTP 200 не подтверждает работу магазина. Сервер может успешно отдавать оболочку страницы, пока поиск, корзина или запись заказа не работают. Для приёмки используйте отдельный сценарий проверки заказа. Публичные сканеры не запускайте на закрытом стенде с реальными клиентскими данными.
Оформите протокол восстановления
В протоколе нужны версия копии, состав данных, время подготовки и восстановления, проверенные сценарии, найденные дефекты и результат повторной проверки. Отдельно укажите ручные шаги: восстановление доступа к хранилищу, настройка расширения, исправление пути. Если они остались только в переписке, следующая команда может не повторить результат.
Учебный пример: файлы и база восстановились, но изображения в карточках отсутствуют. Проверка обнаружила внешнее хранилище, не включённое в первоначальный перечень. Задача — добавить процедуру восстановления или повторного подключения этого хранилища и повторить тест. Формулировка «сайт открылся» в таком случае была бы преждевременной приёмкой.
После проверки сравните измеренное время с согласованными требованиями. Если восстановление слишком долгое, определите конкретную причину: загрузка архива, распаковка, импорт базы или ручная настройка. Ускорение нужно проверять повторной репетицией, а не уменьшением времени в регламенте на бумаге.
Что делать со стендом после теста
Не оставляйте восстановленную копию открытой в интернете. Закройте доступ, удалите временные ключи и данные по согласованной процедуре либо сохраните защищённый стенд на установленный срок. Не удаляйте исходную резервную копию только потому, что один тест прошёл успешно. Политика хранения должна учитывать несколько точек восстановления и отдельные места хранения.
Повторяйте проверку после значимых изменений архитектуры и по согласованному графику. Частоту выбирают по изменчивости проекта и требованиям бизнеса. Если нужен план восстановления с ответственными и контрольными сценариями, его можно включить в техническую поддержку сайта.
Частые вопросы
Нужно ли останавливать рабочий магазин?
Для восстановления уже готовой копии на отдельном стенде — нет. Получение согласованного снимка данных и реальные аварийные переключения планируются отдельно с администратором.
Можно ли проверить только распаковку архива?
Это полезная начальная проверка, но она не подтверждает запуск приложения и сохранность рабочего сценария. Нужны запуск, проверка данных и тестовые действия.
