Since you are able to reproduce consistently the issue, it might be interesting to get more logs/debug to find the root cause ๐ Pinging @dthenot and all relevant people that could help in here ๐
@manilx P.S. Seem like the slow backup speed WAS related to the EPYC bug as I suggested a while ago.....
Should have tested this "workaround" a LONG time ago ๐
No I mean the file level restore feature from XO. If it all worked, I'm curious to understand why you had this issue in the first place. Did you restore the entire chain?
We had to restore the entire VM as a new instance from Xen Orchestra using the delta backup. However, the same error occurred with each restore point. So, we manually copied the backup files from XOA and imported them.
@Ascar In XO cloud means pool, "hamburger" means host. If VM is running, it belongs to host where it runs, and receives host icon, no matter where it is kept in stopped state. If VM is stopped, it belongs to pool if kept on pool shared storage (cloud icon), or to host, if on host's local storage (hamburger).
Well, changing time on the NFS server could have an impact, since file access time attributes are used to do many checks in general. I'm not saying that's 100% the issue, but it tells how deep a small change could cause havoc.
@Chemikant784 I haven't had time to check this, I don't even remember where I put the 2025 eval, but I'll get to it soon. If I put the eval on my VMware system, then I'll likely try it sooner and remember to put it on my XCP-NG system too.