Бэкап Docker volume на сервере: частые ошибки и решения

MAATRIX

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

Как проверить, что бэкапы вообще рабочие

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

ls -lh /opt/backups

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

gzip -t /opt/backups/appdb-2026-08-20.sql.gz && echo OK

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

Дамп базы не восстанавливается

Самая болезненная ошибка: файл есть, а восстановить из него базу не получается — ошибки согласованности, битые данные, обрыв. Частая причина — бэкап снимался копированием файлов тома работающей базы. Пока идёт запись, файлы на диске находятся в промежуточном состоянии, и их снимок оказывается несогласованным.

Правильное решение — снимать логический дамп средствами самой СУБД, а не копировать файлы живой базы. Для PostgreSQL это pg_dump, для MySQL — mysqldump:

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

Такой дамп гарантированно согласован, потому что СУБД сама отдаёт целостный снимок. Вторая причина невосстановимости — несовпадение версий: дамп с новой версии базы не всегда встаёт в старую. Восстанавливайте в совместимую или ту же версию. Третья — обрыв дампа из-за нехватки места или прерывания: если во время pg_dump кончился диск, файл будет неполным. Проверяйте свободное место и код завершения бэкапа. И всегда тренируйте восстановление заранее, а не в момент аварии, — только так вы узнаете о проблеме вовремя.

Архив тома оказался пустым

Симптом: бэкап-скрипт отработал без явных ошибок, но архив тома почти нулевого размера, а внутри ничего нет. Обычно причина в неверном пути или имени тома при монтировании. Если во временный контейнер смонтирован не тот том или не тот каталог внутри, архивируется пустота.

Проверьте, что том существует и в нём есть данные, а также правильный путь монтирования:

docker volume ls
docker run --rm -v db_data:/data:ro alpine ls -la /data

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

docker inspect app | grep -A10 Mounts

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

Cron не запускает бэкап

Классика: скрипт бэкапа работает при ручном запуске, а по расписанию не срабатывает, и через месяц выясняется, что свежих копий нет. Причин у молчащего cron несколько, и все типовые. Первая — cron выполняет задания в урезанном окружении без вашего PATH, поэтому команды вроде docker могут не находиться. Указывайте в скрипте полные пути или задавайте PATH в начале.

Проверьте, что задание вообще зарегистрировано и когда оно запускалось:

crontab -l
grep CRON /var/log/syslog | tail -n 20

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

0 3 * * * /opt/backups/backup.sh >> /opt/backups/backup.log 2>&1

Теперь после запланированного времени в backup.log будет либо успех, либо конкретная ошибка. Третья причина — бэкап падает молча на середине из-за set -e и, например, недоступного контейнера базы. Логирование вывода вскрывает и это. Правило простое: любой бэкап-скрипт должен писать лог и, в идеале, слать уведомление об успехе или провале, чтобы молчание не принимали за работу.

Копии лежат на том же диске

Самая коварная ошибка, потому что до аварии она незаметна: бэкапы исправно снимаются, но лежат в каталоге на том же сервере и том же диске, что и данные. Когда диск выходит из строя или сервер становится недоступен, копии исчезают вместе с оригиналом. Технически бэкап был, а данных нет.

Решение — обязательно увозить копии за пределы сервера. Настройте выгрузку в объектное хранилище или на второй сервер и добавьте её в бэкап-скрипт:

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

Проверяйте, что выгрузка реально происходит, а не только настроена: заглядывайте в удалённое хранилище и убеждайтесь, что свежие архивы там появляются. Идеальная схема разносит боевой сервер и хранилище копий по разным физическим машинам, а лучше и по разным локациям, — тогда никакой единичный сбой не уничтожит и данные, и бэкапы сразу. Второй недорогой VPS под хранилище копий в другой локации решает это надёжно: у MAATRIX площадки RU, US и UK доступны с оплатой из России картой или криптой, и разнести данные и бэкапы получается без сложных схем.

Профилактика и здравый смысл

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

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

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