Чем бэкапить docker volumes так, чтобы не плакать при рестора?

[ralph42]

Накопилось 15 контейнеров с данными в volumes. Сейчас тупо tar по cron, но боюсь что rsync горячей базы Postgres даст битый бэкап. Как взрослые люди это делают?

[lucky1000]

Базы — только нативным дампом (pg_dump/pg_dumpall, mysqldump), не сырыми файлами на живую. Остальные volumes — restic или borg с дедупликацией. tar+cron это лотерея для всего что пишется в момент бэкапа.

[async_nerd]

Я гоняю restic в репозиторий на отдельном NAS + копия в B2. Перед бэкапом хук останавливает контейнеры без своего механизма дампа, потом стартует. Раз в месяц делаю тестовый restore в песочницу — иначе это не бэкап, а молитва.

[seniorwarlock]

Спасибо, что не забросили тему. Через год актуально как никогда

[burnedblueteam]

Для Postgres внутри контейнера правильный путь — pg_dump/pg_basebackup, а не rsync volume напрямую. Я делаю так: отдельный sidecar-контейнер (или docker exec в cron-скрипте) запускает pg_dump -Fc, пишет в /backup с именем вида db_2026-06-08.dump, потом restic backup /backup --tag postgres отправляет в B2 или любой S3-совместимый бэкенд. restic даёт дедупликацию, шифрование и retention-политику одной командой. Восстановление проверял живьём — pg_restore из .dump поднимается чисто, в отличие от rsync горячих файлов WAL.

[middlewarlock]

Для остальных volumes (не Postgres) хорошо работает связка: останавливаешь контейнер (docker stop), делаешь tar через docker run --rm --volumes-from <container> alpine tar czf - /data, пайпишь в restic или просто на диск, поднимаешь контейнер обратно. Даунтайм 5-15 секунд для большинства сервисов терпимый. Если даунтайм недопустим — смотри на volumerize или litestream для SQLite-based сервисов. Главное что потом нужно делать: раз в месяц реально восстанавливать в тестовой среде и проверять что данные читаемы, иначе бэкап это просто ритуал.