Even with a sfc and cleanup, manually reinstalling the package caused the same behavior. I've got backups of this system and will build a template from the working backup for if it goes sideways.
If nothing will help and you can't import xva with import VM, I have solution.
Deploy new VM with disk x4 times greater than backup file. OS Ubuntu 16.04 or later.
Copy backup. Take attention. You need always copy backup. Do not move it.
Install xva-img https://github.com/eriklax/xva-img
add-apt-repository ppa:ubuntu-toolchain-r/test && apt-get update && apt-get install -y gcc-7
cd to xva-img dir and run next command
cmake ./
make install
Extract xva file
tar -xf my-virtual-machine.xva -C my-virtual-machine
chmod -R 755 my-virtual-machine
In folder my-virtual-machine you will find some directory like Ref :1, but maybe with another number. Remember this number.
Create raw disk from extracted. Replace 1 with number from previous step.
xva-img -p disk-export my-virtual-machine/Ref\:1/ disk.raw
Install qemu-utils
apt install qemu-utils
Convert raw to vhd
qemu-img convert -f raw -O vpc disk.raw [vhd-name-you-like].vhd
Copy vhd to some SR. I'm using local SRs, so in my case path is /var/run/sr-mount/[sr-uuid]
Go to the host, cd to SR folder, get VHD uuid, rename VHD
cd /var/run/sr-mount/[sr-uuid]
vhd-util read -p -n [vhd-name-you-like_from-step-8].vhd
mv [vhd-name-you-like_from-step-8].vhd [uuid].vhd
Rescan SR
Attach VHD to existing VM or deploy new one
Get you files
wow. I am getting on with this in parallel. Thank you again! Results for both suggestions and requests are coming!
@hannes Full backup interval (and Force full backup in the schedule settings) forces the job to do a full export of the disk and not a delta based on a previous one.
It is not impacted by the retention as XO will always makes sure every chain has at least a full export at the beginning so that all backups are viable.
Which means you will have multiple full backups, always one at the beginning, and, those that have been triggered by the settings above.
You should probably be able to fix this issue by installing the ntfs-3g package.
As you mentioned you're running it on a Synology, you can do that in DSM by opening Docker -> Container -> Select your container -> Details -> Terminal and enter the below in the console.
I did for sure. But I noticed that a new commit(886ff2cd7) was made literally in about the last hour and after updating again to that version all is good!
@olivierlambert i have created config.httpInactivityTimeout.toml in /opt/xen-orchestra/packages/xo-server with the content from above. Not sure how i can check if thats actually set.
BTW: this is not a CR Backup Problem, i also dont see Tasks running for my "normal" Backup Job. I cant check "how far" the actual Backup runs and if that differs.
Since the update I have run full backup that have taken over an hour to complete due to their size and many smaller delta backups and the error has not come up again. I assume whatever was causing the error was fixed in the xo-server 5.84.2 update.