Disk replication for DRBD over a slow network, or another solution?

Good afternoon.

There are two servers connected by a slow network (100Mb/s or even worse, through the real Internet).
One of the servers - the main, from the second I want to do something like a "warm" replacement.

On the server, eventually, collected, concatenated in a clever system, and the spinning of different virtual machines on which users are working around the clock, but at night - very little, and sometimes nothing at all.

Virtualcom sliced logical volumes from LVM, LVM stacked on the original partition size, say 2 TB.
I want to make sure that this section is regularly copied to the backup server "as is", with all data and metadata LVM inside.

The logical solution was presented by DRBD. Was opened the resource on the primary server it is declared to be Primary, backup - Secondary. In the event of a failure of the server it is supposed to just include backing, to declare it a Primary partition and run all new path.

Technically it worked, but the problem was the network - it's slow. In the test example, 100Mbit/s, in reality it will be 30-50. All changes are written to the Primary partition, try online to Vasilisa on Secondary. As a result, IO speed of entry to Primary drops to 11MB/s, and latency is also too high. For a moment, the underlying physical disks - SSD, which will take 500MB/s, but here - 11.
And one of virtuallock - base 1S, which need a high write speed. With 11 MB/s it just won't move.

I would have made a variant in which a Primary would take users data with the speed of the disk subsystem, and the Secondary they would be transferred to the extent possible. For example, if times in a day or two will meet the stars, and the sync will catch up with the current status of the disc will suit me. Volatile data is copied in a different way, the very valuable team of virtualos, and operating systems on them. To ensure consistency Secondary, DRBD is able to create snapshots between moments of complete synchronization (not yet tested, and in the config it is not).

I can, for example, to turn off the Secondary, and turn it on only at night. When the Secondary is disconnected, the recording speed is just excellent Primary, Secondary and then turns on and takes the difference. But then there is the low write speed of night, that will cause discomfort to users.

Like, 8.4, DRBD is able the deferred timing AHEAD/BEHIND, which allows the Primary to go forward, due to the temporary consistently Secondary. But I for the life of me - cannot configure. Still recording on the Primary is with the speed of the network and the device simultaneous separation in the AHEAD/BEHIND is not happening.

Help, please. I broke his head. What am I doing wrong?

Configuration test environment:

resource data {
 device /dev/drbd1;

 syncer {
 rate 80M;
}

 startup {
 wfc-timeout 10;
 degr-wfc-timeout 10;
}

 on XVMS0 { // then Primary
 address 192.168.0.248:7789;
 disk /dev/sdf;
 meta-disk /dev/vgaux/drbd_meta_sdf;
}

 on XVMS1 {
 address 192.168.0.249:7789;
 disk /dev/vgmain/drbd_test;
 meta-disk /dev/vgaux/drbd_meta_test;
}

 disk {
 al-extents 25600;
}

 net {
 protocol A;
 on-congestion pull-ahead;
 congestion-fill 10G;
 congestion-extents 100; // tried larger values, closer to al-extents.
 data-integrity-alg sha1;
}
}

May be there are other solutions, not DRBD?

I have my script for the differential synchronization block devices over the network. It perfectly would fit if the sync would need once a month. The problem is that it leads to the subtraction of the two devices that 2TB HDD unreasonably long time, almost 10 hours. I want the chips DRBD, which annotates recorded area to transfer the difference, but does not reveal her parallel reading of the two devices.

Thanks in advance.