Backup базы данных MVP: dump, расписание и тест восстановления

Бэкап базы данных MVP — это ежедневная копия PostgreSQL, которая лежит отдельно от рабочего сервера и реально восстанавливается. Без неё один упавший диск или неудачная миграция стирают всех пользователей и все оплаты за секунду. Ниже — рабочая схема: pg_dump, расписание через cron или встроенные бэкапы Railway и Supabase, и обязательный тест восстановления.

В статье: разница между pg_dump и pg_dumpall, готовый скрипт для автоматического бэкапа PostgreSQL, сравнение автобэкапов Railway ($20/мес) и Supabase ($25/мес), хранение в Cloudflare R2 и пошаговая проверка восстановления через psql.

Зачем вообще нужен бэкап базы данных на MVP?

Без регулярного бэкапа любая ошибка в миграции, случайный DROP TABLE или сбой диска на хостинге удаляют базу без возможности отката.

MVP редко падает от нагрузки. Он падает от человеческой ошибки: не тот флаг в скрипте, забытый WHERE в SQL-запросе, откат на неправильный коммит. Одна такая ошибка без бэкапа стоит всей базы пользователей и всей истории оплат. Восстановить это без резервной копии невозможно физически, деньги здесь не помогут.

Разработчики продукта на 200 000+ пользователей и 12 млн рублей выручки, GoBanana, знают эту цену на своём опыте: продукт собрали за 6–8 часов, а базу пользователей и платежей, которая накопилась за месяцы, теряют один раз и навсегда, если не настроить бэкап заранее. Дальше разберём, как этого избежать без лишней сложности.

Кстати, паниковать не нужно. Настройка бэкапа PostgreSQL занимает вечер, а работает потом сама, без вашего участия.

Чем pg_dump отличается от pg_dumpall?

pg_dump копирует одну конкретную базу данных. pg_dumpall копирует весь кластер PostgreSQL целиком, включая пользователей и роли доступа, которых в обычном дампе нет.

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

Для MVP на старте хватает связки pg_dump для базы плюс разовый pg_dumpall -g при первом деплое, чтобы зафиксировать пользователей.

Как настроить автоматический бэкап PostgreSQL по расписанию?

Скрипт на bash с pg_dump, cron-задача на ночь и логирование ошибок — три компонента, которые закрывают 90% рисков потери базы MVP.

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

#!/bin/bash
export PGPASSWORD="ваш_пароль"
BACKUP_DIR="/backups"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
pg_dump -h localhost -U postgres -d mvp_db -f "$BACKUP_DIR/backup_$TIMESTAMP.sql" 2>> "$BACKUP_DIR/backup.log"
find "$BACKUP_DIR" -name "*.sql" -mtime +30 -delete

Дайте файлу права на запуск командой chmod 744 backup.sh, а если храните пароль в отдельном файле .pgpass вместо переменной, обязательно поставьте права 600. Без этого PostgreSQL просто откажется читать файл с паролем.

Добавьте в cron строку 0 3 * * * /backups/backup.sh, и скрипт будет отрабатывать каждую ночь в три часа. Файл размером 0 байт в логе почти всегда значит одно: скрипт не достучался до базы, проверьте переменные подключения.

Railway или Supabase — что выбрать для автобэкапов MVP?

Supabase Pro за $25/мес делает ежедневные бэкапы с хранением 7 дней из коробки. У Railway на тарифе Pro за $20/мес автобэкапы Postgres нужно настраивать отдельно, платформа их не включает по умолчанию.

Тут стоит на минуту остановиться, потому что ожидания часто расходятся с реальностью. Supabase встраивает ежедневные бэкапы прямо в Pro-план: 7 дней хранения на Pro, 14 дней на Team. Point-in-Time Recovery — платный отдельный модуль, от $100 в месяц за окно в 7 дней, и на MVP это обычно избыточно.

Railway устроен иначе: Pro-план за $20 в месяц даёт $20 ресурсного кредита на инфраструктуру, но автоматических бэкапов базы «из коробки» на нём нет, это нужно настраивать своим скриптом через cron или внешний сервис.

Если продукт на Supabase, встроенных бэкапов на старте достаточно. Если на Railway или своём VPS, свой скрипт pg_dump обязателен, иначе бэкапов не будет вообще.

Куда складывать бэкапы, если не доверять локальному диску?

Хранить копию базы только на том же сервере, где крутится продакшен, бессмысленно: при поломке диска вы теряете одновременно и базу, и её резервную копию.

Простое решение — заливать дамп в объектное хранилище сразу после создания. Cloudflare R2 стоит 0,015 доллара за гигабайт в месяц и не берёт денег за скачивание данных, в отличие от AWS S3, где egress добавляет отдельную статью расходов, поскольку прямое скачивание из R2 не облагается платой за передачу данных.

Для настройки: создайте бакет, выпустите API-токен с доступом только к этому бакету, добавьте в скрипт загрузку через AWS CLI или rclone после строки с pg_dump. Держите 30 последних версий, остальное можно удалять автоматически.

