Як відновити дані, які масово видалили в 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 й потрібна копія з їхнього боку.