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