@k11maris said in delta backups with offline snapshot: VMs do not start after snapshot, they start after transfer is done.: I think there is a way with changed block tracking to use delta backups without snapshots, right? I'll have to look into that. ypu need to check those [image: 1764069142589-c0b0933b-c566-4807-bcc9-227a9fa663d7-image.png] and yes a VM that is BACKUPed and REPLICAted have 2 snaps. didn't see a snapshot for Disaster Recovery job though (seems to be snaped, but deleted afterward as there is no need to delta on the next snap), you could use these, but full only and one temporary snapshot during the DR export.

Yes, and then Xen will reduce the RAM if there's not enough available to boot a new VM (reducing down to dynamic min). Static means it can't be changed live, while dynamic can.

@MajorP93 aha, yea. Per disk concurrency is important too.

@Forza Cancelling a backup run is also on our roadmap ,as soon as we have done reworking the tasks to use xo-task on the full chain, and not an hybrid of various iteration of the tasks objects better tracking of the backup run is also on our roadmap , this is also linked to the task changes plus are some issues with the size on the remote before being able to do this In any case, both are on our backlog

@olivierlambert Thank you for the reply. There was a thread on here about the iso not being mounted properly and I commented about having power off the vm and back and it will load the iso. This is specifically true with the 0.4.0 for linux. Image pulled from the XO Hub will not mount the ios if the vm is powered on. There is Yellow Explanation mark next to it. Power off vm and power on vm iso is ok. Reboot vm does not let the ios to work.

@florent Didn't see your message until now about only applying the fix to only 1 client. I did do a warm migration on client with ticket #7748053. This completed without issue! I tried a warm migration on client with ticket #7747444 and this failed again. Sounds expected as the patch was not on this one yet. Can you push the patch to client with ticket #7747444. Thanks!

@hoehnp we're aiming at sharing a very first public version before end of year, but don't hope for it to be anything complete or stable

@AtaxyaNetwork @Pilow @bvitnik Ok, knowing that the p2 partition was likely an old backup was exactly the breadcrumb that I needed. I confirmed via chroot and xsconsole that p2 was xcp-ng v8.2.1, and that p1 was v8.3. Then I was able to check the initrd files there. Namely I needed to see the updated dates and the kernel version. Thankfully, I saw initrd files on the backup that were the correct kernel and hadn't been disturbed. I then just cloned the initrd files from the backup partition to the p1 partition and BOOM. We booted right up. Much appreciated for the assistance, everyone. I'll still need to figure out why my disks are disconnecting, but that will be another post for another day.