20

I want to take lxc container backup. We have server with 12.04 LTS ubuntu server and I have installed LXC - 1.0.0.alpha2 in it. I wanted to update our ubuntu server to 14.04 LTS. So what I want to do is have LXC containers backed up -> upgrade OS to 14.04 -> restore LXC containers. With earlier version(0.7.5 I guess) there was lxc-backup and lxc-restore but with 1.0.0.alpha2 we don't have backup and restore operations. How can I have lxc containers backup. I spent more than 3 hours with copy container folder(/var/lib/lxc/my_container/) into pendrive and paste it in another 12.04 LTS server but it is not working the error am getting is,

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

then how can I expect that it will work in upgraded 14.04 server OS.

Any Idea to have lxc-container backup?

BobTuckerman
  • 689
  • 9
  • 13
niren
  • 2,693
  • 8
  • 34
  • 58

4 Answers4

41

EDIT: March 29, 2016

In case you stumbled upon this post, my answer is really about moving the LXC containers between systems, since that seemed to be the question being asked.

If you want to backup your LXC containers, see @Stuart's answer for some great options.

Moving LXC containers between host systems

This is how I migrate LXC containers between systems. I've successfully moved ubuntu based 12.04 containers to a 14.04 host, and they work great.

  • Shutdown the container

    # lxc-stop -n $NAME

  • Archive container rootfs & config

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

    The --numeric-owner flag is very important! Without it, the container may not boot because the uid/gids get mangled in the extracted filesystem. When tar creates an archive, it preserves user / group ownership information. By default, when extracting, tar tries to resolve the archive user/group ownership names with the ids on the system running tar. This is intended to ensure that user ownership is resolved on the new system, in case the UID numeric values differ between systems.

    This is bad for an LXC filesystem because the numeric uid/gid ownership is intended to be preserved for the whole filesystem. If it gets resolved to a different value, bad things happen.

  • Copy the file to your new server

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

  • Extract rootfs

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

If you're using an overlay backed container, you'll also need to migrate the container this new one is based off of. Lastly, you might see a few warnings about skipped socket files:

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

I've ignored this error, and haven't had any issues with any of the containers I manage. If you have further issues, add your error messages to the original post and I'll elaborate.

Tombart
  • 30,520
  • 16
  • 123
  • 136
BobTuckerman
  • 689
  • 9
  • 13
  • 2
    I'd just like to add that you need to extract the rootfs (tar -xzvf) as root (or at least using sudo) as original permissions and ownership will not be applied unless you do that. – sbrattla Aug 16 '16 at 05:51
  • On my system the container is stored at: `cd /var/lib/lxd/containers/$NAME/` – Loren Nov 13 '17 at 16:08
  • Yes, that's where LXD stores it. This process mostly applies for LXC, but it should work with minor tweaks with LXD. With LXD you could actually just use `lxc copy` or `lxc publish` to backup your containers – BobTuckerman Nov 16 '17 at 22:11
  • This answer should be updated for modern LXD, where the `lxc move` command is available. https://stgraber.org/2016/04/12/lxd-2-0-remote-hosts-and-container-migration-612/ – Routhinator Jun 21 '20 at 20:07
  • # Answer should include move container to lxc/$NAME first before extracting tar mv container_fs.tar.gz $NAME – michela Aug 22 '20 at 03:11
11

EDIT: November 2017

To backup an lxc container quickly to a remote host without a btrfs filesystem I mount a filesystem from the remote host with sshfs & cd into the mount. Stop the container & create a tar.xz archive of it.

EDIT: March 2016

I now run my lxc containers on a btrfs filesystem to make it simpler to take a snapshot of the running containers. btrfs sub snap detects proc run sys are virtual filesystems & does not include them in the snapshot.

I use Duply to backup LXC containers. Unlike backing up a normal machine you DO want to include /dev from the LXC container in the backup.

apt-get install duply
duply mybackup create

In ~/.duply/mybackup/exclude I used:

- /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/*

The above will backup the whole machine & all the LXC containers.

To just backup containers edit ~/.duply/mybackup/conf & change SOURCE='/' to SOURCE='/var/lib/lxc' & remove the non lxc lines from ~/.duply/mybackup/exclude

Tested with running Alpine Linux LXC containers - will also work on Debian.

Simple Backups with Duply - you can also just do very simple unencrypted backups to a local file (set TARGET='file://[relative|/absolute]/local/path' in ~/.duply/mybackup/conf)

To sign Duply backups see GnuPG in Automated Environments ( password-less signing key instead of storing the password in plaintext ).

Set GPG_TEST='disabled' in the Duply conf file for cron jobs.

If you do not store any plaintext passwords in your conf do not disable GPG_TEST on restores - so gpg-agent caches your passwords.

Stuart Cardall
  • 2,099
  • 24
  • 18
  • Alternatively, you can do a lot of this using the frontend to duply, `duplicity`. I have a `pre` and `post` script that shuts down the container and restarts the container after the backup, so I dont need to exclude as many of the directories mounted during runtime. – BobTuckerman Jan 26 '17 at 16:19
2

I find the simplest way to back up a container is to just run lxc-clone.

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

Restoring it is as simple as copying or moving the backup back to /var/lib/lxc You can also tar it to save space.

Chris Montanaro
  • 16,948
  • 4
  • 20
  • 29
Brad Jasperson
  • 75
  • 1
  • 1
    if you tar it, and move it between systems, it may not work when you extract it unless you use the --numeric-owner flag – BobTuckerman Dec 17 '15 at 15:06
2

I agree with Brad Jasperson. I do it this way:

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

If something goes wrong with your container, and downtime costs a lot, you can run the copy:

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

and stop:

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

you can copy it back in place later in appropriate time. Good luck!

Luke Girvin
  • 13,221
  • 9
  • 64
  • 84
Alek
  • 634
  • 7
  • 7