@blueh2o said in Health check scripts. Where is the example?: xen-orchestra/backups/docs/healthcheck example/wait30seconds.sh that would be here https://github.com/vatesfr/xen-orchestra/tree/master/%40xen-orchestra/backups/docs

@Pilow we are still working on it, but for now we didn't find a solution

@MajorP93 It's being packaged at the moment. between this and the testing that needs to be done it might take a couple of weeks to be released, but I can't promise anything yet

@florent @fcgo the host that was queried (with host_ip/export_raw_vdi) will do the export from the shared SR, and will redirect the query to the host that can see the SR otherwise. So it's up to the XO/other orchestrators if they want to distribute the load here.

Ping @thomas-dkmt for better doc clarity about it.

Not sure If correct but the vhd-tool check seem quite basic. Looks like it only do kind of a "wrapper" check and not a full integrity check $ vhd-tool check 4156d2ea-d39d-436d-b89f-06ad64949c53.vhd 0 START of section 'footer_at_top' 1ff END of section 'footer_at_top' 200 START of section 'header' 5ff END of section 'header' 600 START of section 'BAT' 195ff END of section 'BAT' 67a00 START of section 'locator block 0' 67bff END of section 'locator block 0' 67c00 START of section 'locator block 1' 67dff END of section 'locator block 1' 67e00 START of section 'locator block 2' 67fff END of section 'locator block 2'

@florent Delta backup is also leaving old snapshots on some VMs. It should only have one (current) snapshot for the nightly backup. This is an issue on 1 of 100 VMs. XCP (Jan 2026 update) and XO (91c5d) are current. [image: 1770510564402-30de9803-0b8d-488d-b160-57c623f66e78-image.png]

Also.. Thank you for taking a look at it and solving it so quickly, @florent It is a quite nice interaction when reporting bugs that they are looked at and triaged. Not saying everything needs to be a priority 1. But I do appreciate being close to the process. And if I can help make things better by reporting bugs, in a hopefully constructive way. Then I'll continue to contribute my way.

It's not a problem with XO backups

@florent I tried to upload it with the "Upload button" and got this error" [2026-02-05T15_03_26.704Z - backup NG.json](Invalid file type. Allowed types are: .png, .jpg, .bmp, .txt, .diff, .patch, .jpeg) " 2026-02-05T15_03_26.704Z - backup NG_json.txt

@florent As it turns out, the job completed the next time it ran and this task went away, not sure why that first one failed but it seems to be OK for now. I will update this if I see this error again and be sure to include as many logs as I can. Thanks as always!

Keep us posted, happy to hear from it!

@LoTus111 Hello, I attempted to reproduce the issue without success. Could you please share the logs with us so we can conduct a deeper investigation? Feel free to send them to me via PM.

@florent increasing the timeout value was the solution. Thank you.

@florent I think you meant it was locking the xoa via .tar.gz but not via .zip which seemed to be the case Yeah I just decompressed the restored .zip and checked number of files and size via ncdu, result: "Total disk usage: 194,5 MiB Apparent size: 193,1 MiB Items: 613" In case I can provide more information for investigating this issue, please let me know. Thanks and best regards

I recreate my ZFS pool. But next time or for other stuck with this kind of issue, I think you should start to rename your ZFS POOL. I think the old ZPOOL name stay in XO configuration shadow settings. To rename a ZFS pool, export it with zpool export [poolname] and then import it with the new name using zpool import [poolname] [newpoolname] And then recreate (sr-create) your STORAGE in XO

@myles3 Hello Myles3. This post is over 20 days old. The issue was since been resolved by support. I dont remember the exact solution off the top of my head with out looking it up.