Данные в named volumes на одном Docker-хосте не защищены от отказа диска/хоста. Как спроектировать резервное копирование и восстановление (DR) для контейнерных данных, и какие варианты существуют?

Короткий ответ

Единого решения нет: варианты — от периодических файловых снапшотов volume (например, через временный контейнер с tar) до репликации на уровне самого приложения/СУБД, либо использования внешнего распределённого хранилища (сетевое хранилище, объектное хранилище, блочное хранилище облака) со встроенными снапшотами — выбор зависит от требований RPO/RTO и объёма данных.

Как это работает подробнее

простой файловый backup volume достаточно сделать временным контейнером, который монтирует тот же volume в режиме только для чтения и упаковывает его содержимое в архив, сохраняемый вне хоста. Для баз данных такой подход без координации с самим приложением (например, без pg_dump/аналогичного механизма "горячего" снапшота или краткой паузы записи) может дать несогласованный на уровне транзакций снимок, если файлы менялись во время архивации. Внешние распределённые хранилища (сетевой блочный диск со снапшотами на уровне облака, Ceph и т.п.) решают эту проблему на уровне инфраструктуры, но добавляют сетевую зависимость и обычно более высокую latency по сравнению с локальным диском хоста.

Пример кода

Пример конфигурацииКопировать

$ docker run --rm -v pgdata:/data:ro -v /backup:/backup \
    busybox tar czf /backup/pgdata-$(date +%F).tar.gz -C /data .
$ docker run --rm -v pgdata_restored:/data -v /backup:/backup \
    busybox tar xzf /backup/pgdata-2024-05-01.tar.gz -C /data

Что использовать на практике

• Практика. для stateful-сервисов в Docker нужно явно выбрать и зафиксировать целевые RPO (сколько данных допустимо потерять) и RTO (сколько времени допустимо на восстановление), и подобрать механизм backup исходя из этих цифр — для некритичных данных периодический файловый снапшот может быть достаточен, для БД с жёсткими требованиями обычно нужен специализированный механизм резервного копирования самой СУБД плюс репликация.

Подводные камни

• Риск. считают репликацию (если она настроена на уровне приложения) полноценной заменой бэкапа — репликация защищает от отказа одного узла, но не от логической ошибки (например, ошибочного DELETE или повреждения данных), которая мгновенно реплицируется на все узлы; никогда не тестируют процедуру восстановления из backup, обнаруживая проблему с самим архивом только в момент реального инцидента.