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

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

 
 
Логотип GITA-DEV

Автор: Черноусов Антон aka Gita-Dev
Опубликовано: 15 Фев 2018 (последние правки 3 месяца, 1 неделя)

backup cv dev git lxd tar ubuntu копирование сервер на базе ubuntu

Сервер с запущенными 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

Похожие статьи

Сборка гипервизора контейнеров LXC (LXD) из исходных кодов и настройка окружения разработчика

Сборка гипервизора контейнеров LXC (LXD) из исходных кодов и настройка окружения разработчика

Данная статья родилась в процессе работ над проектом по тестировнию функционала горячей миграции контейнеров LXC. Мы провели сборку LXD из git-репозитария и описали шаги для повторения этих манипипуляций в дальнейшем. Дополнительно мы подготовили инструкцию по созданию окружения для наших разработчиков.


Управление дисковыми хранилищами LXD из консоли

Управление дисковыми хранилищами LXD из консоли

В предыдущей статье про базовую настройку окружения разработчика мы получили много вопросов по поводу управления дисковыми пулами и по результатам обсуждения статьи мы подготовили небольшую статью HOW-TO по управлению виртуальными дисками (и хранилищами) системы контейнерной изоляции LXD.


Скрипт и поясняющее видео сборки гипервизора контейнеров LXD из исходных кодов (мастер-ветка)

Скрипт и поясняющее видео сборки гипервизора контейнеров LXD из исходных кодов (мастер-ветка)

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


OpenVPN-сеть для LXD-кластера без назначения адресов клиентов (использование стороннего DHCP для управления клиентами VPN-сети)

OpenVPN-сеть для LXD-кластера без назначения адресов клиентов (использование стороннего DHCP для управления клиентами VPN-сети)

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


Набор скриптов для управления LXD-фермой

Набор скриптов для управления LXD-фермой

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


WEB-интерфейс управления узлом виртуализации LXD

WEB-интерфейс управления узлом виртуализации LXD

Я уже неоднократно рассказывал о настройке системы контейнерной изоляции LXD и управлении фермой LXD гипервизоров из консоли, но как верно подметили мои читатели все же хотелось бы иметь удобный графический интерфейс для управления LXD-сервером. Честно говоря какого-то официального web-интерфейса для LXD я не нашел и мне пришлось пробовать все проекты с github.


Полная инструкция по настройке гипервизора контейнеров LXD в LTS версии 18.04 Ubuntu или Ubuntu server

Полная инструкция по настройке гипервизора контейнеров LXD в LTS версии 18.04 Ubuntu или Ubuntu server

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


Отзывы и комментарии




Аватар пользователя
Анонимно

А если у меня в контейнере например база данных активно работающая? Этот метод можно использовать для резервного копирования?


Аватар пользователя
Антон Черноусов (Администратор)

Если ваша файловая система которую вы выбрали для работы с LXD поддерживает снимки, то теоретически тогда резервное копирование таким методом будет выглядеть как отключение питания на сервере (мгновенный снимок на определенный момент времени). Теоретически, ничего смертельного не будет, но вы можете потерять несколько последних транзакций, но это именно при использовании Btrfs и т.п. Если вы используете EXT, то для копирования используется rsync, и это совсем другое дело! Тут вам активно изменяемые объекты файловой системы надо копировать штатными средствами! Обратите на это внимание!