[lxc-users] backup strategies for lxd + zfs

[Spike]

Hi,

I'm on Ubuntu Xenial running LXD from PPA + a ZFS storage backend.

I've been reading everything I could find on backup strategies, but I've
not found anything "official" or that even looked like a best practice so I
thought I'd ask the list.

First thing first, I think everybody agrees that you need /var/lib/lxd with
lxd's database + the containers' fs.

For /var/lib/lxd + db it seems that a dump of sqlite + rsync should be
sufficient, without the need to stop LXD during the process. Is this true
or are there possible race conditions that require LXD to be stopped before
the db can be dumped?

For the FS, given ZFS, it seems that a snapshot + send|receive should do,
however I'm unclear if one can simply snap and move the entire pool or if
there are reasons why images should be snap'ed individually and sent over.

The other approach I found is entirely different and 100% lxd based in
which case you run LXD on the backup host too, snap containers, and then
publish an image from the snaps to the backup host. However, unless I'm
missing something, this process includes downtime because lxc snap will
stop the container, but maybe I was doing something wrong when I tested (it
makes sense in a way tho, it's trying to ensure consistency).

Besides the downtime, what I'm wondering about with this second approach is
if it requires to still dumping/rsyincing the LXD's database or if the
image will carry with itself all the configuration too.

Third, I found people using the image export command to generate tarballs
which are then copied over to the backup host. Similarly to the publish
mechanism, I'm unclear if this is going to carry over everything to restart
the container configured as it was or not.

can anybody provide some recommendations from experience running lxc in a
production environment with zfs?

thanks,

Spike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20170307/f2ed8a1a/attachment.html>