@manilx said in Our future backup code: test it!: @florent Here is the log of the latest mirror job. All VM's are failing. https://paste.vates.tech/?8b00e8353e4139af#4zVKzqXNcpxA7d9PNehV8w4Xjo45UBj9L1RRa3cgGekC Guess I'm reverting back. Did the mirror work after revert ?

Hi, Use smart backup to target VMs with tags so you are sure NOT to miss copied VMs (because a copy means a new UUID).

@dthenot sorry not sure how the "force restart" button option works for both our full and our delta backups vs the regular scheduled backup jobs because doing the force restart lets the job run fully each time regardless of the specific machine that may have the bad/corrupt disk? That's the orange button And a manual snapshot works on all machines I believe too? Is there a smooth way to track that VHD disk GUID back to its machine in the interface?

Hi! VM export is doing an export of the current disk state (if the VM is shutdown). Double check you are not exporting an old snapshot of the VM.

@McHenry You can clone the VM, and remove the network of the clone before starting it

@olivierlambert yes, I started to work on friday, and hopefully will have a fix today

Keep us posted

@lsouai-vates P.S. This HAS been working a while ago!! I just noticed that it broke when there was a backup job, which had an error and I didn't receive an email. So I can't say when the issue started.

@henri9813 hello, thnaks for the feedback. I propose that you open a git feature in xen orchestra project so we can add it to our roadmap. Have a good day

Changing python system wide on XCP-ng shows that the appliance nature of XCP-ng is really not well understood.

@olivierlambert, Why would this issue be related to my NFS share? I can access the share without any problems, read and write operations work fine. Other NFS shares with multiple applications running are also functioning normally. I checked the XO logs and found the following: xo-server[679]: 2025-04-29T21:45:58.276Z xo:api WARN | backupNg.listFiles(...) [114ms] =!> Error: Command failed: vgchange -ay vg_iredmail xo-server[679]: File descriptor 22 (/var/lib/xo-server/data/leveldb/LOG) leaked on vgchange invocation. Parent PID 679: node xo-server[679]: File descriptor 24 (/var/lib/xo-server/data/leveldb/LOCK) leaked on vgchange invocation. Parent PID 679: node xo-server[679]: File descriptor 25 (/dev/fuse) leaked on vgchange invocation. Parent PID 679: node xo-server[679]: File descriptor 26 (/var/lib/xo-server/data/leveldb/MANIFEST-000103) leaked on vgchange invocation. Parent PID 679: node xo-server[679]: File descriptor 31 (/dev/fuse) leaked on vgchange invocation. Parent PID 679: node xo-server[679]: File descriptor 34 (/var/lib/xo-server/data/leveldb/000356.log) leaked on vgchange invocation. Parent PID 679: node xo-server[679]: WARNING: Couldn't find device with uuid oWTE8A-LNny-Ifsc-Jmtp-lTkB-dSjt-2AqhwY. xo-server[679]: WARNING: VG vg_iredmail is missing PV oWTE8A-LNny-Ifsc-Jmtp-lTkB-dSjt-2AqhwY (last written to /dev/xvda4). xo-server[679]: Refusing activation of partial LV vg_iredmail/lv_root. Use '--activationmode partial' to override. To me, this looks more like an issue with file restore than the NFS itself. It seems similar to what's reported here: https://github.com/vatesfr/xen-orchestra/issues/7029 andrew64k created this issue in vatesfr/xen-orchestra open File level restoration not working on LVM partition #7029

@McHenry hello, thanks for the report. Can you open a suggestion on Github so we can plan it or next roadmap? Have a good day.

@florent can you help him?

I got this error on a backup, that the VM was created on 8.2 but at this point the hosts are both updated to 8.3. Is there something I am missing? I am new-ish to XCP/Xen, but really liking it. Not sure what other info to include here. I was trying to do DR. I am trying CR now, and assuming it will work based on your conversation. I don't think I really need CR in this case, I am probably only backing up this VM once a year. Zabbix (zabbix-host) Snapshot Start: 2025-04-23 11:34 End: 2025-04-23 11:34 VM (2.09 TiB free - thin) - xcp-dr-zabbix transfer Start: 2025-04-23 11:34 End: 2025-04-24 00:26 Duration: 13 hours Error: (intermediate value) is not iterable Start: 2025-04-23 11:34 End: 2025-04-24 00:26 Duration: 13 hours Error: (intermediate value) is not iterable Start: 2025-04-23 11:34 End: 2025-04-24 00:26 Duration: 13 hours Error: (intermediate value) is not iterable Type: full

@McHenry xo-cli backupNg.getLogs --json limit='json:500' should work ( the command line parameter are considered as string )

@vmpr there is a high chance that we improve the scheduler , so maybe be able to plan more precisely when the full occurs, but we will always keep one full backup as the beginning of the chain You can mitigate the risk on infinite schedule by using health check : restoring the backup automatically after the job, this ensure that , at the time of backup, the files are correct, and that if an issue occurs in the backup you can start a new chain, thus detecting a backup storage issue before needed it after having a production issue

@olivierlambert Hyper-V has the concept of Dynamic memory as documented below. This allows a startup mem value to be specified and something similar could be used for health checks as this is only needed for the network to connect then them VM gets killed. [image: 1745470452383-f746e366-9f3a-4d78-a6d7-219c8faac555-image.png]