Thanks. I also used "disaster recovery" with the "offline backup" option before.
I also just noticed: Every time I open the backup settings, the email address field is empty.

Btw: It is really confusing that it still says "disaster recovery" while the documentation uses other names....

@Bastien-Nollet
I am using delta backups, not full backups. So there is no option called "offline backup".

However, I was in fact using "backup" before and had "offline backup" enabled. Maybe this option is still checked, but invisible... I did not create a new backup job, I simply de-selected "full backup" and activated "delta backup".

This is my configuration:

Hi,

I just did delta backups with offline snapshot. There are 6 VMs in this job (smart mode).
It shuts down the VM(s) as expected and takes the snapshot. Then it exports to the remote and then it starts up the respective VM again. Is this a bug? Why does it not start the VM immediately after taking the snapshot? Or can this be caused by a setting?

Strange... I habe another job, again offline snapshot. There is only von VM in this job. Here it starts the VM immediately after taking the snapshot....

I am seeing this message, too. This is the first time I try out delta backups. I only did one backup so far, so this is a full backup. Storage is NFS.

Yes, OVA of course.

Import as OVH worked fine. Thanks!

I guess it is in fact a static vhd (same size as needed for the applicance). Hm.... Can I just manually copy that to an NFS storage repository and rescan?

Hi,

I am trying to import a 100 GB VHD. It fails with XCP-ng Center ("import failed") and also with xen orchestra from source ("fetch failed"). I had a tail -f /var/log/*.log running on the master when I tried the import with xo and there was absolutely nothing showing up, so I think the problem is either the web browser (edge) or xo. Any ideas?
Thanks?

@Danp
No, I am not familiar with many of the "manual" commands. I have to figure out how to use that with LVM over iSCSI.
Meanwhile, I stopped the VM, did a SR scan and it coalesced successfully. Offline always works fine....

@Danp
The failed backup from last weekend left an orphaned disk and a disk connected to the control domain behind which I removed.

I tried a couple of backups today, all worked finde, including XO. However, while 4 Linux-VMs coalesced after a few minutes, one failed. So it is not limited to Windows VMs.
Usually, I get "Exception unexpected bump in size" for the windows VMs, so it might be a different issue here.
There is nothing special about the affected VM. Ubuntu 22.04 LTS, almost no CPU or IO load.

Apr 26 11:31:33 xen002 SMGC: [18314] Removed leaf-coalesce from 37d94ab0[VHD](25.000G/479.051M/25.055G|a)
Apr 26 11:31:33 xen002 SMGC: [18314] *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Apr 26 11:31:33 xen002 SMGC: [18314]          ***********************
Apr 26 11:31:33 xen002 SMGC: [18314]          *  E X C E P T I O N  *
Apr 26 11:31:33 xen002 SMGC: [18314]          ***********************
Apr 26 11:31:33 xen002 SMGC: [18314] leaf-coalesce: EXCEPTION <class 'util.SMException'>, VDI 37d94ab0-9722-4447-b459-814afa8ba24a could not be coalesced
Apr 26 11:31:33 xen002 SMGC: [18314]   File "/opt/xensource/sm/cleanup.py", line 1774, in coalesceLeaf
Apr 26 11:31:33 xen002 SMGC: [18314]     self._coalesceLeaf(vdi)
Apr 26 11:31:33 xen002 SMGC: [18314]   File "/opt/xensource/sm/cleanup.py", line 2053, in _coalesceLeaf
Apr 26 11:31:33 xen002 SMGC: [18314]     .format(uuid=vdi.uuid))
Apr 26 11:31:33 xen002 SMGC: [18314]