Бэкап сайта проверяют восстановлением: код в git, база отдельно

У сайта есть разные части: код задаёт поведение, база хранит заявки, отдельное хранилище держит загруженные документы. Они могут жить у разных поставщиков.

Архив папки сайта не обязательно включает базу. Документация WordPress разделяет резервное копирование файлов и базы: для восстановления нужны обе части.

Попросите подрядчика назвать состав копии и показать, где она лежит. «Хостинг всё сохраняет» не отвечает на вопрос, что удастся поднять при потере доступа к хостингу.

В разработке с агентами правки кода сохраняют коммитами. Инженер ведёт машину агентов и проверяет изменения; журнал версий позволяет найти, что именно поменялось.

На живом /open 7 октября 2026 года: 7 063 коммита за 98 дней. Счётчик идёт по основной ветке с 1 июля 2026; это изменения файлов, включая документацию.

В Git команда revert создаёт новую запись, отменяющую выбранное изменение. Базу и внешние сервисы она не возвращает; старый код надо проверить с текущими данными.

После изменения структуры базы старый код может ожидать поля, которых уже нет. Подрядчик должен проверить совместимость или подготовить отдельный возврат схемы.

В репозитории может быть скрипт удаления ящика, но не его письма. Прежде чем запускать такой скрипт, нужна проверенная выгрузка истории.

Кто разрешает откат и отвечает за последствия, разбираем в статье об ответственности за ошибки ИИ. Здесь задача владельца: принять доказательство возврата данных.

Обсуждение начинайте с заявок: сколько последних записей бизнес готов потерять? Для страницы-визитки и сервиса с заказами ответ может различаться.

Копия возвращает базу к моменту её создания. Если заменить рабочую базу старой копией, появившиеся позже заказы в ней отсутствуют; их сохранение требует отдельного плана.

PostgreSQL описывает восстановление до выбранного момента: исходная копия плюс сохранённый журнал изменений. Это отдельный механизм, который надо настроить и проверить.

Агент может изменить внешний сервис, а след действия останется только в отчёте. Удалённый ящик или данные поставщика не появятся обратно от возврата кода.

Перед удалением нужна выгрузка, которую удалось открыть или восстановить. Перед переключением рабочего сайта нужен отдельный сигнал, даже если настройку можно вернуть.

У нас эти уроки появились после ошибок машины. Их стоит включить в правила для ИИ-агентов; разрешение опасного шага должно быть явным.

Скачанный архив подтверждает, что файл доступен. Для приёмки нужен другой результат: из этой копии получился работающий сайт с ожидаемыми данными.

Проверку проводят отдельно от рабочего сайта. На стенде выключают реальные платежи, рассылки и фоновые задания, чтобы копия не повторила действия над клиентами.

В копии базы могут быть персональные данные. Стенд требует ограниченного доступа и срока удаления; секреты передают защищённо, в публичный git их не кладут.

В задании для ИИ-агента результатом должна быть повторяемая проверка. «Настроить бэкап» без способа приёмки позволяет закончить на создании архива.

Попросите показать восстановленный стенд и передать порядок действий. Повторите проверку после смены базы, хранилища или схемы выкладки: прежний протокол мог перестать работать.

Назначьте ответственного за свежую копию и пробный запуск. Сигнал сбоя должен приводить к исправлению и новому восстановлению; иначе проверка останется разовой.

Для оценки разработки под вашим управлением начните с теста для руководителя.

Настроить копии базы и проверить восстановление можно задачей подписки «Один проект». Код остаётся в вашем репозитории; ночные дежурства в подписку не входят.

1. Примите состав копии: код, базу, загрузки и настройки.

2. Согласуйте допустимую потерю записей и время возврата сайта.

3. Попросите восстановить копию отдельно и пройти путь тестовой заявки.

4. Сохраните протокол и доступы, назначьте ответственного за повторную проверку.