Our future backup code: test it!
-
It's a bit early, it should be ready for Monday
-
@Delgado relevant packet aren't published yet, and we are testing it as extensively as possible before letting you play with it
-
Thanks! Looking forward to trying it out!
-
@olivierlambert @stormi this looks interesting! What will be the main advantages of using "Node generators" instead of streams for backups?
-
Yes it definitely looks really good. Will it be able to perform File Level restore, on multiple disk images in LVM LVs in a LVM VG on a single VM?
The reason being a lecturer on a Linux System Administration course, who's lecturing based on experience. The lecturer's experience is from over 30 Years of System Administration at a wide variety of Corporations including the Fortune 500.
During the course the lecturer has the student's setup VMs using LVM based drive pools for storage. Then have them learn how to add more drives to the LVM VG and increase the size of LVM LV and the filesystem formatted on the logical volume.
If the current and proposed backup engine can't support File Level restore on LVM could it be added please?
-
No change in feature in the end, however the problem with LVM could be easily solved with "Instant restore" feature, coming somewhere in 2025.
-
@olivierlambert said in Our future backup code: test it!:
No change in feature in the end, however the problem with LVM could be easily solved with "Instant restore" feature, coming somewhere in 2025.
Thanks for the reply and all of your company's hard work. When the date gets closer I'll let the Linux System Administration lecturer know about using VMs via XCP-ng, XOA and Instant Restore.
-
Will this add the ability to control which disks on the VM will be backed up? I'd love to be able to select specific disks on a VM to backup and leave others out.
Maybe configured at the VM level rather than the backup level. Flag a disk as not needing backup and then the regular backup procedure would ignore it. However, I could also see why it might be better to control it by creating a specific backup for that VM so you could have different backup schedules, some that backup those extra disks and some that don't. I have no need to ever backup the extra disks at the moment though.
-
@CodeMercenary I think what your asking for is already possible using [nobak] and [nosnap]
https://xen-orchestra.com/blog/xen-orchestra-5-96/ -
@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
