Our future backup code: test it!
-
@flakpyro Oh thank you. I try to go through every update post but I must have missed that one.
It worked
Makes a big difference for this VM if I back up a partially filled 250GB disk vs a largely full 8,250GB set of disks when 8TB of that doesn't need to be backed up.
-
@CodeMercenary that is exactly the use case of the [NOBAK]
the best way to speed up a transfer is to skip the transfer -
@john.c no, but this is high on our backlog, but there is no easy solution to autodetect the settings without booting the VM
Still, we have a cli to mount a VHD as a raw disk : https://github.com/vatesfr/xen-orchestra/tree/master/%40vates/fuse-vhd , this can allow you to then mount any complex setup . This hide the complexity of the vhd chain, then encryption at rest, vhd blocks, and storage difference.
-
@flakpyro today the backup code use binary stream in a the vhd format. This format is limited, by design , to 2TB disks
xcp-ng team introduce the qcow2 format to handle bigger disk
By using a independant format, we'll be able to handle both vhd and qcow2 on the backup side without multiplying complexity. We'll also be able to build the adapter to handle the various vmdk sub format (rax, cowd, sesparse and stream optimized) used by v2v and import bigger disks directly -
Could i test it on prod, along with real backups? or better to setup 2nd XO instance.
-
It's your call, but there's no guarantee it won't break for now, as the code is relatively young.
-
@olivierlambert but could it change old backup tasks\compability or something else? tests with real data obviously more helpful.
-
I will let @florent answering this one
-
I'm still getting "Cannot find module '@vates/generator-toolbox'" errors when I try to build it. I'm using the 'feat_generator_backups" branch.
-
Thanks for your feedback, @florent will take a look.
