AssertionError [ERR_ASSERTION]: footer1 !== footer2

justjosh

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: '=='
  }
}

olivierlambert

Hi,

I'm not sure to understand what you expect by just posting an error log without any context like this

justjosh

@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..

olivierlambert

Context is king: XO source or XOA? Which version?

justjosh

@olivierlambert Neither. A ubuntu VM with backups-cli installed via npm install --global @xen-orchestra/backups-cli

olivierlambert

Hmm I'm not sure we provide anything supported directly via npm. Pinging @julien-f

justjosh

@olivierlambert Shouldn't it be a disaster recovery option in case one is unable to spin up another XO instance?

olivierlambert

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.