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

@olivierlambert Client is a proxmox shop and whilst tolerating services running in XCP-ng / XO world they require that if everything fails they have the ability to pick up the pieces in-house. Proxmox has easy import of .ova but very manual process for .xva hence....

Hi! Thanks for the feedback. Can you be more specific? This might be helpful if others would have the same issue Thanks!

still having initial issue, even on latest XOA or XO CE

Great job, worked perfectly! Thank you very much for your fast support!

@Pilow error reporting is a feature in itself . Thanks

@Pilow I will take a look in deep later, but the key/delta and disk usage is set during backup, even if they are merged during LTR retention

@Bastien-Nollet Great, thanks!

@Forza you will have to switch to LATEST to profit from end month release STABLE is one version behind LATEST both are production ready.

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

I hope someone will reply to my post here about how to check status on this but I believe I've resolved the main issue: I disabled and re-enabled the whole task itself yesterday and it ran this morning as scheduled.

@henri9813 yes thank you for correcting my message

I confirm that this is the current behaviour, as @pilow reported here https://xcp-ng.org/forum/post/99446 We might change it in the future to make it better, but it won't be trivial to change.

@MajorP93 aha, yea. Per disk concurrency is important too.

Adding @florent and/or @Bastien-Nollet in the loop

Adding @gregoire in the loop

I will tell you a little secret, you taught me more than that one command for CLI lol One more important note for my Bitwarden Thanks again bud!