Apologies for the long silence on my end — real life got in the way and I couldn't dig into this for a while. Finally found the time now to go through it again properly, helped a lot by the details others have already posted here in the meantime. I don't think this adds a new root cause, but it does corroborate what @kagbasi-wgsdac described — same "mass collapse onto a single anchor UUID" pattern, and in my case too that anchor is a real, still-in-use base disk, not a dangling/non-existent OpaqueRef (referencing vatesfr/xen-orchestra#9578). Environment: 2-host pool, shared NFS SR, XO recently updated to the latest version (didn't change anything regarding this issue, as expected since it's XAPI-side). Ran a read-only xe vdi-list params=uuid,name-label,is-a-snapshot,snapshot-of,snapshot-time directly against the pool master. Result: 47 of 196 VDIs match the pattern (is-a-snapshot: false but snapshot-of populated). All 47 point to the exact same single anchor UUID — which resolves to one specific, actively-used base VDI, not a missing reference. snapshot-time on most affected VDIs is the epoch default (1970-01-01T00:00:00Z), but a handful show plausible real dates (e.g. late 2025 / early 2026) — suggesting those entries originally had a legitimate snapshot-of relationship that got overwritten by whatever corrupted the metadata. Currently-running VMs affected (100% of each VM's disks affected in every case): VM OS Disks Sizes VM-1 Windows Server 2016 1 50 GB VM-2 Windows Server 2016 3 50 / 200 / 450 GB VM-3 Windows Server 2019 3 100 / 100 / 100 GB VM-4 Windows 11 Pro 2 50 / 100 GB VM-5 (decommissioned) Windows Server 2016 2 100 / 50 GB VM-6 Ubuntu 24.04 2 10 / 10 GB VM-7 Ubuntu 24.04 2 10 / 10 GB VM-8 Windows Server 2025 3 25 / 25 / 64 GB VM-9 Ubuntu 24.04 2 10 / 10 GB On top of that, ~28 more affected VDIs are orphaned/unattached objects ("base copy" leftovers, old ISO references) — same pattern, no VBD attached. Not touching any of this (no snapshot-fixer.py, no manual vdi-param-set) given the risk of severing legitimate snapshot relationships that's already been flagged here. Happy to provide a full anonymized xe vdi-list dump if that's useful for tracking down the root cause. Big thanks to everyone who kept digging into this and shared their findings here — especially @kagbasi-wgsdac for the detailed write-up that pointed me in the right direction, and of course @poddingue and the whole Vates team for staying on top of this and keeping us updated despite no clear timeline yet. Really appreciate the effort that goes into this, especially for something as tricky as a metadata corruption bug across production pools. Kind Regards and thx again Alex

okay weird. Let's see if there's other reports then

Hi, sorry for the long break. i'll continue here for my colleague AlexD2006. We have now also tried with the current version (deeb3) of Xen-Orchestra, the problem remains the same. But we have now noticed other error messages (also with the old version) that appear during a delta backup ("base VDI is not a vhd; cannot compute differences"): May 23 16:40:35 xcp-mono02 xapi: [error||7644621 HTTPS 10.32.1.159->:::80|[XO] Exporting content of VDI test-vm.test 1 R:2e892fda7776|vhd_tool_wrapper] base VDI is not a vhd; cannot compute differences May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] [XO] Exporting content of VDI test-vm.test 1 R:2e892fda7776 failed with exception (Failure "base VDI is not a vhd; cannot compute differences") May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] Raised (Failure "base VDI is not a vhd; cannot compute differences") May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 1/14 xapi Raised at file stdlib.ml, line 29 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 2/14 xapi Called from file ocaml/xapi/vhd_tool_wrapper.ml, line 206 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 3/14 xapi Called from file ocaml/xapi/export_raw_vdi.ml, line 50 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 4/14 xapi Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 24 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 5/14 xapi Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 35 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 6/14 xapi Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 24 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 7/14 xapi Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 35 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 8/14 xapi Called from file ocaml/xapi/export_raw_vdi.ml, line 90 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 9/14 xapi Called from file ocaml/xapi/export_raw_vdi.ml, line 116 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 10/14 xapi Called from file ocaml/xapi/server_helpers.ml, line 101 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 11/14 xapi Called from file ocaml/xapi/server_helpers.ml, line 122 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 12/14 xapi Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 24 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 13/14 xapi Called from file string.ml, line 115 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 14/14 xapi Called from file src/sexp.ml, line 113 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] Can anyone say anything about the cause of the problem or any ideas for further analysis?

@olivierlambert said in Backup-NG Error "invalid header checksum" after VM-Disk-Resize and reaching retention Limit.: So the issue appeared just when the oldest extended delta had to be merged in the full I suppose. This is exact, but we need to have a proper process to reproduce it. This might be related to: increasing the size of the disk above a certain threshold increasing the content of the disk above a certain threshold