Как зарезервировать Docker-контейнер PostgreSQL (2026)
PostgreSQL требует согласованного дампа до того, как в дело вступит restic. Dockstash выполняет `pg_dumpall -U "$POSTGRES_USER"` внутри контейнера, забирает вывод и хранит его зашифрованным вовне — он никогда не копирует /var/lib/postgresql/data вживую, потому что pg_dumpall читает согласованный MVCC-снимок: каждая база захватывается в один момент времени без блокировки писателей.
Что находит Dockstash
| Найденные переменные окружения | POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB |
|---|---|
| Порт по умолчанию | 5432 |
| Живые пути данных (никогда не копируются вживую) | /var/lib/postgresql/data |
| Примеры образов | postgres:16-alpine, postgres:16, postgres:15, postgres |
Резервируем PostgreSQL с Dockstash, шаг за шагом
Создайте аккаунт Dockstash и откройте панель
Зарегистрируйтесь бесплатно на app.dockstash.com/register. Одноразовый мастер настройки спросит ваш VPS для хранения (машину, где будут лежать зашифрованные резервные копии) и сгенерирует пароль шифрования — сразу сохраните его в менеджере паролей: он показывается ровно один раз.
Добавьте Docker-проект, в котором работает PostgreSQL
На экране Projects Dockstash автоматически находит каждую папку Compose-проекта на сервере (по умолчанию под /var/www). Выберите проект с вашим сервисом PostgreSQL. Пока ничего не резервируется — вы лишь указываете Dockstash, где живёт проект.
Проверьте, что PostgreSQL распознан
Откройте проект и загляните во вкладку Plan. Dockstash читает docker-compose.yml, распознаёт образ postgres и добавляет слой базы данных с правильной командой дампа — плюс разрешённое имя контейнера и найденные переменные окружения (POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB). Файлы, базы и конфиги прокси можно включать и выключать перед сохранением.
Опционально: проверьте дамп вручную
Если хотите доказательство до автоматизации, выполните тот же дамп, что выполнит Dockstash. Вы увидите поток SQL-инструкций — именно этот вывод и резервируется, никогда не живой каталог данных.
docker exec <postgres-container> sh -c 'pg_dumpall -U "$POSTGRES_USER"' | head -n 20Подтвердите место хранения
Резервные копии хранятся как зашифрованные снимки restic на вашем собственном VPS для хранения, по SSH. Если вы прошли мастер настройки, всё уже настроено; хост, пользователя, порт или SSH-ключ можно изменить в любой момент в Settings → Storage.
Настройте расписание резервного копирования
Во вкладке Schedule проекта выберите ежедневно, еженедельно или собственное cron-выражение (валидируется при вводе). Ежедневно в тихий час — правильное умолчание для большинства проектов PostgreSQL. Добавьте еженедельный prune с вашей политикой хранения, чтобы старые снимки обрезались автоматически.
Запустите первую копию сейчас
Нажмите Backup Now на карточке проекта. Dockstash выполнит pg_dumpall внутри работающего контейнера и отправит дамп прямо в restic — живой вывод restic можно смотреть построчно в панели логов.
Убедитесь, что снимок существует
По завершении запуска карточка проекта показывает новое время последней копии, число снимков и размер репозитория. Откройте экран Snapshots: точка восстановления появится на таймлайне — это ваше доказательство, что копия дошла до внешнего хранилища.
Команда дампа
pg_dumpall -U "$POSTGRES_USER"Команда восстановления
psql -U "$POSTGRES_USER"pg_dumpall читает согласованный MVCC-снимок: каждая база захватывается в один момент времени без блокировки писателей.
Восстановите копию PostgreSQL и докажите, что она работает
Резервная копия PostgreSQL становится настоящей только после восстановления. Восстановления Dockstash по умолчанию никогда не перезаписывают живую базу — сначала вы восстанавливаете в новое место, проверяете данные и продвигаете осознанно.
Выберите точку восстановления
Откройте Snapshots, выберите проект и просмотрите таймлайн точек восстановления. Каждая строка — полный согласованный дамп всех баз кластера плюс файлы проекта, снятые в том же запуске.
Восстановите в новое место
Нажмите Restore и оставьте режим по умолчанию «Restore to new location». Введите имя проекта для подтверждения — осознанное действие с набором текста. Дамп и файлы попадут в выбранный целевой путь, не трогая живой проект.
Проверьте восстановленные данные
Загрузите восстановленный дамп в тестовый контейнер PostgreSQL через psql, перечислите базы и выборочно проверьте таблицы, от которых зависит приложение. Счётчики строк и свежие записи — самый быстрый тест на правду.
docker exec <postgres-container> sh -c 'psql -U "$POSTGRES_USER" -c "\l"'Продвигайте, когда всё проверено
Когда восстановленные данные проверены, переключите на них приложение (или повторите восстановление в режиме «Overwrite existing» — явный опт-ин). Ещё лучше: пусть еженедельная тренировка восстановления делает это доказательство автоматически, чтобы восстановление никогда не было вашей первой репетицией.
Каких ловушек избегать
- Никогда не запускайте restic по живому каталогу /var/lib/postgresql/data — страница кучи, скопированная посреди записи, порвана и невосстановима.
- pg_dumpall захватывает роли и все базы; одиночный pg_dump теряет глобальные объекты вроде ролей и табличных пространств.
- Расширения (PostGIS, pgvector) должны быть установлены в целевом образе до восстановления, иначе SQL упадёт.
Типичные проблемы резервирования PostgreSQL
- Симптом
- Дамп падает с «role does not exist» или ошибками аутентификации.
- Причина
- Значение POSTGRES_USER в compose больше не соответствует реальной роли в базе — обычное дело после ручного переименования роли или тома, восстановленного из другого проекта.
- Решение
- Запустите psql в контейнере, проверьте реальные роли через \du и приведите env compose (или учётные данные дампа в плане) к существующей роли суперпользователя.
- Симптом
- Восстановленный SQL падает с «extension ... is not available».
- Причина
- Дамп ссылается на CREATE EXTENSION (PostGIS, pgvector, …), но целевой образ восстановления не содержит бинарники этих расширений.
- Решение
- Восстанавливайте в тот же образ, что использует продакшен-сервис (например postgis/postgis или сборки с pgvector), а не в «чистый» postgres.
- Симптом
- Копии внезапно стали намного дольше, или репозиторий быстро растёт.
- Причина
- Вывод pg_dumpall меняется целиком, когда крупные таблицы активно пишутся, что снижает дедупликацию restic.
- Решение
- Держите ежедневное расписание и позвольте prune + retention обрезать историю; для очень больших кластеров сверяйтесь с трендом размера на карточке проекта, что политика хранения действительно чистит.
- Симптом
- Запуск резервного копирования падает с устаревшей блокировкой restic после сбоя или перезагрузки.
- Причина
- Предыдущая задача умерла посреди запуска и оставила репозиторий заблокированным.
- Решение
- Вручную делать ничего не нужно: следующий запуск обнаружит осиротевшую блокировку и автоматически выполнит restic unlock. Если запуски продолжают падать, посмотрите настоящую ошибку в панели живых логов.
Сделайте это в один клик с Dockstash
Dockstash выполняет ровно тот дамп, что выше, передаёт его restic вовне и автоматически проверяет восстановление тренировкой — без скриптов на поддержке.
Последнее обновление: July 2026
Часто задаваемые вопросы
Почему pg_dumpall, а не копирование каталога данных?
Живой каталог данных Postgres пишется постоянно. Его копия захватывает порванное, несогласованное состояние, которое не запустится. pg_dumpall читает согласованный MVCC-снимок с работающего сервера и даёт дамп, который чисто восстанавливается.
Блокирует ли Dockstash базу во время копирования?
Нет. pg_dumpall использует MVCC-снимки: чтение согласовано без блокировки записей. Приложение продолжает обслуживать трафик во время дампа.
Как часто резервировать PostgreSQL?
Ежедневно — практичный вариант по умолчанию; ежечасно — если потеря дня записей недопустима. На тарифе Free копии только вручную; Pro позволяет расписания вплоть до ежечасных, Business — любой cron. Сочетайте расписание с еженедельной тренировкой восстановления.
Как восстановить одну базу вместо всех?
Архив pg_dumpall — это обычный SQL; можно восстановить весь кластер через psql или использовать pg_dump/pg_restore по-базово. По умолчанию Dockstash восстанавливает полный согласованный снимок.
А расширения вроде PostGIS или pgvector?
Дамп ссылается на CREATE EXTENSION, но бинарники не содержит. Убедитесь, что в целевом образе восстановления есть те же расширения.
Где на самом деле живут резервные копии?
На вашем собственном VPS для хранения, как зашифрованные снимки restic, отправляемые по SSH. Dockstash никогда не держит ваши данные в чужом облаке — вы указываете машину под вашим контролем, а репозиторий зашифрован паролем, который есть только у вас.
Как узнать, что копия восстановима, без ручного восстановления?
Запланируйте тренировку восстановления. Dockstash восстанавливает последний снимок в изолированную рабочую область, сверяет каждый файл по байтам с источником и проверяет восстановленный дамп — затем ставит на проект значок «прошло/провалено». Еженедельная тренировка означает всегда свежее доказательство.