@olivierlambert whoops! Well spotted 🙂 Will post in the real one 🙂

The easiest solution is to change the destination CR for the replication, so it will start from scratch. I'm not sure you'll be able to move the whole chain like this (or maybe somehow manually but it will be tedious). I would go personally for a new SR target and start clean there.

@olivierlambert No problem at all, it was my pleasure. I hope it helps other having the issue.

@olivierlambert @florent thank you for the suggestions.
So far I have attempted to do the following:

Remote backup to NFS Remote backup to NFS target which is connected to another storage server using iSCSI Move the VM from one SR to another (on a completely different pool) Copy the VM to another pool

Unfortunately, my VM size is not reducing.

@florent said in Backup size larger than it should be:

thin mode doesn't allocate space that is not needed. But once allocated, they stays there.

This looks like an answer to me.
In the worst-case scenario, I will have to recreate the VM and copy the data onto it

Yeah! 😎 Problem solved then!

@ColBod XO source is the development version. If you have a full version of XOA then keep using it...XOA has support.

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 :
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

hi @ricky222

the structure of the backup repository is documented here https://github.com/vatesfr/xen-orchestra/tree/master/%40xen-orchestra/backups/docs/VM backups .

Checking if a backup is done/running can be done with the XO rest api from https://xen-orchestra.com/docs/restapi.html

You can go confidently with rsync/rclone for the full backups ( the xva files ). For restoration you can even use the import VM function of XO or xo-cli to directly import the xva. If you rsync data back from rsync to a local backup repository, you must delete the local cache.json.gsz to ensure XO see the downloaded backup (xva + hash + json)

The caveat is for the incremental backup and the merging. In XO we are merging older incremental backups, that means modifying older files. This process is offloaded to another node process which does not appear for now in the api. Making a transfer during a merge may lead to an invalid backup on target.

Do you have enough informations ? Also, it could be great if you share your setup when you have a working/tested setup with rsync

Regards

@olivierlambert Checking the storage where the delta backups are, I find 13 copies, and I have a retention of 7 configured.

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.