We have been using CR at work for over a year now and it is working great. There is no point of using the DR-feature since it is way slower and doesnt support incremental backups.

To answer @Pechkin000 original question: If you build yourself from the sources you get the LATEST. The appliance is build from the exact same sources, but is then tested for a while before it is realeased.

At work we're using the appliance, at home I am using "from sources" and to be honest I havent had any issues with my "from sources"-version.
All tho, if you are running an enterprise-shop you should really really know what you are doing if you decide to go with the "from sources"-version since this is pretty much untested.

I dont understand why @mropen is being so dramatic - Did you have any issues with the "from sources"-version?

@S-Pam Having a VIF for management and one for storage-traffic is a good solution, we do it that way to avoid crippling management during backups.

@olivierlambert said in 10GB backup with XOA (XCP to windows NFS):

First thing on the calendar will be to use the XO proxy code in threads directly in XOA for "normal" backups. It will allow more XOA usage and we'll see if it helps (at least it will help to scale).

Sounds like a step in the right direction, any ETA?

@olivierlambert said in 10GB backup with XOA (XCP to windows NFS):

We'll get rid of potential stream buffer limitation in a relatively short time frame, but again, I'm pretty sure the export speed on the host is the real bottleneck.

As we are also working on XCP-ng storage performance in parallel, I'm confident we'll be able to improve that

I think the storage performance-improvements will contribute to increasing the export-storage as well as working on the XAPI export/import performance.
I know the XCP team is aware of this issue and I am also confident that it will be a priority

We see about the same speed, just below 1Gbit/s no matter how many concurrent backups and what not. The bursting is probably due to buffering in the node-process.

I think this is a limitation in XAPI just like @olivierlambert wrote earlier and nothing much you can do in XO to speed it up.

We've been trying to speed things up for a long time, we ended up using the Delta-backup and Continious Replication which are both incremental. This allows us to backup all our VM's over night to our NFS-machines.

Did anyone try the performance of VM export/import yet?
I am really excited to see the increase since this was one of the improvements mentioned by Citrix.

Did anyone try VM export/import to see how much the performance has been improved?
More interesting would be if someone tried it with 10G or making backups with XOA.

@akurzawa said in Extrlemy slow backup speec = about few MB/s:

@nikade said in Extrlemy slow backup speec = about few MB/s:

Maybe you saw the same thing I did - I also had major issues with backups. Then in the summer of 2019 I upgraded our XOA (Yes, we have the paid version) and everything was going 3-4x times faster. Must have been some major improvement in the XOA code.

So maybe some official info that if you have XO from source Your backup speeds will be as low as 3-4 MB/s? Or what?

Sorry if I was unclear - XOA is built from the same sources so there is no difference in that aspect.
All tho, there was a big performance issue regarding backups which was resolved.

I am using XO from sources in my "private" infrastructure and I can assure you there are no "limits" on purpose.

@synologic said in Extrlemy slow backup speec = about few MB/s:

Ok, upgrading to the latest version worked. Thank you.

I see some improvements in the backup speed like:

• from xcp 8.1 - no compression - about 33 MiB/s
• from xcp 8.1 - compression (zstd) about 15 MiB/s

both are up from about 4 MiB/s

However, i am also seeing vast improvements when backing up from XCP 8.0.0 with transfer speeds (as reported by iptraf-ng) going up to 700 Mbps, which was not happening before.

Viorel

Maybe you saw the same thing I did - I also had major issues with backups. Then in the summer of 2019 I upgraded our XOA (Yes, we have the paid version) and everything was going 3-4x times faster. Must have been some major improvement in the XOA code.

Hi,

I've been struggling with this for many years and I havent found any solution yet.
Our setup is not exactly like yours, but it is simular.

We have 10st XenServer's with 2x10Gb each in 2 different pools, the SR's are located on a NFS share over 4x10Gb and benchmarks from within a VM gives 450-600MB/s in both read and write so I know that is not the limiting factor.
XOA runs in Pool A, so the physical host that it runs on has 2x10Gb NIC.

The backup NFS are 2 different FreeNAS machines with 2x1Gbit nic in each, running a VM from there and running a disk-benchmark gives me around 100-110MB/s per NFS share, in total around ~200MB/s which is fine.

When we backup we backup about 100 VM's to the 2 NFS shares, Pool A backups to NFS Backup A and Pool B backups to NFS Backup B and no matter what we do the network seems to be limited to 800Mbit/s.
If we backup a single VM it goes up to 800Mbit/s, if we backup 4 at the same time it is still limited to 800Mbit/s, since all traffic passes through XOA I am under the understanding that this must be a limitation in XOA or the XAPI-mechanism used by XOA to export the VM's.

Are you using XO from sources?
If yes, this XO will run inside a regular VM and therefor I'd say yes, you can put this script into crontab.

If you are using the XOA appliance I wouldnt recommend it just due to the fact that they could blame it incase anything goes wrong

We have been using CR at work for over a year now and it is working great. There is no point of using the DR-feature since it is way slower and doesnt support incremental backups.