Базе на 5 ГБ такое хранение обойдётся в копейки даже при хранении месяца версий. Это дешевле, чем один час работы по восстановлению данных вручную из головы.

Как проверить, что бэкап реально восстанавливается?

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

Правило простое и жёсткое: без теста восстановления бэкап не бэкап, а файл на диске, в который вы верите на слово.

Максим: «GoBanana принёс 12 миллионов рублей при том, что весь продукт собрали за 6–8 часов. Базу с этими платежами восстанавливать вручную никто не хочет, поэтому тест восстановления мы гоняем регулярно, а не один раз при настройке.»

Восстановление проверяется одной командой на тестовой базе, не на продакшене:

createdb test_restore
psql test_restore < backup_20260716_030000.sql

Дальше просто зайдите в тестовую базу и посмотрите, на месте ли таблицы, строки и внешние ключи. Если дамп создавался через pg_basebackup для Point-in-Time Recovery, восстановление сложнее: нужен файл recovery.conf с параметром recovery_target_time, и после восстановления база сначала будет в режиме только для чтения.

Что такое Point-in-Time Recovery и нужен ли он MVP?

PITR позволяет откатить базу не на вчерашний бэкап, а на конкретную секунду перед сбоем, но требует архивирования WAL-журналов и обычно избыточен для раннего MVP.

Point-in-Time Recovery работает поверх обычных файловых бэкапов плюс архива Write-Ahead Log — журнала, куда PostgreSQL пишет каждое изменение. Восстановить так можно весь кластер целиком, отдельную таблицу через PITR не вытащить, для этого всё равно нужен pg_dump.

Для MVP с десятками или сотнями пользователей ежедневного pg_dump обычно достаточно: потерять максимум сутки данных не так критично, как оплата в $100 в месяц за 7-дневное окно PITR на Supabase. Возвращаться к этой теме стоит, когда через продукт проходит поток платежей каждый час, а не пара заявок в день.

Итог: какую схему бэкапа ставить на старте

Для MVP без миллионов пользователей рабочая связка выглядит так: pg_dump каждую ночь через cron, загрузка дампа в Cloudflare R2, автоудаление копий старше 30 дней и тест-восстановление раз в месяц на отдельной базе. Если проект уже крутится на Supabase Pro, встроенных ежедневных бэкапов на первое время хватит без доработок.

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

Глоссарий

• pg_dump — утилита PostgreSQL для создания резервной копии одной базы данных в виде SQL-файла.
• pg_dumpall — утилита для бэкапа всего кластера PostgreSQL, включая пользователей и роли.
• WAL (Write-Ahead Log) — журнал, куда PostgreSQL записывает каждое изменение данных до того, как применить его к базе.
• PITR (Point-in-Time Recovery) — восстановление базы данных до конкретного момента времени с точностью до секунды.
• Cron — планировщик задач в Linux, который запускает скрипты по расписанию.
• S3-совместимое хранилище — облачное хранилище файлов с протоколом Amazon S3, к нему относятся Cloudflare R2, DigitalOcean Spaces и сам AWS S3.

Частые вопросы про бэкап базы данных MVP

Как часто нужно делать бэкап базы данных MVP?
Для большинства MVP хватает ежедневного бэкапа через pg_dump ночью. Если через продукт идут платежи, добавьте Point-in-Time Recovery, чтобы терять секунды, а не сутки данных.

Чем pg_dump отличается от pg_dumpall?
pg_dump копирует одну базу. pg_dumpall бэкапит весь кластер вместе с пользователями и ролями, которых в обычном дампе нет.

Нужен ли отдельный сервис для хранения бэкапов?
Да. Хранить копию на том же сервере, где живёт база, рискованно: при поломке диска пропадает и база, и бэкап разом. Cloudflare R2 или другой S3 закрывают это за копейки в месяц.

Что делать, если Railway или Supabase уже обещают автобэкапы?
Встроенный бэкап платформы — это хорошо, но он привязан к вашему аккаунту именно на этой платформе. Держите свою копию отдельно на случай блокировки аккаунта или переезда.

Как проверить, что бэкап рабочий?
Разверните дамп на отдельной тестовой базе через psql или pg_restore и убедитесь, что таблицы и строки на месте. Бэкап, который ни разу не восстанавливали, доверия не заслуживает.

Сколько стоит хранение бэкапов в 2026 году?
Cloudflare R2 берёт 0,015 доллара за гигабайт в месяц и не берёт денег за скачивание. База на 5 ГБ с историей в 30 версий обойдётся в пару долларов.

Что такое Point-in-Time Recovery простыми словами?
Это откат базы не на вчерашний бэкап, а на конкретную секунду перед сбоем. Работает поверх обычных резервных копий и архива WAL-журналов.

Больше практики по инфраструктуре и инструментам для вайбкодинга — в каталоге AI-инструментов VibeCoderz. Если нужна помощь с архитектурой конкретного MVP, запишитесь на консультацию к Максиму.

Источники: документация Supabase по бэкапам, тарифы Railway, цены Cloudflare R2.

Обновлено: июль 2026.