Бэкап приложений в CapRover

Как-то очень давно мы уже разбирали тему резервного копирования CapRover и пришли к крайне неприятному выводу – платформа не способна полноценным образом бэкапить контейнеры и их тома с данными. Как же тогда осуществлять бэкап приложений в CapRover? Выход есть, и вариантов даже несколько.

Вариант №1. Скрипт

Говоря о резервном копировании томов, разработчики CapRover ясно дали понять, что не будут реализовывать требуемый функционал в самой платформе. В качестве причин называется сложность процесса бэкапа и практически гарантированная потеря данных при попытке скопировать их из рабочего контейнера.

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

curl -sSL https://raw.githubusercontent.com/caprover/caprover/master/dev-scripts/backup-vols.sh | bash -s -- backup

В процессе скрипт останавливает все рабочие сервисы, чтобы избежать потерю данных. Готовый бэкап будет помещён в директорию /backup-vols/YYYY-MM-DD (по актуальной дате), который вы сможете перенести в любое удобное место.

Чтобы в будущем восстановить данные из такого бэкапа понадобится переместить файлы резервной копии в директорию /restore-vols:

mv /backup-vols/2019-11-11 /restore-vols

И запустить скрипт командой:

curl -sSL https://raw.githubusercontent.com/caprover/caprover/master/dev-scripts/backup-vols.sh | bash -s -- restore

В идеале все эти действия можно автоматизировать при помощи Cron, и осуществлять копирование, например, в смонтированный удалённый диск. Но всё это уже далеко за гранью нашей с вами темы.

Вариант №2. Duplicati

Второй способ предполагает установку стороннего сервиса, а именно Duplicati. Сделать это можно в самом CapRover из официального репозитория приложений.

Чтобы установить Duplicati понадобится также заполнить некоторые переменные:

• Timezone – указываем свой часовой пояс, например Europe/Moscow. Это понадобится, например, для правильного планирования копирования.
• Version Tag – можно указать latest – так у вас на момент установки будет самая новая версия Duplicati.
• User ID / Group ID – необходимо узнать пользователя, у которого в вашей системе есть доступ к каталогу /var/lib/docker. Если вы точно знаете такого пользователя, отлично, узнайте его id командой:

id $имя_пользователя 

В моём же случае единственный пользователь с таким уровнем доступа – это root. Поэтому, несмотря на то, что меня наверняка забросают тапками, я укажу его ID, а именно 0.

• Path to store local backups – тут указываем корень /, чтобы в случае локального бэкапа можно было выбрать нужный каталог
• Path to source for files to backup – указываем путь до наших данных, а именно /var/lib/docker/volumes

Когда всё будет заполнено, смело нажимайте Deploy и переходите в интерфейс Duplicati по завершению установки.

Мы не будем подробно останавливаться на настройках сервиса, только лишь сразу дам совет установить сложный пароль доступа к Web-интерфейсу.

Что дальше? Для начала нам понадобится настроить новый сценарий резервного копирования. Процесс пошаговый и довольно простой, поэтому оставлю на вас 1 и 2 этап с выбором места хранения резервной копии. Что нас интересует в первую очередь, так это выбор источника данных.

В нашем случае все тома контейнеров будут хранится в каталоге source.

По умолчанию можно выбрать весь каталог, однако вы также можете исключить некоторые тома и оставить только нужные приложения. Они, кстати, всегда имеют названия в формате captain--название_приложения-название_директории.

Следующий пункт позволит выбрать расписание, и вот здесь состоит самая важная загвоздка.

В идеале, чтобы удостовериться в целостности копируемых данных, перед созданием бэкапа необходимо выключать работающие Docker контейнеры. Такой способ, на самом деле, не особо надёжный. Ведь для каждого запуска резервного копирования нам нужно надеяться на свою память. Целостности в копиях таким образом не добиться.

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

docker container ls

Чтобы остановить нужный контейнер используем команду:

docker stop docker_id_или_имя_контейнера

Далее, заканчиваем настройку сценария резервного копирования, а именно:

• снимаем галочку с автоматического бэкапа;

• выбираем размер одного архива и политику хранения (мои настройки выглядят как-то так).

После чего запускаем процесс резервного копирования, и не забываем включить контейнеры:

docker run docker_id_или_имя_контейнера

Если же вы привыкли к риску и решили “бэкапить” данные контейнеров без их остановки, игнорируем последние 3 команды, устанавливаем график и сохраняем сценарий резервного копирования.

Итог. Что лучше?

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

В первую очередь советую выбирать инструмент в зависимости от ваших познаний. Главным критерием всегда будет возможность автоматизации процесса резервного копирования. Повезёт, если вы сможете настроить скрипт на работу с Cron. В противном случае, Duplicati ваш надёжный друг.

Лично я использовал именно Duplicati и не испытывал каких-то проблем даже без остановки контейнеров.