Разбор · 08.10.2026
Восстановление базы данных начинают на копии: сначала определяют, какие записи удастся вернуть
Как оценить возможность возврата заказов, принять результат и разделить работу агента и клиента после потери данных.
Текст написан инженером, который ведёт vibecoding.ru, вместе с машиной агентов · факты проверены 8 октября 2026
Для руководителя есть тест об агентной разработке.
После удаления заказов восстановление базы данных начинают на отдельной копии: сначала проверяют, какие записи вернутся и чем это подтверждается.
ИИ-агент может написать проверки, но копии и журнал изменений определяют результат. Своего клиентского кейса восстановления базы у нас нет.
Не хотите разбираться сами? Внедряем ИИ в ваш бизнес: задачи без лимита, одна цена в месяц, отмена в любой момент.
1. Исходное состояние сохраняют до попытки восстановления.
После потери заказов ответственный за базу сохраняет материалы инцидента и определяет, какие операции остановить. Эксперименты проводят отдельно.
Исходные файлы и журналы нужны для других попыток. Копию готовят средствами СУБД: произвольная копия файлов работающей базы не доказывает её пригодность.
SQL Server восстанавливают с другим именем и путями файлов. Проверяют оба: новое имя не задаёт отдельное расположение файлов (Microsoft Learn, 08.10.2026).
Исходные материалы нужны до попытки восстановления
Редакционный план начала работ; восстановление отдельно подтверждено документацией Microsoft Learn, проверено 08.10.2026.
Профилактику и проверку бэкапа сайта мы разобрали отдельно. После потери записей задача другая: найти их в сохранившихся материалах и оставить исходное.
2. Копия и журнал определяют, до какого момента можно вернуться.
Что вернёт резервная копия? Состояние, которое в ней сохранилось. Если заказ появился позже, одной этой копии для его возврата недостаточно.
В PostgreSQL возврат к моменту требует физической копии и непрерывного архива WAL. Он хранит изменения после копии; обычный экспорт pg_dump его не заменяет.
SQL Server требует подходящей копии и цепочки журналов. Остановка до удаления зависит от режима восстановления. Имя файла «бэкап» этого не доказывает.
Сохранившиеся материалы задают возможность возврата
PostgreSQL 17 и Microsoft Learn, проверено 08.10.2026. Последняя строка задаёт диагностику, а не обещает возврат.
В SQL Server режим bulk-logged не позволяет остановиться внутри копии журнала с массовыми изменениями. Подрядчик проверяет режим до обещания возврата.
3. Возвращённые заказы проверяют по записям, оплатам и связям.
Запуск базы подтверждает, что СУБД читает данные. Бизнесу нужно подтвердить возвращённые заказы и обязательства. Это отдельная проверка.
GitLab после инцидента 31 января 2017 года вернул сервис, но часть изменений потерял. Разбор от 10.02.2017 перечитали 08.10.2026.
Для ожидаемых заказов сверяют номер, состав и оплату. Одинаковое число строк не доказывает, что вернулись нужные записи.
Протокол отделяет подтверждённые записи от потерь и конфликтов
Наш предлагаемый протокол приёмки. GitLab подтверждает границу «сервис вернулся, часть изменений потеряна», а не эту форму таблицы.
На копии отключают реальные письма, списания и отгрузки до проверок. Возврат записи не должен повторить действие для клиента.
4. Агент готовит проверки на копии, боевые данные контролирует клиент.
Агенту поручают код сверки и отчёт о расхождениях на копии. Инженер задаёт правила и принимает работу; так устроена наша машина агентов.
Клиент определяет место выполнения и допустимые данные. Копия тоже может содержать сведения о людях. Правила для персональных данных и агентов разобраны отдельно.
Общий заказ не заменяет разрешение на разрушительный шаг. Клиент принимает план перед изменением боевой системы. Наши истории показывают эту границу.
Необратимые действия требуют отдельного решения
18.07
Служебный ящик удалили до извлечения истории. После удаления вернуть её не удалось; объём потери не установлен. Урок: получить и проверить нужную выгрузку до удаления. Это почта, не восстановление БД.
09.09
Агент выполнил рабочее переключение без отдельного сигнала; вреда не было. Правило: перед таким шагом нужен отдельный сигнал, разрешение на весь бриф его не заменяет.
Собственные записи машины 18.07 и 09.09.2026, перечитаны 08.10.2026. Закрытые файлы не цитируются; обе истории относятся к границам действий.
Ответственность за ошибки агента не исчезает после зелёной проверки. Документ приёмки показывает, какие записи изменятся и кто разрешил перенос.
5. Перенос согласуют с учётом новых операций.
Между копией и переносом могли появиться новые заказы и оплаты. Перед заменой рабочей базы проверяют, что с ними произойдёт.
Возврат всей базы в прошлое способен убрать новые изменения. Совпавший номер заказа при другом статусе требует решения, а не перезаписи.
Ответственный выбирает способ переноса после диагностики. Цельный возврат и выборочное добавление требуют разных проверок. Сначала выполняют тестовый прогон.
Новые операции учитывают до боевого переноса
Редакционный план приёмки, не универсальная команда для СУБД. Конкретный способ определяют после проверки материалов инцидента.
Неподтверждённые записи остаются в отчёте. Технический перенос не решает спор об оплате. Агент не должен заполнять пропуски догадками.
6. Восстановление заканчивают исправленной причиной и повторяемой проверкой.
У подрядчика сначала заказывают диагностику и перечень достижимого. Цена и срок возврата всех заказов без проверки ничем не подтверждены.
После возврата чинят причину и сохраняют код проверки целостности. Если сбой повторится, проверка должна его обнаружить. Перезапуск приложения этого не доказывает.
Урок «Одиннадцать шагов одной задачи» описывает путь до приёмки. Здесь её итогом становятся отчёт по записям и проверка причины потери.
Приёмка заканчивается проверенными данными и исправленной причиной
Предлагаемый состав работ этой статьи. Это критерии приёмки, а не отчёт о выполненном клиентском восстановлении.
Подписка на агентную разработку «Один проект» стоит 250 000 ₽ в месяц (08.10.2026). Цена месячная; план возврата согласуют после диагностики.
Мы предлагаем согласованный план, код проверки целостности и исправление причины. Боевые данные и разрушительные шаги контролирует клиент.
Ночные дежурства в подписку не входят. Следующий шаг для руководителя: тест для руководителя. Порядок работ обсуждают до передачи доступов.
Что и как мы проверяли
| Факт | Что известно | Проверено |
|---|---|---|
| Условия возврата | Прочитали документы PostgreSQL 17 об архиве WAL и Microsoft Learn о новом месте и моменте восстановления. Они подтверждают условия конкретных механизмов, а не возможность вернуть любую базу. | 2026-10-08 |
| Чужой инцидент | Первичный разбор GitLab от 10.02.2017 об инциденте 31.01.2017: сервис вернули, часть изменений восстановить не смогли. Числа ущерба и срока простоя не используем. | 2026-10-08 |
| Наш опыт | Машина агентов на vibecoding.ru. Перечитали собственные записи 18.07 и 09.09.2026. Это истории границ действий; нашего клиентского кейса восстановления базы нет. | 2026-10-08 |
| Публичные страницы | Сверили роль инженера на /open, название урока в программе курса и тариф «Один проект» на /services: 250 000 ₽ в месяц. Это месячная услуга, а не смета возврата всех заказов. | 2026-10-08 |
| Наш план приёмки | Таблицы сверки записей и переноса являются редакционным предложением. Они не выданы за выполненный проект или дословную инструкцию вендора. Возможность восстановления без материалов конкретной системы неизвестна. | 2026-10-08 |
7. Частые вопросы
Ошибка восстановления означает, что копия испорчена?+
По фразе «не восстановилось» диагноз не ставят. Нужны точный текст ошибки, версия СУБД и сведения о создании копии. Следующую попытку делают отдельно, сохранив исходные материалы.
Что передать подрядчику для первого разговора?+
Описание сбоя, время с часовым поясом, версию базы и список доступных копий и журналов. Пароли, ключи и содержимое боевой базы не нужны в первом сообщении. Доступ и состав данных согласуют отдельно.
Можно ли восстановить заказ по письму клиенту?+
Письмо может подтвердить, что заказ существовал. Его недостаточно для автоматического восстановления оплаты, состава и обязательств. Такие записи помечают неподтверждёнными до сверки с выбранными источниками.
Что делать, если время удаления неизвестно?+
Сначала сопоставить журналы и подтверждения операций. На отдельных экземплярах проверить подходящие состояния и показать различия. Выбранную границу фиксируют в плане, вместе с часовым поясом.
Подписка заменяет аварийного администратора?+
Ночные дежурства в подписку не входят. Действия с рабочей базой контролирует клиент. Подписка даёт план, код проверок и исправления в согласованном проекте; возможность возврата определяет диагностика.
Источники
- PostgreSQL 17, Continuous Archiving and Point-in-Time Recovery · проверено 08.10.2026 — документация
- Microsoft Learn, Restore a Database to a New Location · проверено 08.10.2026 — документация
- Microsoft Learn, Restore a SQL Server Database to a Point in Time · проверено 08.10.2026 — документация
- GitLab, Postmortem of database outage of January 31 · 10.02.2017, проверено 08.10.2026 — первичный разбор
- vibecoding.ru, роль инженера в машине · проверено 08.10.2026 — наш проект
- vibecoding.ru, тариф «Один проект» и границы подписки · проверено 08.10.2026 — наш тариф
- vibecoding.ru, программа курса с уроком «Одиннадцать шагов одной задачи» · проверено 08.10.2026 — наш продукт
Запомнить
1. Сохраните исходные материалы до экспериментов. Возможность возврата проверяют на отдельной копии.
2. Попросите список возвращённых записей, потерь и конфликтов. Запущенная база ещё не подтверждает заказы.
3. Согласуйте перенос с учётом новых операций. Боевые данные и разрушительные шаги контролирует клиент.
4. Примите исправление причины вместе с повторяемой проверкой целостности. Неподтверждённые записи остаются в отчёте.
Следующий шаг для руководителя: пройти тест.