Incremental backup of lxc containers

(alix) #1

LXD 3.1 Introduced a new backup API and ability to export containers using lxc export.

Does this method allows incremental backup in which only the new deltas will be back up.

For example, a container contains three letters “X-Y-Z” was fully backed up yesterday. Today, the data is modified so now we have four letters “W-X-Y-Z”. If we then perform another full backup, it will copy the whole data “W-X-Y-Z”. But if we perform an incremental backup instead, it will only copy the “W” part of the data. Obviously, copying only the “W” part of the data will consume less disk space compared to copying the whole “W-X-Y-Z” data. Moreover, we already have the “X-Y-Z” part backed up previously, so we don’t need that part to be backed up again

(Stéphane Graber) #2

No, backups are full backups of the container.

Incremental backups tend to be a bit annoying to make, we’d effectively need to unpack the previous backup, then do a diff with the current content and spit out a delta as there’s no cheap way for us to know exactly what changed since the last backup (unlike big backup systems that will usually have a database of all files, modified times and hashes to make this easier).

(Bruce) #3

So I’m assuming that both

lxc copy


lxc image export

are always full copies/backups and that there’s no easy way to do incremental backups, other than with lxc snapshot or is snapshot also a full copy?

(Gunnar) #4

I think by nature of snapshots in general, no.

Snapshots represent a certain state of the containers livecycle. If you’d lxc copy [container]/[sn] [new_container] you’ll get a new full container in the state of sn1 (including everything which happened before, but nothing which happened after. So, if you’d make a copy of 5 snapshot, you’ll get 5 containers which are only different in size by everything which was added/removed between 2 snapshots.

That’s at least my understanding of the matter thus far.

(Bruce) #5

Got you, thanks…