@Danp I'll do some more digging on this once I have some time and see if I can find anything in the logs. I didn't have a chance to look yesterday when I was working on this.
It might be worth noting that I was trying to setup an S3 remote, not sure if it would happen with another one and maybe it has something to do with timing out (was trying to hook into Backblaze which doesn't seem to be working right either, works fine on all my other machines running TrueNAS and stuff but can't get it connected with XCP-ng, other S3 places like Wasabi and Amazon work fine though).
I'll update this thread with more info once I do some more testing, might have time this weekend but not sure yet, and this is in a production environment, so I do want to be careful about causing potential issues.
There's no compression on delta, because we need to merge them on destination, when retention is reached (inside the backup repository). So it doesn't really worth it (since you'll have to decompress them to do the merge).
Hello, mtill ! In this situation, you may try to recover the stored data on the RAM because, in your case, the data was overwritten in the RAM. The number of recovered files by this method depends on the RAM size, the size of files that was overwritten by this way and by the time running this process. I can suggest you use a specialized recovery service like raid recovery service to ensure that you will restore more data you can. I wish you a bit of good luck.
No, there is no way to enable HA at XO level and it is on purpose. Enabling HA as to be taken very seriously, it can cause pool wide crippling issues so we considerer doing it through CLI and be aware of what you really do being mandatory.