First of all congratulations to the stable release of IncusOS!
Quick question about backups. On Instances that install incus manually on top of Debian, we use borg backup to backup ZFS snapshots of instances and additional volumes. That works pretty well, especially for block level zvols.
As IncusOS does not support a shell (I like that concept), I am limited to Incus native backup options. Our VMs usually have more disks attached. To my understanding to have a full backup of a instance, I have to do the following:
use incus export <instance_name> --optimized-storage ----instance-only for instance config and first disk
and incus storage volume export <pool_name> <volume_name> --optimized-storage ----instance-only for all additional disks attached to the VM
Question: do the export commands make a (temporary) snapshot before exporting? Or can the export commands be based on a snapshot? I do not want to shut down the VM and with ZFS snapshots I get crash resistant backups. But if the export commands would not be based on temporary shapshots I am not sure if that would be the case.
Besides syncing to another Incus instance, are there any good practices / ideas / plans to get a daily backup that can be archived using differential backups? Like borg backup can do based on ZFS snapshots or something like proxmox backup server?
I really like the concept of IncusOS but I am not sure how to properly do differential backups of VMs with multiple disks in an user friendly way.
Did you consider using incus copy --refresh and incus storage volume copy --refresh combined with a snapshot schedule?
That’s the approach I’ve seen quite a few ZFS users use to handle a situation like yours. Effectively having another system running Incus (can be a VM) which just has a bunch of storage and can receive the ZFS differential stream from a source.
Thank you for the quick reply. A few questions on that:
would the receiving server also require ZFS file system for that?
is it crash consistent for running instances?
how would one create an “archive” without using the same amount of space on the source incus server? Do snapshots on the target incus server based on the synced data for the source incus server?
For optimal conditions, the target server should also run ZFS, yeah. That way you get an optimized delta transfer of data.
ZFS will ensure consistency of the dataset or volume during migration, though whether your applications running in the instance have flushed all their data to disk is a separate problem.
You can have the target server create additional snapshots if needed but you’ll want some on the source side to allow for easy incremental transfers.
You do a snapshot on the source server. Then push it over to the destination server where you can set the destination. Then do snapshots on the destination to produce the “archive”.
So you always sync from 1 daily snapshot from the source (that gets deleted after sync) to the target and based on the daily synced VM on the target make snapshots only on the target to create the “archive”.