Archiving container

LXD
1

I’d like to archive a few containers for history purposes, but I am not sure about the best way to do that with the possibillity to be able to restore it at a later date/time (say far in the future). I can rsync the rootfs, or export it as tar file, or create an image and export it as tar file and maybe others, but if I do that and LXD will change over time, how big would the risk (if any) be that I won’t be able to restore it in a newer LXD version?

2

A rootfs is a rootfs, so a tarball of the rootfs should always be fine. You can always create an empty container later and just rsync your backup over it.

We do have a plan to implement “lxc export” and “lxc import” to support specifically such use cases, but until then you have a few options:

  • Backup the container’s filesystem + the output of “lxc config show NAME”
  • Turn your container into an image and export it.
    • lxc stop NAME
    • lxc publish NAME --alias backup
    • lxc image export backup .
    • lxc image delete backup

The image route is nice because it’s all API driven and can even be done remotely, but it will not include your container’s configuration nor will it include any snapshots you may have.

1 Like
3

Thanks Stephane!
So just adding the lxc config show NAME to your proposed image export would be the way to go I guess.

If I understand you correctly the “lxc export” (and configuration?) will take the snapshots as well in the backup file?
Sounds great!

4

Right, the intent for “lxc export” is that it will allow you to export your container, including snapshots (unless you opt out of that) and even give you a filesystem optimized blob.

So if you don’t opt out of either snapshot exports or the optimized export and your container is on ZFS, you’re going to get a tarball which contains one blob for the container and then one blob for every snapshot. Those blobs will be output of “zfs send” and can therefore be re-imported by LXD as zfs datasets on the target. Alongside those blobs there’ll be a backup.yaml file (similar to what we have on disk already now) which includes all the database state for the container.

5

Sounds great Stephane!