Backup sync performance over VPN

[broth-itk]

Attached the current version of the code. It has been extensively tested and fine-tuned.
Backups, which have been transmitted with that method have been successfully restored.

This code might not be perfect but it suits my needs and it doubles my sync performance.

Now, the root cause is still under investigation. Once fixed it will render the script useless.

In the meantime I'm happy with BBS, buffer tuning and the helper script ^_^

 

[santi23]

Hi.
I have a problem with the Backup running over VPN, every time I run the backup, the VM stopped and that affects the performance and that VM can't be stopped.

 

[broth-itk]

Hi.
I have a problem with the Backup running over VPN, every time I run the backup, the VM stopped and that affects the performance and that VM can't be stopped.

This has nothing to do with my initial report but I'll be happy to help: Is fleecing active? If not, enable it. I expect that the VM is not stopped anymore (or is having I/O errors).

 

[_gabriel]

Fleecing mitigates, but the recommended and safest is local BPS backup then Sync over WAN/VPN.
Fleecing from the docs :
When a backup for a VM is started, QEMU will install a "copy-before-write" filter in its block layer.
This filter ensures that upon new guest writes, old data still needed for the backup is sent to the backup target first.
The guest write blocks until this operation is finished so guest IO to not-yet-backed-up sectors will be limited by the speed of the backup target.
With backup fleecing, such old data is cached in a fleecing image rather than sent directly to the backup target.
This can help guest IO performance and even prevent hangs in certain scenarios, at the cost of requiring more storage space.