If your target is a SR (and NOT a BR), then what you do is not called "Backup" in XO, but Replication (full or incremental). Target -> Backup mode: SR -> Replication (you can use it with retention to have a kind of backup too) BR (Backup Repository or "remote") -> Backup Both can be full or incremental. Note: you CAN'T and shouldn't use a host as a BR. A BR must be any NFS/SMB/S3 capable operating system, as long it's not XCP-ng.

Please try to reproduce the issue first, we won't change the code behavior on assumptions

Hi, This error means you have an issue to reach the backup repository. Check you can access this share from your XO VM.

This is precisely why we did that feature in Xen API Enjoy!

@KPS Hi, that is some nice performance, I guess the hardware under is beefy++ Did you try if NBD increase the speed ? You need to enable NBD on the backup network, and then enable it in the delta backup : [image: 1699624343030-f556d425-d66f-41b5-bf8b-c6c769fdbcb5-image.png] We have a few tasks in the pipeline to increase performance, leveraging our knowledge of both XCP and XO Florent

@olivierlambert said in No back available to restore: Then make sure your backup repository is correctly connected. Bingo. All my backblaze credential seem to have disappeared

@momofhlp I suspect it is a UID/GID mapping or permissions problem. Mount the share manually no-root-squash. run a backup on that share. see what UID/GID xo expects you to use. Then set up an nfsshare for only that matching UID/GID and all should be good. it is easiest to set it up wrong security wise with NFSv3 but easiest to make it work. Once it works, go back and switch to nfs4.1. read and weep. https://www.truenas.com/community/threads/nfs-sys-security-option.86501/ old nfs (v3) has little or no security. nfs4,1 has SYS for slightly better security. NFS4.2 + kerb5 has best security but a learning curve like: | | | | only much much steeper. a better nfs security solution is nfs via stunnel see: https://www.linuxjournal.com/content/encrypting-nfsv4-stunnel-tls https://bobcares.com/blog/nfsv4-encryption-with-stunnel-tls/ historical: https://www.stunnel.org/mailman3/hyperkitty/list/stunnel-users@stunnel.org/thread/7FVHLCPSDHL2S6KQ7DBN24HLPSX4SHWV/ other implementation details https://github.com/chadgeary/tls_nfs/tree/master/playbook another imp. https://forge.puppet.com/modules/simp/nfs/readme I should turn this info into a package for xcp-ng.

Some time ago I read "ZFS - the billion dollar file system" and the more time I spend with it, the more I think that's true

@Anonabhar The NAUbackup script goes in order of a list of VMs, so I can imagine it'd be easy to implement this if not already present in XCP-ng. Worst case, separate those big VMs out into a separate backup instance and offset it adequately from when the other backups run.

@techjeff Unfortunately, I do not have direct experience with that tool. I would hope it would have some way of independently staggering the startup times when they kick off. If there is no other option, requesting a way to deal with this as an added feature seems like the best recourse.

Our official doc is the right place https://xen-orchestra.com/docs/installation.html#from-the-sources

@olivierlambert Checking the storage where the delta backups are, I find 13 copies, and I have a retention of 7 configured. [image: 1694801941149-235b1aae-b8f9-4f3c-b732-b6a79977628a-image.png]

Up to date? What's your commit number? Also, the issue is not due to Xen Orchestra, but when XO is trying to ask for a snapshot or your VM (Async.VM.snapshot). This VM has a disk which is not usable because likely connected to another host which is shutdown or not there.

Sounds like a familiar topic Pinging @julien-f

Dear @CJ, We have added an article in our documentation that explains why full exports sometimes happen unexpectedly. You can find this article on this page. I hope it clarifies, do not hesitate to tell us your opinion!

Yeah this is relatively normal, it's using 2MiB blocks so there are going to be a lot of requests when you are doing this with large VMs or data. Are these a ton of VMs or a few larger ones? If the later, might be worth moving that data to a NAS of some kinda, TrueNAS or whatever, and have the NAS handle the backup of it so that the VMs remain light and nimble. Of course that only works IF you can do that.

Good news then

You do not enable NBD in your VM, you enable NBD on a XCP-ng network, that's it. There's no drawback to enable it (well, it's a new service exposed but it's OK)

@Gheppy I would have done those operation, if i wouldn't loose connection to xcp-ng. I got only 1 IP address which is dedicated to pfsense, and from there i connect to xcp-ng (LAN side).

Hi, sorry for the long break. i'll continue here for my colleague AlexD2006. We have now also tried with the current version (deeb3) of Xen-Orchestra, the problem remains the same. But we have now noticed other error messages (also with the old version) that appear during a delta backup ("base VDI is not a vhd; cannot compute differences"): May 23 16:40:35 xcp-mono02 xapi: [error||7644621 HTTPS 10.32.1.159->:::80|[XO] Exporting content of VDI test-vm.test 1 R:2e892fda7776|vhd_tool_wrapper] base VDI is not a vhd; cannot compute differences May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] [XO] Exporting content of VDI test-vm.test 1 R:2e892fda7776 failed with exception (Failure "base VDI is not a vhd; cannot compute differences") May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] Raised (Failure "base VDI is not a vhd; cannot compute differences") May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 1/14 xapi Raised at file stdlib.ml, line 29 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 2/14 xapi Called from file ocaml/xapi/vhd_tool_wrapper.ml, line 206 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 3/14 xapi Called from file ocaml/xapi/export_raw_vdi.ml, line 50 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 4/14 xapi Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 24 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 5/14 xapi Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 35 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 6/14 xapi Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 24 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 7/14 xapi Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 35 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 8/14 xapi Called from file ocaml/xapi/export_raw_vdi.ml, line 90 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 9/14 xapi Called from file ocaml/xapi/export_raw_vdi.ml, line 116 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 10/14 xapi Called from file ocaml/xapi/server_helpers.ml, line 101 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 11/14 xapi Called from file ocaml/xapi/server_helpers.ml, line 122 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 12/14 xapi Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 24 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 13/14 xapi Called from file string.ml, line 115 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 14/14 xapi Called from file src/sexp.ml, line 113 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] Can anyone say anything about the cause of the problem or any ideas for further analysis?