@Danp said in Running a Backup Job for a Pool that wasn't previously in said backup job: @DustinB said in Running a Backup Job for a Pool that wasn't previously in said backup job: Are you suggesting for just this run I remove the old pool from this section and rerun the job? Yes. Making those changes now and running the job. Thanks for confirming

@DustinB Yes

I am running the latest XO. I ended up fixing the issue, it has backed up successfully 2 times now without any errors. What I did was removed ALL snapshots for the specific VM. Once the tasks finished for removing the snapshots, I created a new manual snapshot. Then let the backup happen as normal. What I noticed though is the backup snapshot replaced my manual snapshot so the VM still only has 1 snapshot. But it seems to be working now.

@olivierlambert said in XO (from source): backup error (to Wasabi): If you need another trial, no problem. To me, the problem is not in XOA (the broken commit was done after the monthly release) and fixed today, so it means it would be never shipped in XOA. Then I am fine, building XO from Sources provides me with the ability to backup my VMs, which was the only XOA "Feature" I was using... Thanks anyway!!!

According to Microsoft you need to use their built in backup feature or a software that supports AD and VSS which will tell the VM OS that it is going to be backed up. Unless you do this there might be corruption of the AD Databases according to Microsoft. ALL THO we've been backing up our AD servers with XOA snapshots (Both normal backup and incremental) and had only 1 issue since we started using XOA in 2016. Since that issue we also use a guest agent (From Ahsay CBS) that makes a Windows System State backup and Windows System Backup. More info about that can be found here: https://wiki.ahsay.com/doku.php?id=public:version_9:client:9447_system_state_backup_vs_system_backup

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. I've got other stuff to handle.

Are these issues resolved with a Full backup? Just curious as to how they might come about, and what the implications are. Thanks again

I have opened a ticket to support because file level restore doesn't work anymore after latest update. Best regards Walter

@felipefonsecabh You need to check the specific checkbox: https://xen-orchestra.com/docs/full_backups.html#backup-without-snapshot

@splastunov said in File restore not finding any option: 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. apk update apk add ntfs-3g Let us know if it helped.

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. https://github.com/vatesfr/xen-orchestra/pull/6315 Rajaa-BARHTAOUI opened this pull request in vatesfr/xen-orchestra closed fix(xo-web/tasks): tasks with no bound objects not displayed #6315

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.

Sure, please keep us posted on your experiments If it's a bug, we'll have more info to be able to work on it!

Posted this as I personally found this configuration quite involved, and the permissions earlier in the thread were insufficient to make it work when using AWS KMS for bucket encryption as well as the XO provided encryption secret.

Answered on the XO forum, thank you