Как восстановить данные, которые массово удалили в CRM

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

В большинстве случаев данные никуда не делись.

#Удалено или только помечено удалённым

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

Soft delete — строка остаётся в базе, ей просто проставляют пометку. Так работают многие CRM: это дешевле и безопаснее. Проверить просто: сделайте запрос по идентификатору объекта через API. Если приходит 200 и данные на месте — это soft delete, и восстановление сводится к снятию пометки или повторному созданию связи.

Hard delete — строки нет. Тогда источником остаётся резервная копия или экспорт, сделанный до инцидента.

#Откуда взять перечень того, что восстанавливать

Нужен список пар «что с чем было связано» до инцидента. Источники по убыванию надёжности:

• резервная копия базы — если она есть и сделана до события;
• экспорт из админки — многие системы дают выгрузить связи таблицей;
• логи самой операции — если тот, кто удалял, сохранил результат прогона;
• сторонние системы — если те же данные дублируются в другом сервисе.

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

#Почему сухой прогон обязателен

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

node restore.js                 # ничего не шлёт, печатает первые 10 запросов
node restore.js --live          # только после того, как проверили глазами

На сухом прогоне проверяют три вещи: правильные идентификаторы, правильный метод и правильное количество. Если скрипт собирается сделать тридцать тысяч запросов, а удалили три тысячи связей — что-то не так с перечнем, и лучше увидеть это сейчас.

#Зачем писать каждый запрос в лог

Это главная часть, и делают её до запуска, а не после.

Каждый выполненный запрос записывают отдельной строкой: метод, адрес, тело, код ответа, время. Формат — по одной записи JSON на строку, чтобы файл можно было читать частями и не держать в памяти.

Этот лог даёт три вещи:

• доказательство. Видно, что именно сделано, а не «кажется, восстановили»;
• восстановление после сбоя. Связь оборвалась на полпути — повторный запуск берёт только то, чего нет в лог-файле;
• отмена. Тот же файл, прогнанный обратным методом, возвращает всё как было.

node restore.js --live --method=DELETE --from-log=logs/2026-08-13.jsonl

Это и есть кнопка «отменить», которой нет в интерфейсе. Её нужно сделать самому, и сделать до живого запуска.

#Что проверить перед живым запуском

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

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

#Что сделать после восстановления

Инцидент стоит закрывать не восстановлением, а устранением причины.

В некоторых CRM массовые операции открыты всем, у кого есть доступ к сегментам. Минимум, который имеет смысл: ограничить круг тех, кто может их запускать, и завести правило — перед массовым действием сохранять экспорт этого сегмента. Это тридцать секунд, которые в следующий раз сведут восстановление к одному импорту.

#Выводы

• Сначала остановите то, что удаляет, и только потом восстанавливайте.
• Проверьте, не soft delete ли это: часто данные ещё на месте.
• Перечень для восстановления собирайте сразу — помеченные записи могут убрать окончательно.
• Скрипт по умолчанию не пишет ничего; живой запуск — отдельным флагом.
• Каждый запрос — в лог. Тот же лог — доказательство, продолжение после сбоя и откат.
• Перед массовым прогоном проверьте на одной записи.

#Частые вопросы

#Сколько времени есть на восстановление?

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

#Можно ли восстановить, если резервной копии нет?

Часто да — если это soft delete или если те же связи есть в другой системе. Если это hard delete и дублирования нигде нет, восстанавливать не из чего.

#Кто должен это делать — ваша команда или поддержка сервиса?

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