Как сделать резервную копию базы данных приложения (и как её восстановить)

Чтобы сделать резервную копию базы данных приложения, выгружайте её в файл по расписанию (для Postgres стандартный инструмент — pg_dump), храните копии отдельно от самой базы и регулярно разворачивайте одну из них в пустой базе, чтобы убедиться, что она работает. Перед каждым рискованным изменением делайте дополнительную копию. Резервная копия кода, будь то репозиторий GitHub или экспорт, данные не включает.

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

Что должна покрывать резервная копия

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

Данные — это то, что нельзя восстановить. Код можно переписать, настройки можно ввести заново, а заказы клиентов — нет.

Шаг 1: решите, сколько данных можно потерять

Два вопроса определяют ваш план резервного копирования:

• Сколько последних данных можно позволить себе потерять? Если копия делается раз в сутки, а база падает вечером, вы теряете изменения за день. Для хобби-проекта это нормально. Для приложения, которое принимает заказы, может быть недопустимо.
• Сколько приложение может простаивать, пока вы восстанавливаете данные? Маленькая база восстанавливается за минуты. Большая может восстанавливаться гораздо дольше, и это лучше знать заранее, а не в момент аварии.

Для большинства небольших приложений хорошее начало — автоматическая копия раз в сутки плюс ручная перед рискованными изменениями. Приложениям, где задействованы деньги или медицинские данные, нужны более частые копии или управляемая база с point-in-time recovery (возможностью восстановить состояние на любой момент, а не только на последнюю копию).

Шаг 2: проверьте, что уже делает ваш хостинг

Многие провайдеры управляемых баз создают автоматические копии. Выясните:

• Включены ли копии на вашем тарифе и как часто они создаются?
• Как долго они хранятся?
• Можно ли восстановить состояние на конкретный момент или только на ежедневный снимок?
• Можно ли скачать копию или её можно восстановить только внутри системы провайдера?

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

Шаг 3: сделайте дамп с помощью pg_dump

pg_dump выгружает базу Postgres в файл. Он читает согласованный снимок данных, поэтому приложение может продолжать работать, пока он трудится.

Типичная команда, которая использует строку подключения, уже хранящуюся в переменной окружения вашего приложения:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

Что делают опции:

• --format=custom записывает сжатый файл, который может прочитать pg_restore, и позволяет позже восстановить отдельные таблицы. Используйте --format=plain, если нужен читаемый файл .sql.
• --no-owner пропускает команды владельца, что упрощает восстановление в другую базу.
• Дата в имени файла не даёт копиям смешаться друг с другом.

Версия pg_dump должна совпадать с версией Postgres вашей базы или быть новее. Более старый pg_dump может отказаться работать.

Если вы создаёте приложение с помощью ИИ и не хотите работать в командной строке, можно попросить так:

Создай резервную копию базы данных приложения с помощью pg_dump в пользовательском формате, с сегодняшней датой в имени файла. Не выводи строку подключения и никакие секреты. Когда закончишь, сообщи имя файла и его размер.

Шаг 4: автоматизируйте

Ручные копии забывают. Автоматизируйте их тем, что поддерживает ваша система:

• Плановые копии вашего провайдера базы, если он их предлагает.
• Задача по расписанию на сервере или в CI-сервисе, которая запускает pg_dump и загружает файл в хранилище.
• Сервис резервного копирования, который подключается к вашей базе.

Что бы вы ни выбрали, настройте уведомление о сбое. Задача копирования, которая тихо ломается три месяца подряд, — классическая страшная история.

Шаг 5: храните копии в другом месте

Часто применяют правило 3-2-1: три копии данных, на двух разных типах носителей, и одна копия вне площадки. Для небольшого приложения практичный вариант такой:

• Живая база данных
• Автоматические копии вашего провайдера
• Ваши собственные дампы в отдельном хранилище, например в бакете объектного хранилища в другом аккаунте

Также:

• Ограничьте доступ. Копия содержит данные каждого пользователя. Относитесь к ней так же, как к живой базе.
• Продумайте срок хранения. Например, ежедневные копии две недели и ежемесячные — год. Старые копии удаляйте осознанно, помня, что законы о персональных данных могут требовать удалять их по запросу.
• Никогда не коммитьте копии в Git. Дамп в репозитории — это утечка данных, которая только и ждёт своего часа.

Шаг 6: проверьте восстановление

Резервная копия годна ровно настолько, насколько годно ваше последнее успешное восстановление. Проверяйте хотя бы раз в несколько месяцев, а также после любого изменения процесса копирования:

1. Создайте новую пустую базу. Никогда не проверяйте восстановление поверх живой базы.
2. Восстановите в неё последнюю копию:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Для обычного файла .sql используйте вместо этого psql "$TEST_DATABASE_URL" -f backup.sql.

1. Проверьте, что все таблицы на месте, сравните количество строк с живой базой и посмотрите несколько последних записей.
2. Если получится, запустите копию приложения, подключите её к тестовой базе и войдите в неё.
3. Запишите, сколько занимало восстановление. Это и есть ваше реальное время восстановления.

Шаг 7: делайте копию перед рискованными изменениями

Сделайте свежую копию непосредственно перед:

• Миграцией базы, которая удаляет или переименовывает столбцы
• Массовым импортом данных
• Крупными изменениями модели данных, которые вносит ИИ-агент
• Удалением старых записей

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

Частые ошибки

• Считать Git или экспорт кода резервной копией. В них есть код, а не данные.
• Никогда не проверять восстановление. Многие копии оказываются пустыми, неполными или нечитаемыми именно тогда, когда они нужны.
• Хранить копии в том же аккаунте, что и базу. Один взломанный или закрытый аккаунт потеряет обе.
• Забыть про загруженные файлы. База хранит путь к файлу, а сама картинка лежит в хранилище.
• Оставлять секреты в скриптах копирования. Читайте строку подключения из переменной окружения, а не из текста скрипта. См. как хранить API-ключи в безопасности.

Резервные копии и Mythex

В проектах Mythex может быть выделенная база Postgres, а её параметры подключения передаются в рабочее пространство и в опубликованное приложение. В документации Mythex не описана функция резервного копирования или восстановления базы, поэтому планируйте копии сами: попросите агента сделать дамп, скачайте его и храните в надёжном месте, особенно перед крупными изменениями. Экспорт проекта (на тарифе Pro) содержит ваш код; секреты и node_modules в него не входят, и строк базы данных он тоже не содержит. Подробнее — в разделах База данных и Владение данными документации. Чтобы узнать больше о самой базе, прочитайте что такое Postgres.

Чеклист резервного копирования

• Решено, сколько данных можно потерять и сколько времени можно простаивать
• Проверено, какие автоматические копии предоставляет ваш провайдер базы
• Собственный дамп запускается по расписанию, а сбои присылают уведомление
• Копии хранятся отдельно от базы, с ограниченным доступом
• Срок хранения записан
• Загруженные файлы скопированы наравне с базой
• Восстановление проверено в пустой базе, количество строк сверено
• Копия сделана перед каждым рискованным изменением

Вопросы