Если нужные записи удалены, не откатывайте рабочую базу целиком автоматически. Обычно безопаснее остановить источник новых удалений, восстановить резервную копию в изолированной среде, извлечь только нужные строки и вернуть их в production контролируемой транзакцией.
До любых действий зафиксируйте время инцидента и часовой пояс, затронутые таблицы и идентификаторы, способ удаления и продолжаются ли записи в эти сущности. Если границы инцидента неясны, сначала остановите опасную операцию и привлеките администратора базы данных.
Почему полный откат может увеличить ущерб
Резервная копия отражает прошлое состояние. Полный откат способен вернуть удалённые строки, но одновременно стереть корректные изменения, появившиеся после создания копии: новые заказы, аккаунты, оплаты, статусы и настройки.
Выборочное восстановление подходит, когда известны затронутые сущности, их ключи и зависимости. При массовом удалении или неясных связях нужен отдельный план восстановления до точки во времени.
Что сделать в первые минуты
- Остановите причину удаления: ошибочную задачу, импорт, скрипт, API-метод или действие в панели. Не выключайте сервер базы вслепую — важно прекратить именно опасные записи.
- Зафиксируйте границы: таблицы, первичные ключи, проект или пользователя, время начала и окончания операции. Не помещайте персональные данные и секреты в рабочие заметки.
- Сохраните журналы приложения, аудит операций, бинарные журналы или WAL, текущую схему и сведения о бэкапах.
- Сделайте свежую копию текущего состояния перед возвратом данных. Она нужна для сравнения и отката самой восстановительной операции.
- Ограничьте обычные изменения затронутых сущностей, если новые записи могут конфликтовать с возвращаемыми строками.
Из каких источников собирать данные
Основной источник — последняя исправная копия, созданная до удаления. Если настроены журналы транзакций и восстановление до точки во времени, на отдельной базе можно приблизиться к моменту непосредственно перед ошибочной операцией.
Аудит приложения и история изменений помогают определить удалённые строки и зависимые операции. Сравнивайте их с production: там могут быть более новые и правильные версии части данных.
Не считайте наличие файла бэкапа доказательством его пригодности. До инцидента полезно проводить пробное восстановление резервной копии и проверять, что база открывается, схема ожидаема, а нужные сущности читаются.
Как подготовить выборочное восстановление
1. Поднимите копию отдельно
Создайте изолированную базу с совместимыми версией СУБД, кодировкой и схемой. Не разворачивайте старую копию поверх production и не подключайте к тестовой среде реальные отправки писем, платежи или другие внешние действия.
Восстановите бэкап, а при наличии журналов транзакций доведите копию до момента перед удалением. Затем убедитесь, что искомые записи действительно существуют и относятся к нужному времени.
2. Определите полный набор зависимостей
Начните с родительских строк и пройдите связи по внешним ключам и логике приложения. Для заказа это могут быть позиции, платежные статусы и история; для пользователя — настройки и связи с проектами.
Одного совпадения по имени или дате недостаточно. Используйте устойчивые идентификаторы и проверьте, не были ли они повторно заняты, объединены или изменены после резервной копии.
3. Сравните старое и текущее состояние
Для каждой строки решите: её нужно вставить, пропустить или объединить вручную. Более новая корректная запись из production обычно не должна заменяться старой версией только потому, что она есть в бэкапе.
Проверьте уникальные ограничения, внешние ключи, обязательные поля, статусы и совместимость со свежей схемой. Если после бэкапа была миграция, старый экспорт может потребовать явного преобразования.
4. Подготовьте повторяемый импорт
Сценарий должен перечислять конкретные таблицы и ключи, работать в транзакции и останавливаться при неожиданном конфликте. Не используйте широкую замену строк или подавление ошибок: они скрывают расхождения и могут перезаписать актуальные данные.
Сначала выполните импорт на копии текущей базы и разберите все конфликты. Не включайте в отчёт пароли, токены, персональные данные или полный дамп.
Как вернуть записи в production
В окно работ убедитесь, что опасная операция остановлена, снимите свежий бэкап и запустите проверенный сценарий в транзакции. Возвращайте родительские записи раньше зависимых.
После записи проверьте не только количество строк, но и бизнес-инварианты: открывается ли сущность в приложении, сохранены ли связи, не появились ли дубликаты, корректны ли статусы. Затем протестируйте критический пользовательский путь и просмотрите ошибки приложения.
Ограничения базы не следует молча отключать ради успешного импорта. Если данные не проходят проверку, безопаснее остановить транзакцию, разобраться с конфликтом и повторить тест на изолированной копии.
Как убедиться, что сервис восстановлен
Проверьте данные через тот же интерфейс или API, которым пользуются сотрудники и клиенты. Убедитесь, что фоновые задачи больше не удаляют и не перезаписывают строки.
Web-Puls можно использовать для регулярной проверки доступности публичной страницы или API после работ. Такой контроль покажет HTTP-сбой или недоступность, но не докажет правильность внутренних данных — для этого нужны прикладные проверки и сверка базы.
Когда выборочного восстановления недостаточно
Готовьте более широкий план, если затронуто много неизвестных таблиц, нет журналов, менялась схема или нельзя определить состояние до удаления. Восстановите отдельную копию до выбранной точки и оцените разницу до любых переносов.
Финансовые и персональные данные переносите только по согласованному защищённому процессу; не отправляйте дампы в формы поддержки.
Что передать специалисту
Подготовьте время и часовой пояс инцидента, версию СУБД, таблицы и обезличенные идентификаторы, время бэкапа, способ удаления и наличие журналов. Добавьте очищенные ошибки, но не пароли, строки подключения и данные клиентов.
Если границы удаления или зависимости неясны, можно отправить заявку на профессиональную поддержку: укажите публичный адрес сайта и кратко опишите инцидент, а безопасный способ передачи технических материалов согласуйте отдельно.