ИИ удалил базу данных: бэкапы и миграции без страха
Летом 2025 года ИИ-ассистент стёр рабочую базу прямо во время заморозки изменений, а потом сочинил тысячи несуществующих пользователей, чтобы это скрыть. У того проекта не было бэкапа. Страх потерять всё, что пишет нейросеть, не выдуманный. Этот материал разбирает, как защититься: какие бэкапы делать и как часто, почему медиа держат отдельно, и почему миграция падает только на проде. С чек-листом и промтом для проверки вашего проекта.
Летом 2025 года один предприниматель запускал продукт с помощью ИИ-ассистента. На девятый день он прямым текстом попросил ничего не менять, заморозка. Ассистент всё равно полез в продакшн и удалил рабочую базу. Дальше началось интересное. Чтобы экран выглядел нормально, нейросеть сочинила несколько тысяч несуществующих пользователей и нарисовала зелёные отчёты по тестам, которых не было. То есть сначала сломала, потом соврала и спрятала следы.
Бэкапа у проекта не было. А когда хозяин спросил, можно ли откатиться, ассистент заявил, что данные уничтожены безвозвратно. Это тоже оказалось неправдой, откат в итоге сработал, но человек об этом узнал не сразу.
Я рассказываю эту историю первой, когда у меня спрашивают про страх потерять проект. Почти каждый, кто начал собирать продукты с нейросетью, рано или поздно ловит этот холодок: «а что если оно сейчас сотрёт мне всё». Холодок правильный. Я сам пишу код каждый день и каждый день немного боюсь что-то сломать. Разница в том, что у меня этот страх есть, а у нейросети его нет совсем.
Этот материал про то, как спать спокойно. Без магии, на понятном языке: что такое бэкап, какие они бывают, как часто их делать, куда девать тяжёлые файлы и почему миграция базы данных ломается ровно в тот момент, когда вы выкатили её на живых клиентов. В конце дам чек-лист и промт, который скормите своему ассистенту, чтобы он проверил именно ваш проект.
Если совсем коротко. Код живёт в GitHub, это его бэкап, откатить сломанный код оттуда быстрее всего. Данные базы бэкапьте отдельно и часто: от раза в неделю для статики до раза в несколько часов для живого проекта. Тяжёлое медиа держите в S3, а не в общем бэкапе, иначе архив раздуется до сотни гигабайт. Перед любой миграцией или удалением чего-либо на проде снимайте свежий бэкап и читайте глазами команду, которую собралась выполнить нейросеть. И помните, что у неё нет страха сломать, поэтому страховку встраиваем в процесс. Просьба «будь аккуратнее» тут не работает.
Тот случай с заморозкой не единичный, и дело не в одной «плохой» нейросети. За один только 2025 год похожих историй набралось на отдельную полку.
Ассистент Gemini в командной строке потерял файлы пользователя на ровном месте. Он попытался создать папку, команда тихо провалилась, но ассистент этого не заметил и продолжил перекладывать файлы в папку, которой не существует. Файлы исчезли. В конце он написал что-то вроде «я полностью вас подвёл».
Claude Code, которым я сам каждый день работаю, дважды за осень и зиму выполнял команду полного удаления каталога и сносил людям рабочие папки. Вывод из этих случаев не «Claude плохой». Вывод инженерный: нельзя давать ассистенту полную власть над живой машиной без песочницы и без бэкапа. Я и сам после этих историй стал жёстче с правами.
А весной 2026 ИИ-агент в редакторе кода одним запросом к облаку снёс продакшн-базу компании вместе со всеми бэкапами. Бэкапы лежали на том же диске, что и база, поэтому исчезли вместе с ней. Всё заняло девять секунд. Основатель потом написал, что агент «угадал», будто удаляет тестовый том, а удалил боевой. Здесь важна не скорость, а урок: бэкап рядом с данными это не бэкап.
Складывается один и тот же сценарий. Нейросеть охотно выполняет разрушительную команду, а потом отчитывается, что всё прошло успешно, хотя шаг на деле провалился. Замечает неладное и пытается починить своей же новой командой, копая яму глубже. А когда становится совсем плохо, прячет проблему за красивым отчётом. На каждом из этих шагов спасает ровно одно: свежий бэкап, который лежит отдельно от того, что он бэкапит, и из которого можно откатиться.
Что нейросеть реально может сломать
Стереть базу данных
Самое болезненное. Удаляет таблицу или всю базу, выполняя команду, которую вы попросили «немного поправить». Все клиенты, заказы, история исчезают за секунду.
Сломать запуск проекта
Меняет файлы так, что проект перестаёт собираться и подниматься. Сайт лежит, а вы не понимаете, какая из двадцати правок его уронила.
Удалить или подменить ключи
Затирает или переписывает ключи доступа и переменные окружения. Платежи, почта, внешние сервисы отваливаются молча, без явной ошибки.
Внести необратимые правки на сервере
Меняет конфигурацию живой машины. Откатить через историю кода такое нельзя, потому что в код это не попадает. Спасает только бэкап сервера.
Почему у нейросети нет тормозов, которые есть у человека.
Раньше в этой цепочке были только люди. Человек боится. Прежде чем удалить таблицу на проде, у живого разработчика потеют ладони, он трижды перечитывает команду, делает копию на всякий случай. Этот страх неприятный, но он защищает. У нейросети его нет. Она ограничена только теми инструкциями, которые вы ей дали.
И вот тут ловушка. Если вы сформулировали задачу так, что её можно понять двояко, считайте, что её поймут не так, как вы хотели. Нейросеть не уточнит лишний раз, не остановится на пороге. Она исходит из того, что она права и делает правильно. Ломает она без злого умысла, искренне считая, что поступает верно.
Отсюда вывод. Спорить с нейросетью про аккуратность бесполезно, у неё нет органа, которым боятся. Поэтому страховку выносим наружу, в процесс. Бэкап, отдельная база для экспериментов, права только на чтение там, где не нужна запись. Бесполезно просить ассистента быть осторожнее. Лучше сделать так, чтобы его неосторожность ничего не стоила.
Теперь по делу. Что такое бэкап, если без терминов.
Бэкап это полная копия, сложенная в архив. Представьте, что вы заморозили состояние своего сервера в одной точке времени и упаковали в один файл. Когда что-то ломается, вы берёте этот архив, распаковываете (не руками, конечно, автоматически) и возвращаете либо отдельные потерянные файлы, либо всё целиком, вплоть до операционной системы.
Полный бэкап сервера это снимок всего разом. Ваш продакшн, база данных, все проектики, которые крутятся на машине, медиафайлы, настройки. Всё, что потом можно поднять обратно, если сервер сгорит дотла.
Но снимать всё целиком каждый час не получится, и сейчас вы поймёте почему. Поэтому на практике бэкапы делят на части и снимают их с разной частотой. Дальше разберём эти части по отдельности.
Три вида бэкапа, которые держим раздельно
Бэкап базы данных
Снимок ваших данных: клиенты, заказы, сообщения, контент. Меняется чаще всего, поэтому и снимаем чаще всего. Это ваш главный бэкап.
Бэкап проекта это GitHub
Код проекта живёт в репозитории. По сути это и есть его бэкап. Что-то сломалось, откатили на рабочий коммит, выкатили заново, и проект снова дышит.
Полный бэкап сервера
Снимок всей машины целиком на случай, когда сервер ложится полностью. Самый тяжёлый и редкий, но без него при настоящей аварии поднять всё обратно нечем.
Откатить из GitHub или поднимать из полного бэкапа
Когда подходит
Сломан код: проект не собирается, поехала логика, кривая правка
Потеряны данные или лёг весь сервер целиком
Сколько занимает
Минуты: откатил коммит, выкатил заново
От десятков минут до часов: распаковка и накат
Что вернёт
Только код на момент рабочего коммита
Данные, файлы, при полном бэкапе всю машину
Чего не вернёт
Данные в базе и загруженные файлы (их в коде нет)
То, что появилось после момента снятия бэкапа
Первый выбор
Если сломан только код, всегда начинайте отсюда
Когда откат кода не помогает или пропали данные
Здесь у бэкапа проекта есть тихая ловушка, в которую попадают почти все. Код в GitHub откатывается легко, но как только у вас появляются медиафайлы, всё усложняется.
Дело в размере. GitHub не любит тяжёлое: у одного файла там потолок около ста мегабайт, и сам репозиторий стоит держать компактным. Для кода это огромный запас. В один репозиторий спокойно влезает мобильное приложение, телеграм-бот, мини-приложение, сайт, целая база документации, и место ещё останется. Код почти ничего не весит. Вы при всём желании не напишете руками код, который потянет на гигабайт.
А вот видео в хорошем качестве легко весит несколько гигабайт. Одно. Если медиа лежит на сервере и попадает в общий бэкап, размер бэкапа взлетает. У меня были случаи, когда настроенный бэкап весил под сто гигабайт. Такое не то что неудобно снимать, такое даже хранить тяжело.
Лечится это легко. Храним файлы в двух местах и в бэкап их не суём.
Медиа кладём в отдельное файловое хранилище, в S3 или подобное, можно ещё и продублировать. На сервере при этом остаётся либо сам файл, либо просто ссылка на него. А в бэкап отправляем только то, что действительно важно и невелико: данные и код. Медиа из бэкапа исключаем сознательно. Это большие пулы данных, которые чаще всего можно вообще не бэкапить.
Звучит рискованно, но посмотрите на любой мессенджер. Пролистайте старый чат на пару лет назад. Часть медиа там уже не открывается, осталась только подпись «срок хранения истёк». У всего есть свой срок жизни, и это нормально. Старое медиа можно частично удалять и не тащить за собой годами. Важное лежит в S3 в двух копиях, а раздувать им бэкап базы смысла нет.
Я и в своих проектах так делаю. Файлы уходят в S3, в базе остаётся только ссылка, бэкап базы лёгкий и снимается часто. Если завтра сервер сгорит, я подниму данные за минуты, а медиа спокойно лежит отдельно и никуда не делось.
Правило, которое экономит и нервы, и деньги на хранении. Медиафайлы (фото, видео, вложения, аватары) держите в отдельном файловом хранилище вроде S3, а в базе храните только ссылку на файл. Тогда бэкап базы остаётся лёгким и его можно снимать хоть каждые несколько часов. Тяжёлое медиа при этом лежит в своём хранилище, по желанию в двух копиях, и в общий бэкап не попадает. Смешивать тяжёлое медиа с базой в одном бэкапе это прямой путь к архивам на сотню гигабайт, которые невозможно ни быстро снять, ни удобно хранить.
Как часто снимать бэкап базы. Зависит от того, насколько живой ваш проект, то есть как много нового появляется в базе за сутки.
Если у вас статика, сайт-визитка, лендинг, что-то почти не меняющееся, хватит раза в неделю. Если проект чуть живее, обновляется время от времени, делайте раз в три дня. Обычный рабочий сайт, где каждый день что-то происходит, заявки, регистрации, правки, бэкапим раз в сутки, удобно ночью, когда нагрузка низкая.
А если проект кипит, постоянно идут посты, генерации, переписки с клиентами, ответы, какая-то непрерывная движуха, то раз в сутки уже мало. Такое бэкапим раз в несколько часов. Работает это так. Бэкап откатывает вас к моменту последнего снимка, и всё, что появилось после, теряется. Чем дороже вам данные за последние часы, тем чаще снимок.
Как часто бэкапить базу
Статика: визитка, лендинг
Данные почти не меняются
Раз в неделю
Слабо живой проект
Обновляется время от времени
Раз в три дня
Обычный рабочий сайт
Каждый день заявки, правки, регистрации
Раз в сутки, удобно ночью
Кипящий проект
Посты, генерации, переписки, ответы клиентам без остановки
Раз в несколько часов
Отдельная история, когда база разрастается до огромных размеров. Снимать целиком гигантскую базу каждые несколько часов нерационально, бэкап получается тяжёлым, а большая его часть это старые данные, которые давно не меняются.
Тут помогает разделение. Самое тяжёлое и быстрорастущее, например историю сообщений, выносим в отдельную базу. Допустим, в ней накопился миллион сообщений. В какой-то момент мы её закрываем на чтение, новые сообщения с этого дня пишем уже в другую, свежую базу. Старую снимаем в бэкап один раз, когда она заполнена и больше не меняется, и просто храним этот единственный архив. Копировать её снова и снова смысла нет, она застыла.
А вот свежую базу, в которую теперь падает вся новая движуха, бэкапим часто, как договорились выше. Получается, тяжёлое и неизменное лежит снятым один раз, а лёгкое и горячее снимается регулярно. И размер каждого бэкапа остаётся вменяемым.
Вторая половина страха это миграции. Слово звучит угрожающе, а на деле миграция это просто изменение структуры базы. Добавить колонку, переименовать поле, поменять тип. Проблема в том, что миграция обожает падать ровно в одном месте: на проде, на живых данных, когда уже поздно.
Причина почти всегда одна. У вас на компьютере база пустая или почти пустая, и миграция на ней проходит мгновенно и гладко. Вы видите зелёную галочку и спокойно катите на прод. А на проде в той же таблице лежат сотни тысяч строк реальных данных, и та же самая команда ведёт себя совсем иначе.
Три классические ловушки, на которых обжигаются чаще всего.
Первая. Вы делаете колонку обязательной, ставите запрет на пустое значение. На локальной базе строк нет, запрет встаёт мгновенно. На проде в этой колонке у части старых строк значение пустое, и миграция либо падает с ошибкой, либо надолго блокирует таблицу, пока проверяет каждую строку. На время блокировки сайт фактически висит.
Вторая. Вы меняете тип колонки, например текст на число. База в общем случае вынуждена переписать всю таблицу целиком, строка за строкой, и всё это время держит её заблокированной. На пустой таблице это миг. На таблице в миллион строк это минуты простоя.
Третья. Удаление или переименование колонки, на которую ещё ссылается работающий код. Старая версия кода обращается к полю, которого уже нет, и сыпет ошибками, пока не доехал новый деплой. Между «накатили миграцию» и «выкатили новый код» всегда есть зазор, и в этот зазор проект ломается.
Снимите свежий бэкап базы и прочитайте глазами команду, которую собралась выполнить нейросеть. Не «накати миграцию», а «покажи команду, я посмотрю». Это последний рубеж: почти все потери данных из живых историй ловятся именно на этом шаге. Минута проверки против часов восстановления.
Безопасный способ называется «сначала добавь, потом убери». Идея в том, чтобы старая и новая версия какое-то время жили вместе, и ни в один момент ничего не ломалось.
Меняете поле в три захода, без одного резкого движения. Сначала добавляете новое поле рядом со старым, ничего не трогая. Старый код продолжает работать как работал. Потом учите код писать и в старое поле, и в новое, и спокойно переносите данные в фоне. И только когда весь код перешёл на новое поле и старое больше никем не используется, удаляете старое. На каждом шаге система целая, откатиться можно в любой момент.
И два правила поверх этого. Первое: перед любой миграцией на проде снимите свежий бэкап базы. Минута времени против потерянных данных, выбор очевиден. Второе: всегда читайте глазами, что именно нейросеть собралась выполнить. Не «накати миграцию», а «покажи мне команду, которую ты хочешь выполнить, я посмотрю». Большинство катастроф из начала этого материала ловятся ровно на этом шаге.
Пройдитесь по своему проекту прямо сейчас, не дожидаясь аварии. Семь пунктов, которые в день аварии отделяют уверенность от паники. 1. У вас вообще есть бэкап базы? Не «облако само что-то хранит», а конкретный архив, который вы видели. На бесплатных тарифах баз автобэкапов часто нет совсем, только ручная выгрузка. Проверьте сегодня. 2. Вы хоть раз восстанавливались из своего бэкапа? Бэкап, который ни разу не разворачивали, это не бэкап, а надежда. Проверьте, что он рабочий. 3. Бэкапы снимаются автоматически по расписанию? Ручной бэкап «когда вспомню» не работает. Частота под динамику проекта: от недели до нескольких часов. 4. Код лежит в GitHub и оттуда поднимается? Если да, сломанный код вы откатите за минуты, не трогая тяжёлые бэкапы. 5. Тяжёлое медиа вынесено в отдельное хранилище? Если видео и картинки лежат вперемешку с базой, бэкап скоро станет неподъёмным. 6. У нейросети есть отдельная песочница, а не доступ к проду? Эксперименты на копии, на проде только проверенное. Где можно, дайте доступ только на чтение. 7. Перед миграцией снимается свежий бэкап и читается команда? Это последний рубеж перед потерей данных. Не пропускайте его никогда.
А это самое практичное. Готовый промт, который отдадите своему ИИ-ассистенту вместе с описанием проекта. Он проверит вашу устойчивость к потере данных и предложит, что починить в первую очередь. Важно: промт просит ассистента только анализировать и советовать, ничего не удаляя и не меняя. Сначала опишите проект, потом вставьте промт ниже.
Ты опытный инженер по надёжности. Проверь мой проект на устойчивость к потере данных и помоги настроить защиту. Не выполняй никаких разрушительных команд, только анализируй и предлагай. Сначала задай мне вопросы, без ответов на которые проверка будет неполной: где хостится база, на каком тарифе, есть ли уже бэкапы и какие, где лежат медиафайлы, как часто меняются данные, как у тебя (ассистента) настроен доступ к проду. Дальше дай разбор по пунктам: 1. Бэкап базы. Есть ли он, автоматический ли, как часто снимается. Если нет или редко, предложи частоту под динамику моего проекта и конкретный способ настроить автобэкап для моего хостинга. 2. Проверка восстановления. Опиши по шагам, как мне безопасно проверить, что из бэкапа реально можно восстановиться, не трогая прод. 3. Медиафайлы. Лежат ли они отдельно от базы. Если нет, предложи, как вынести их в отдельное хранилище и оставить в базе только ссылки. 4. Код и откат. Лежит ли проект в системе контроля версий, можно ли быстро откатиться на рабочую версию. 5. Доступ ассистента. Оцени, насколько рискованно настроен мой доступ к проду. Предложи, где включить права только на чтение и как отделить песочницу от боевой среды. 6. Миграции. Объясни, как мне безопасно вносить изменения в структуру базы, чтобы не уронить прод на живых данных. В конце дай список из трёх самых срочных действий, отсортированный по риску: что починить прямо сегодня, что на этой неделе, что в течение месяца. ОПИСАНИЕ МОЕГО ПРОЕКТА: [ОПИШИ ЗДЕСЬ: что за проект, где хостится база, есть ли бэкапы, где медиа]
Частые вопросы
Настроим бэкапы и безопасные миграции под ваш проект
За консультацию разбираем вашу инфраструктуру: где и как часто снимать бэкапы, как вынести медиа, как закрыть прод от случайной команды ассистента и как менять структуру базы без простоя. На выходе понятный план, что настроить и в каком порядке.
Обсудить проектЕсли по какому-то пункту чек-листа ответ «нет» или «не уверен», это нормальное место, чтобы остановиться и спросить. Напишите, разберём ваш случай. Отвечаю всем по мере возможности.