Как установить и настроить бэкап Docker volume на VPS

MAATRIX

Данные ваших контейнеров — базы, загрузки, состояние — живут в томах Docker, и их потеря обычно необратима. Настроить бэкап Docker volume на VPS — значит один раз поставить процесс, который регулярно сохраняет содержимое томов в архив и увозит его в безопасное место. Разберём по шагам: как снять дамп тома, автоматизировать по расписанию, выгрузить копию за пределы сервера и, главное, восстановиться.

Почему том — это не бэкап

Распространённое заблуждение: раз данные лежат в именованном томе, они в безопасности. Том защищает от одного — от пересоздания контейнера: вы можете обновить образ, и данные останутся. Но том никак не спасает от гибели диска сервера, от ошибочного docker volume rm, от повреждения базы или от шифровальщика. Всё это уничтожает и контейнер, и его том разом.

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

Отдельно про базы данных. Простое копирование файлов тома работающей базы может дать несогласованный снимок, если запись шла в момент копирования. Поэтому для баз предпочтительнее логический дамп средствами самой СУБД, а копирование файлов тома оставляют для данных, которые не меняются в момент бэкапа, либо делают на остановленном контейнере. Это важная тонкость, которую многие узнают уже после неудачного восстановления.

Подготовка и ручной бэкап тома

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

mkdir -p /opt/backups

Теперь снимем архив тома db_data. Временный контейнер с образом alpine монтирует том только для чтения и папку назначения, после чего архивирует содержимое:

docker run --rm \
  -v db_data:/data:ro \
  -v /opt/backups:/backup \
  alpine tar czf /backup/db_data-$(date +%F).tar.gz -C /data .

Ключевое здесь — :ro (только чтение), чтобы случайно не повредить данные, и метка даты в имени файла, чтобы копии не перезаписывали друг друга. Проверьте, что архив создался и имеет ненулевой размер:

ls -lh /opt/backups

Для базы данных вместо копирования файлов лучше снять логический дамп. Например, для PostgreSQL в контейнере это выполнение pg_dump внутри него с выводом в файл на хосте — такой дамп гарантированно согласован.

Логический дамп базы данных

Разберём правильный бэкап базы на примере PostgreSQL, потому что это самый частый и самый ответственный случай. Вместо архивации файлов тома мы просим саму СУБД отдать согласованный дамп. Если база работает в контейнере db, команда выглядит так:

docker exec db pg_dump -U postgres appdb | gzip > /opt/backups/appdb-$(date +%F).sql.gz

Здесь pg_dump внутри контейнера формирует логическую копию базы, а gzip на хосте сразу её сжимает. Такой дамп можно восстановить в любую совместимую версию базы, и он не зависит от согласованности файлов на диске. Для MySQL и MariaDB аналогично используют mysqldump:

docker exec db mysqldump -u root -пПАРОЛЬ appdb | gzip > /opt/backups/appdb-$(date +%F).sql.gz

Логический дамп — золотой стандарт для баз. Архивацию файлов тома оставьте для того, что не является базой: пользовательских загрузок, конфигураций, статических данных. Разделяя эти два подхода, вы избегаете самой частой причины «бэкап есть, а восстановиться не смог» — несогласованного снимка живой базы.

Автоматизация по расписанию через cron

Ручной бэкап бесполезен, если о нём забывают. Автоматизируем. Соберём скрипт, который снимает дампы и удаляет старые копии, затем повесим его на cron. Создайте файл /opt/backups/backup.sh:

#!/bin/bash
set -e
DEST=/opt/backups
DATE=$(date +%F)
docker exec db pg_dump -U postgres appdb | gzip > $DEST/appdb-$DATE.sql.gz
docker run --rm -v uploads:/data:ro -v $DEST:/backup \
  alpine tar czf /backup/uploads-$DATE.tar.gz -C /data .
find $DEST -name "*.gz" -mtime +14 -delete

Строка с find ... -mtime +14 -delete — это ротация: она удаляет копии старше двух недель, чтобы бэкапы не заполнили диск. Сделайте скрипт исполняемым и добавьте задание в cron на ежедневный запуск ночью:

chmod +x /opt/backups/backup.sh
crontab -e

В редакторе crontab добавьте строку 0 3 * * * /opt/backups/backup.sh, чтобы бэкап снимался каждый день в 3 часа. Теперь копии создаются сами, а старые удаляются. Проверьте, что задание записалось, командой crontab -l.

Выгрузка копий за пределы сервера

Бэкап на том же сервере — половина решения: если диск умрёт или сервер станет недоступен, копии исчезнут вместе с данными. Поэтому архивы нужно увозить наружу — в объектное хранилище S3, на другой сервер или в удалённое хранилище. Проще всего использовать S3-совместимое хранилище. Установите клиент и добавьте выгрузку в скрипт:

apt install -y rclone
rclone copy /opt/backups remote:my-backups --include "*$(date +%F)*"

После настройки удалённого хранилища в rclone эта строка догружает свежие архивы в облако. Альтернатива без облака — копирование на второй сервер по SSH командой scp или rsync. Главное — чтобы копия физически лежала не на том же диске и желательно в другой локации. Тогда даже полная потеря основного сервера не означает потерю данных.

Здесь удобно, что второй сервер под хранение бэкапов можно взять недорого в другой локации. У MAATRIX доступны RU, US и UK с оплатой из России картой, СБП или криптой, и разнести боевой сервер и хранилище копий по разным площадкам — разумная страховка без сложных схем.

Восстановление и проверка бэкапов

Бэкап существует ради восстановления, и его нужно проверять, а не просто накапливать. Отработайте процедуру заранее, чтобы в реальной аварии не изобретать её впопыхах. Восстановление логического дампа PostgreSQL — это подача его содержимого в базу:

gunzip -c /opt/backups/appdb-2026-08-20.sql.gz | docker exec -i db psql -U postgres appdb

Восстановление архива тома — обратная операция к бэкапу: распаковка архива в том через временный контейнер. Обязательно тренируйтесь восстанавливаться на тестовом окружении, а не на боевом, и хотя бы раз в месяц проверяйте, что свежая копия действительно разворачивается. Копия, из которой не пробовали восстановиться, ненадёжна: повреждённый архив, неполный дамп или несовместимая версия всплывают именно при восстановлении.

Сведём всё воедино. Регулярность обеспечивает cron, согласованность — логический дамп для баз, сохранность — выгрузка копий в другую локацию, надёжность — проверка восстановления. Такой процесс защищает данные по-настоящему, а не на бумаге. И помните, что бэкапы занимают место и требуют быстрого диска для скорости снятия и восстановления, поэтому серверу под данные и копии нужен запас по объёму. У MAATRIX VPS с быстрым NVMe доступны с оплатой из России картой или криптой, что позволяет держать и боевые данные, и историю бэкапов без тесноты.

Частые вопросы