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.

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.

@akurzawa I think the stats looks fine to be honest. Maybe there is something with the TCP offloading but I have no experience from that.
Please share if you manage to find anything that speeds up the performance.

@kevdog said in HTTP to HTTPS redirection:

@nikade Hey thanks for for the link. I ended up just using a LetsEncrypt cert rather than self signed. I think had to add a DNS host override on my router to associate the Local LAN address of the xo server with the domain name of the server contained in the certificate -- Like 10.0.1.50 ---> xo.example.com. Thanks for pointing me in the right direction on this one.

Yeah that is a good solution as well, I hope this helps others in the future who wants to secure their XO with https

To be honest there is a lot of "magic" stuff happening during the handling of disks. I've noticed as well there there might be activity on the sources-server before the destination-server even reacts.

I guess you'd have to read the code to be able to give a certain answer to that question - All tho I wouldnt suprise me if there is some snapshotting and stuff going on on the source-server.

Are you using 7200k disks by any chance? The increase going to 10k or even 15k sas-drives is incredible and I know that XS/XCP is really picky when it comes to I/O.
Even our machines at work that has PERC H710p controllers with 1Gb cache and SSD-drives seems slow at times....

Oh I see, sorry for reading a bit too fast @akurzawa
I dont use the Disaster-recovery myself, we use Continous-replication because we want it to be incremental.

Is tapdisk reaching 100% on both hosts or only on the sender?

I have been running Windows 10 and Windows Server 2016 now for a long time on xcp-ng.
last weekend I upgraded one of my test-servers to xcp-ng 8.0 and Windows Server 2016 still runs fine.
This is the output of systeminfo

C:\Windows\system32>systeminfo

Host Name:                 HEL-DC1
OS Name:                   Microsoft Windows Server 2016 Standard
OS Version:                10.0.14393 N/A Build 14393
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Primary Domain Controller
OS Build Type:             Multiprocessor Free
Registered Owner:          Windows User
Registered Organization:
Product ID:                00377-60000-00000-AA934
Original Install Date:     2018-10-20, 17:26:33
System Boot Time:          2019-10-01, 23:13:37
System Manufacturer:       Xen
System Model:              HVM domU
System Type:               x64-based PC
Processor(s):              1 Processor(s) Installed.
                           [01]: Intel64 Family 6 Model 158 Stepping 9 GenuineIntel ~3600 Mhz
BIOS Version:              Xen 4.7.5-5.4.1.xcp, 2018-08-02

I am using these tools:

@kevdog said in HTTP to HTTPS redirection:

I'm just curious on using this --- do you have a SSL cert with the server name and are you accessing XO through an address like: https://xoserver.example.com? I'm just curious since my XO server is located at 10.0.1.11 and Chrome states cert is invalid -- since I believe SSL needs to resolve to hostnames and not IP addresses.

I have generated a self-signed certificate which I am using to reach my XOA. You can do this very easily by using the "openssl"-tool.
https://www.linux.com/tutorials/creating-self-signed-ssl-certificates-apache-linux/ explains how to create both they cert and key-files that you need.

It would be interesting if you could try the DR-copy to another remote-machine just to see if tapdisk is as busy.
I noted that it is having a rather high % in the busy-column, around 90%, which would indicate that there's a bottleneck somewhere.

Did you try any other backup-type to a remote nfs for example?

Thanks for the output. Is this "top" running while you are doing a DR? I dont see any processes related to copying vdi's or even sparse_dd.