Мой блог - Современный подход к резервному копированию контейнеров Linux-серверов

Современный подход к резервному копированию контейнеров Linux-серверов

Представляю вашему вниманию, активно применяемый мной метод ежедневного резервного копирования серверов, основанный на использовании технологии снятия копии текущего состояния LXC-контейнера и выгрузки его дампа. Данный метод не требует остановки сервера и создает полноценный образ состояния сервера (копия снимается раз в день), а промежуточные резервные копии файлов и баз данных ваших проектов вы можете выполнять с требуемой регулярностью штатными средствами базы данных и операционной системы.

Фотография автора

Автор: Антон Черноусов
Опубликовано: 3 месяца (последние правки: 0 минут назад) - 2 комментария
Категории записи: Linux, LXC/LXD, Ubuntu, Виртуализация, Системное администрирование


Представляю вашему вниманию, активно применяемый мной метод ежедневного резервного копирования серверов, основанный на использовании технологии снятия копии текущего состояния LXC-контейнера и выгрузки его дампа. Данный метод не требует остановки сервера и создает полноценный образ состояния сервера (копия снимается раз в день), а промежуточные резервные копии файлов и баз данных ваших проектов вы можете выполнять с требуемой регулярностью штатными средствами базы данных и операционной системы.

Сервер с запущенными LXC-контейнерами

Естественно, что для реализации такого подхода вам потребуется актуальная версия гипервизора контейнеров LXD, с актуальным модулем сохранения замороженного состояния процессов CRIU. Если вы еще не используете в своей работе эти технологии, то я рекомендовал бы вам пристальнее к ним присмотреться, так как помимо полноценной контейнерной виртуализации, вы получаете механизмы копирования и горячей миграции, доступные в других системах контейнероной виртуализации только в коммерческих решениях.

Фактически, для резервного копирования работающего контейнера (например gita-dev-ru), нам необходимо выполнить следующую последовательность команд:

# lxc copy gita-dev-ru gita-dev-ru-backup --stateless
# lxc publish gita-dev-ru-backup --alias gita-dev-ru-backup-image
# lxc image export gita-dev-ru-backup-image ./gita-dev-ru-backup-image
# lxc image delete gita-dev-ru-backup-image
# lxc delete gita-dev-ru-backup

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

Операция "lxc copy gita-dev-ru gita-dev-ru-backup --stateless"

Данная команда, создает копию работающего контейнера без его остановки, используя CRIU для снимка текущего состояния запущенного контейнера и ,по завершении данной операции, вы получите в списке контейнеров остановленный контейнер с именем "gita-dev-ru-backup".

Создание клона работающего сервера

Этот контейнер находится в том же хранилище и представляет собой срез состояния "виртуальной машины". Запускать его я вам не рекомендую, так как он получит тот-же мак-адрес, что и работающий контейнер, что ,естественно, вызовет конфликт.

Операции lxc publish и lxc image export

И хотя, файловую часть скопированного контейнера вы можете найти в виде обычных файлов (обычно в каталоге /var/lib/lxd/storage-pools/default/containers/), копировать его напрямую командами cp или rsync я бы вам не рекомендовал. Как вы видите, у контейнера схема UID/GID файлов смещена и root-пользователь контейнера имеет идентификатор отличный от 0.

Для каждого LXD-контейнера смещение UID/GID может отличаться и я вам крайне рекомендую использовать штатный механизм создания образа и выгрузки его в файл, что  и делают две эти команды.

# lxc publish gita-dev-ru-backup --alias gita-dev-ru-backup-image
# lxc image export gita-dev-ru-backup-image ./gita-dev-ru-backup-image

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

Выгрузка контейнера LXC в tar.gz архив

Последний этап - это удаление копии контейнера и образа в хранилище

Две финальные команды:

# lxc image delete gita-dev-ru-backup-image
# lxc delete gita-dev-ru-backup

Команда lxc delete - удаляет копию контейнера в хранилище контейнеров, а команда lxc image delete - удаляет образ контейнера в хранилище образов.

Удаление LXD-контейнера и образа

Теперь ,как вы понимаете, мы привели хранилище к исходному состоянию.

Автоматизированное резервное копирование LXC-контейнеров

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

#!/bin/sh
LXC_VM=`echo $1`
lxc copy $LXC_VM $LXC_VM-backup --stateless
lxc publish $LXC_VM-backup --alias $LXC_VM-backup-image
lxc image export $LXC_VM-backup-image /opt/backup/$LXC_VM-backup-image
lxc image delete $LXC_VM-backup-image
lxc delete $LXC_VM-backup

Для лучшего понимания происходящих процессов представляю вашему вниманию видео-презентацию.

Восстановление контейнера из резервной копии

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

# lxc image import ./b37549eac8eece42f22d7990242e480ac9c56ca4125216910227b34bbe9c1bbb.tar.gz --alias import-lxc-1
# lxc init import-lxc-1 test-ubuntu-lxd
# lxc image delete b37549eac8eece42f22d7990242e480ac9c56ca4125216910227b34bbe9c1bbb

Пожалуйста, оцените мою статью (всего оценок 2, средняя оценка 5.00):

Комментарии к статье:

Sergey 2 месяца, 1 неделя назад

А реальные сервера вы чем бэкапите?

Ссылка | Ответ

Anton Chernousov 2 месяца, 1 неделя назад

В зависимости от обстоятельств от бакулы до банального rsync или копирования на гуглодиск. У меня много серверов на обслуживании и требования везде разные.

Ссылка | Ответ

Оставьте комментарий:

обязательно

обязательно (не публикуется)

необязательно

обязательно

обязательно