10GB backup with XOA (XCP to windows NFS)
-
I explained that here: https://xcp-ng.org/forum/post/28832
-
Do you know where i can find some data about HTTP handler on XCP/Xenserver? How much GB can be fetch in the handler?
-
Hi,
i opened this ticket because our datacenter has 67 VM and right now we take 20 Hours to make a full backup.
We need to fast it up a lot.
The differential backup need 5 hours to backup 350GB. -
I think it's likely the bottleneck, and except disabling HTTPS, there's no magical rule. You can play with concurrency in XO to see if it's better.
Also, it's not a "ticket" you opened, but a thread on a community forum, where people can answer on their free time.
-
Sorry, i know this isn't a ticket, i meant the question here on the forum.
and we write this thread because we cannot find a solution anywhere for our issue/question to speed up the backup.
We are making a lot of test right now, but we are not going better in anyway and we found a lot of limits in XOA/XCP-ng and Xen server 7.1 CU2 to, we are a bit worried about this issue with the backup. -
Note that you can scale up with concurrency (see https://xen-orchestra.com/docs/backups.html#backup-concurrency).
Also, if you have different pools, you could use XOA Proxies (alternatively, multiple XO from sources but it's less elegant) so you can accumulate all pool speed to get to a decent global speed.
-
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.
-
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 confirm what @nikade say. Even if i use a 10Gb and set the concurrent backup to 10, the speed will be always the same.
If we use proxy XOA or similar idea i think we can speed the backup but not to a point we would like.
We usually make a differential backup, but for us (67 VM = 300 GB transfer and 300 GB merged - diff backup, XOA take from 4 to 6 Hours). -
I'm confident we can improve this for you before the end of the year
@julien-f is working hard on that! -
@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 -
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).
-
@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?
-
With summer in the middle, hard to tell. But I have the feeling end of Q3 is doable
At least in a specific release channel -
I hope it's fine for you @julien-f
-
That sounds feasible indeed
