Как сделать резервное копирование / перемещение контейнеров LXC?

Я хочу взять резервную копию контейнера для lxc. У нас есть сервер с 12.04 LTS ubuntu server и я установили LXC - 1.0.0.alpha2 в нем. Я хотел обновить наш сервер ubuntu до 14.04 LTS. Итак, что я хочу сделать, это создать резервные копии контейнеров LXC - > обновить ОС до 14.04 - > восстановить контейнеры LXC. С более ранней версией (0.7.5 я думаю) был lxc-backup и LXC-restore, но с 1.0.0.alpha2 у нас нет операций резервного копирования и восстановления. Как я могу сделать резервную копию контейнеров lxc. Я провел более 3 часов с контейнером для копирования папка (/var/lib/lxc/ my_container/) в pendrive и вставьте его в другой 12.04 LTS сервер, но он не работает ошибка я получаю,

#sudo lxc-start -n my_container
lxc-start: invalid sequence number 1, expected 4.
lxc-start: failed to spwan "my_container"

тогда как я могу ожидать, что он будет работать в обновленной 14.04 server OS.

любая идея иметь резервную копию lxc-контейнера?

11
backup lxc ubuntu

4 ответов

EDIT: 29 марта 2016

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

если вы хотите резервное копирование ваши контейнеры LXC, см. ответ @Stuart для некоторых больших вариантов.

перемещение контейнеров LXC между хост-системами

вот как я переношу контейнеры LXC между системами. Я успешно переместил контейнеры ubuntu 12.04 на хост 14.04, и они отлично работают.

  • выключение контейнер

    # lxc-stop -n $NAME

  • архивный контейнер rootfs & config

    # cd /var/lib/lxc/$NAME/
# tar --numeric-owner -czvf container_fs.tar.gz ./*

    на --numeric-owner флаг-это очень важно! Без него контейнер может не загружаться, потому что uid/gids искажаются в извлеченной файловой системе. когда tar Создает архив, он сохраняет пользователя / группу информация о собственности. По умолчанию при извлечении tar пытается разрешить имена владельца пользователя/группы архива с идентификаторами в системе, в которой выполняется tar. Это предназначено для обеспечения разрешения права собственности пользователя в новой системе, если числовые значения UID отличаются между системами.

    это плохо для файловой системы LXC, потому что числовое владение uid/gid предназначено для сохранения для всей файловой системы. Если он будет разрешен для другого значения, плохо всякое случается.

  • скопируйте файл на новый сервер

    # rsync -avh container_fs.tar.gz user@newserver:/var/lib/lxc/

  • извлечь rootfs

    # mkdir /var/lib/lxc/$NAME/
# cd /var/lib/lxc/$NAME/
# tar --numeric-owner -xzvf container_fs.tar.gz .

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

tar: /var/lib/lxc/$NAME/rootfs/dev/log: socket ignored

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

31

EDIT: ноябрь 2017

для резервного копирования lxc контейнер быстро к remote хоста без btrfs файловая система я монтирую файловую систему из remote хоста sshfs & cd на гору. Остановите контейнер и создайте tar.xz архив.

EDIT: март 2016

теперь я запускаю свой lxc контейнеров на btrfs файловой системы, чтобы сделать его проще взять snapshot работает стеклотара. btrfs sub snap обнаруживает proc run sys являются виртуальными файловыми системами и не включают их в снимок.

я использую Duply для резервного копирования контейнеров LXC. В отличие от резервного копирования нормальной машины вы DO хотите включить /dev из контейнера LXC в резервной копии.

apt-get install duply
duply mybackup create

на ~/.duply/mybackup/exclude я:

- /cdrom
- /dev
- /lost+found
- /media
- /mnt
- /proc
- /run
- /sys
- /tmp
- /var/backup/restore/*
- /var/backup/tmp/*
- /var/lib/lxc/*/rootfs/lost+found
- /var/lib/lxc/*/rootfs/media/*
- /var/lib/lxc/*/rootfs/mnt/*
- /var/lib/lxc/*/rootfs/proc/*
- /var/lib/lxc/*/rootfs/run/*
- /var/lib/lxc/*/rootfs/sys/*
- /var/lib/lxc/*/rootfs/tmp/*
- /var/lib/lxcfs/*

вышеуказанное подперет всю машину & все контейнеры LXC.

просто резервное копирование контейнеры редактировать ~/.duply/mybackup/conf и SOURCE='/' to SOURCE='/var/lib/lxc' & удалить не lxc линии из ~/.duply/mybackup/exclude

протестировано с помощью running контейнеры Alpine Linux LXC - также будет работать на Debian.

простые резервные копии с Duply - вы также можете просто сделать очень простые незашифрованные резервные копии в локальный файл (set TARGET='file://[relative|/absolute]/local/path' на ~/.duply/mybackup/conf)

подписать Duply резервные копии см. GnuPG в автоматизированных средах ( пароля ключа подписи, а не хранить пароль в открытом виде ).

Set GPG_TEST='disabled' в Duply conf файл для заданий cron.

если у вас не хранить любые пароли открытого текста в вашем conf do не отключить GPG_TEST on восстановление - так gpg-agent кэширует пароли.

9

Я согласен с Брэдом Jasperson. Я делаю это так:

lxc-clone -KMP /path/to/backup name name

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

lxc-start -n name -P /path/to/backup

и

lxc-stop -n name -P /path/to/backup

вы можете скопировать его на место позже в подходящее время. Удачи!

2

Я нахожу самый простой способ резервного копирования контейнера - просто запустить lxc-clone.

lxc-clone -o NAMEOFCONTAINER -n NAMEOFCONTAINER -P BACKUPDIR

восстановление так же просто, как копирование или перемещение резервной копии обратно в /var / lib/lxc Вы также можете смолить его, чтобы сэкономить место.

1