PBS with slow backend

[andreisrr]

We are considering a potential offsite backup via the internet using PBS, as a secondary backup.
The actual storage is mountable via SSHFS (via fuse), expected throughput would go somewhere between 1 and 5Mbps with RTT between 10 and 50ms.
Aside from an initial backup which obviously takes a huge time, for data that changes very little, like several MB to several hundred MB a day, would using PBS be viable, much better then the rsync they use today, especially from the point of view of how much metadata must be exchanged over the connection to determine what has changed and needs to be copied to the backup?

 

[J-Rod]

What filesystems and block sizes are used by the PVE host and VM?

From what I've seen with using PBS sync over a 10Mbit/sec link, it's never quite as efficient as hoped.

Maybe you could set up a test PBS instance on-site first so you could count the data transferred?

 

[kawano-y]

Just to make sure I understand the setup correctly: are you planning to use an SSHFS-mounted directory as the PBS datastore, rather than running a PBS instance at the remote site with local storage attached?

 

[AlexHK]

I know this doesn't answer the question directly, but to overcome this I have setup a local PBS to which I backup my machines locally.

From this local PBS I sync to a remote PBS instance. This offsite PBS is behind a slow connection (VPN over cable modem with limited upload speed).

The sync happens via built-in PBS sync.

https://pbs.proxmox.com/docs/managing-remotes.html

 

[SteveITS]

I’ve used remote PBS sync on relatively low speed links, though not that slow, and it’s been fine.

There is a setting in the sync job for the number of backups per VM to sync e.g. 1.

IIRC we did find putting CODEL shaping on that connection in pfSense boosted speeds.

 

[J-Rod]

Reducing the number of recent backups to sync will help, but also not as much as you would hope. As I understand it, even if you only sync the very last backup, that backup is small at the source only because it's storing changes from the backup right before it. But to send that last backup to the remote site, you have to send all the other blocks that have changed. You won't have multiple copies of the same block, as you would with multiple backups, but you'll still have a lot of blocks sent over in order to get "caught up" so to speak.

I am running a remote sync once a day right at the end of the work day, and the daily changes are approximately 5% of the total data stored. These are very basic VMs with not a lot of activity. From my tests, if I sync all of the hourly backups for a 24 hour period, it takes about 2.5 hours, and to back up just the most recent backup takes about 1.5 hours. So it's hardly worth missing out on all those extra recovery points.

 

[SteveITS]

The limit would sync 1 backup so can be used to get one of each VM offsite quicker…vs 25 backups of VM1.

 

[IsThisThingOn]

would using PBS be viable, much better then the rsync they use today, especially from the point of view of how much metadata must be exchanged over the connection to determine what has changed and needs to be copied to the backup?

Depends.
Rsync should be pretty good at batching metadata over slow networks. AFAIK the bottlneck should be the storage metadata performance.
PBS on the other hand reads ALL you lokal data, and creates a hash. So you lokal storage and CPU performance could be a bottleneck.

ZFS send would probably give you the best performance. For that you need ZFS on both ends.