AssertionError [ERR_ASSERTION]: footer1 !== footer2
-
xo-backups clean-vms -m /vm1 VHD check error { path: '/vm1/vdis/e8c6772b-0bab-489d-a24e-b41e07f9298b/7572fba5-2cbb-496a-9349-deb8f0c1af29/.20240914T191707Z.vhd', error: AssertionError [ERR_ASSERTION]: footer1 !== footer2 at VhdFile.readHeaderAndFooter (/usr/lib/node_modules/@xen-orchestra/backups-cli/node_modules/vhd-lib/Vhd/VhdFile.js:195:7) at async VhdFile.open (/usr/lib/node_modules/@xen-orchestra/backups-cli/node_modules/vhd-lib/Vhd/VhdFile.js:95:7) at async openVhd (/usr/lib/node_modules/@xen-orchestra/backups-cli/node_modules/vhd-lib/openVhd.js:15:14) at async Promise.all (index 0) at async Set.<anonymous> (file:///usr/lib/node_modules/@xen-orchestra/backups-cli/node_modules/@xen-orchestra/backups/_cleanVm.mjs:209:7) at async Promise.all (index 0) at async RemoteAdapter.cleanVm (file:///usr/lib/node_modules/@xen-orchestra/backups-cli/node_modules/@xen-orchestra/backups/_cleanVm.mjs:203:3) at async Disposable.<anonymous> (file:///usr/lib/node_modules/@xen-orchestra/backups-cli/commands/clean-vms.mjs:26:9) at async Promise.all (index 0) at async cleanVms (file:///usr/lib/node_modules/@xen-orchestra/backups-cli/commands/clean-vms.mjs:23:3) { generatedMessage: false, code: 'ERR_ASSERTION', actual: false, expected: true, operator: '==' } }
-
Hi,
I'm not sure to understand what you expect by just posting an error log without any context like this
-
@olivierlambert I was running the clean-vms -m command to try and merge a bunch of delta backups into a single .vhd file but it throws this strange assertion error which makes no sense to me. Looking for suggestions because it should be a relatively straightfoward task..
-
Context is king: XO source or XOA? Which version?
-
@olivierlambert Neither. A ubuntu VM with backups-cli installed via
npm install --global @xen-orchestra/backups-cli
-
Hmm I'm not sure we provide anything supported directly via npm. Pinging @julien-f
-
@olivierlambert Shouldn't it be a disaster recovery option in case one is unable to spin up another XO instance?
-
Why you wouldn't be able to deploy another XOA? It's meant to be re-deployed anytime you lose it, because even a fresh one can access a backup repo and restore everything.