
Бэкап PostgreSQL: pg_dump по cron в S3 (Yandex, Selectel)
Бэкап PostgreSQL через pg_dump по расписанию: выбор формата, .pgpass вместо пароля, скрипт с pipefail, загрузка в Yandex Object Storage и Selectel, ротация.
PostgreSQL
Оставьте pg_dump — он надёжен и знаком. dbsend берёт на себя всё, что вокруг: хранение дампов в российском облаке, версии с метками, сравнение двух дампов, алерты, если ночной бэкап не пришёл, и выдачу нужной версии для восстановления.
Классическая схема выглядит просто: скрипт делает pg_dump, сжимает его и копирует в бакет. На практике к ней быстро добавляются ротация старых файлов, хранение ключей от бакета на сервере, логирование и проверка, что дамп не пустой. Всё это — код, который никто не тестирует.
Самое опасное — тихие сбои. Сменился пароль базы, закончилось место в /tmp, обновился образ Docker без клиента postgresql — и cron годами пишет ошибку в лог, который никто не читает. Узнают об этом в день, когда бэкап понадобился.
И даже рабочие дампы мало что говорят сами по себе. Чтобы понять, в каком из десяти файлов ещё есть удалённые вчера строки, приходится разворачивать их по очереди во временную базу.
Каждый загруженный дамп — версия vN с меткой, размером и SHA-256. CLI сжимает файл потоково и загружает большие дампы частями с повторами при сбоях сети.
Для дампов в формате --format=plain dbsend разбирает CREATE/ALTER, COPY и INSERT: видно список таблиц, число строк и хэш схемы (тарифы от «Старт»).
Сравните вчерашний и сегодняшний дамп: в каких таблицах изменилось число строк, поменялась ли схема. Помогает найти момент, когда данные пропали. Доступно на тарифах от «Старт».
Задайте ожидаемый интервал — например, раз в сутки. Если дамп не пришёл, придёт уведомление в Telegram или на email.
Создайте в панели базу с типом postgresql_dump и API-ключ. Сервер с PostgreSQL ключ от S3 не получает — только API-ключ dbsend, который можно ограничить одной базой.
#!/usr/bin/env bash
# /usr/local/bin/pg-backup.sh
set -euo pipefail
DUMP=/var/backups/app.sql
pg_dump --format=plain --no-owner "$DATABASE_URL" > "$DUMP"
dbsend backup "$DUMP" -d <id базы> -e postgresql_dump -l "nightly-$(date +%F)"
rm -f "$DUMP"Используйте --format=plain: custom, tar и directory-форматы тоже можно хранить, но без инспекции и diff по таблицам.
# crontab -e — каждый день в 03:15
15 3 * * * DATABASE_URL=postgres://backup@localhost/app /usr/local/bin/pg-backup.sh >> /var/log/pg-backup.log 2>&1Ключ dbsend сохраняется один раз командой dbsend login для пользователя, от имени которого работает cron. Ненулевой код выхода (3 — ключ, 4 — лимит тарифа, 5 — сеть) удобно ловить в мониторинге.
docker exec -t postgres pg_dump -U app --format=plain app > /var/backups/app.sql
dbsend backup /var/backups/app.sql -d <id базы> -e postgresql_dumpdbsend log <id базы>
dbsend restore <id версии> ./restore.sql --yes
psql "$DATABASE_URL_STAGING" -f ./restore.sqlВосстанавливайте сначала в отдельную базу, проверяйте данные и только потом переключайте приложение.
Логический бэкап через pg_dump подходит для баз до десятков гигабайт, где допустимо потерять изменения с момента последнего дампа: SaaS на старте, внутренние сервисы, CMS, базы ботов и pet-проектов. Он переносим между версиями PostgreSQL и восстанавливается одной командой psql.
Если вам нужна точка восстановления с точностью до секунды или база весит сотни гигабайт, используйте физические бэкапы и архив WAL (pgBackRest, WAL-G) или управляемую базу в облаке. dbsend при этом можно оставить как второй, независимый слой — ежедневные логические дампы вне основной инфраструктуры.
| pg_dump + cron + S3 | dbsend | |
|---|---|---|
| Ключи от бакета на сервере базы | нужны | не нужны — только API-ключ |
| Таблицы и число строк в каждом дампе | от «Старт» | |
| Время на настройку | скрипт, бакет, ключи, ротация — часы | 3 команды — несколько минут |
| История версий с метками | имена файлов по дате | v1…vN, метки, закрепление |
| Не плодит одинаковые копии | ||
| Diff между версиями (таблицы, строки, схема) | на платных тарифах | |
| Проверка SHA-256 при восстановлении | если написали сами | |
| Алерт, если бэкап не пришёл | Telegram и email | |
| Шифрование и хранение в РФ | зависит от бакета | AES-256-GCM, РФ |
| Доступ из Claude Code и Cursor (MCP) | ||
| Стоимость | хранилище + ваше время | от 0 ₽ |
Тарифы и лимиты — на странице «Тарифы». Документация: CLI, форматы файлов, REST API.
Для инспекции и diff нужен plain SQL (--format=plain). Дампы в форматах custom, tar и directory можно загрузить как generic-файл: они хранятся версиями с контрольной суммой, но без разбора таблиц.
Да, если у вас есть сетевой доступ к базе и права на pg_dump. Запускайте скрипт на любом сервере или в CI, откуда база доступна, — dbsend нужен только исходящий HTTPS до api.dbsend.ru.
Скачайте версию командой dbsend restore <id> ./restore.sql --yes — CLI проверит SHA-256. Затем примените дамп штатным psql -f restore.sql к пустой базе. Для custom-формата используйте pg_restore.
Зависит от тарифа: 3 версии на бесплатном, 30 на «Старт», 90 на «Про» и 365 на «Команде». Старые версии удаляются автоматически, закреплённые командой dbsend pin — сохраняются.
До 100 МБ на бесплатном тарифе, 500 МБ на «Старт» и 2 ГБ на «Про» и «Команде» — это размер одного файла. Дампы больше 32 МБ CLI загружает частями автоматически.

Бэкап PostgreSQL через pg_dump по расписанию: выбор формата, .pgpass вместо пароля, скрипт с pipefail, загрузка в Yandex Object Storage и Selectel, ротация.

Как восстановить базу из бэкапа без потерь: psql и pg_restore, mysql, замена файла SQLite и DuckDB, одна таблица из дампа, чек-лист до, во время и после.

Бэкап базы в Docker и Coolify: почему нельзя копировать живой volume, docker exec без -t, дампы PostgreSQL, MySQL и SQLite, sidecar, бэкапы Coolify в S3.

Как проверить, что бэкап базы рабочий: sha256sum, gzip -t, integrity_check, тестовое восстановление в Docker, еженедельный тест в cron и контроль пропусков.
Другие сценарии
Бесплатный тариф: 1 база, 500 МБ и 3 версии навсегда. Подключение — одна строка в cron.
Начать бесплатно →