Process a second backup, or sync the first?

[lukyjay]

Hi

With one PVE instance and two PBS servers I would like to understand the best way to great backups. I've included my assumptions below each one.

1. Backup PVE to the first PBS server, then sync that backup to the second PBS server
   • Pro: Less downtime on PVE guests
   • Pro: Less resources needed from PVE host
   • Pro: Less bandwidth since the sync job transfers less data (I think?)
   • Con: Failed or corrupt backup (e.g. one that fails verification) will have those issues sync (although rare)
2. Backup PVE to both PBS servers (two backup jobs)
   • Pro / Con: Inverse of the above
   • Con: Not viable for an off-site backup (I think?)

Is the above correct? I assume sync jobs are the way to go given failures are rare and they're more efficient.

Thank you
J

 

[hd--]

Hello
i'd recommend using one pbs for the back-up jobs but not replicate the backups, but instead sync them to the second pbs.
PBS has a feature called Sync Jobs [0] which i'd use in the scenario your described.

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

 

[lukyjay]

Hello
i'd recommend using one pbs for the back-up jobs but not replicate the backups, but instead sync them to the second pbs.
PBS has a feature called Sync Jobs [0] which i'd use in the scenario your described.

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

Sorry! Sync is what I meant to say (not replicate). I will edit my post

 

[hd--]

Less bandwidth since the sync job transfers less data (I think?)

Less bandwidth is required for the communication between the host and first pbs, but additional bandwidth is required for the sync between the two pbs servers.

Not viable for an off-site backup (I think?)

could also be viable for an off-site backup (e.g. with one of the two pbs off-site) but personally i'd prefer the use of the sync job feature and also because of the advantages you mentioned

 

[lukyjay]

Less bandwidth is required for the communication between the host and first pbs, but additional bandwidth is required for the sync between the two pbs servers.


could also be viable for an off-site backup (e.g. with one of the two pbs off-site) but personally i'd prefer the use of the sync job feature and also because of the advantages you mentioned

Hey @hd-- sorry I just had a thought on reducing bandwidth. I know that you shouldn't backup to the same machine (i.e. PBS should be on a different machine to PVE) but wouldn't it be faster if I backed up to PBS on the same machine as PVE, then synced that to a PBS install on a different machine? Is there any reason that you can think of where it wouldn't make sense?

 

[Mad Scientist]

IMO, I would opt for your second option. The reason being if the first backup somehow became corrupted, the first option would carry the corrupted data to the second backup.

 

[hd--]

Hey @hd-- sorry I just had a thought on reducing bandwidth. I know that you shouldn't backup to the same machine (i.e. PBS should be on a different machine to PVE) but wouldn't it be faster if I backed up to PBS on the same machine as PVE, then synced that to a PBS install on a different machine? Is there any reason that you can think of where it wouldn't make sense?

If there's only one pve-node than i don't think it would be such a huge problem to have both pve and pbs on one machine - if there is also another pbs of-site. The pbs on the same machine would enable super fast backup-restores and if the system crashes there are still of-site backups to rebuild the system.
if you have a cluster, that is of course a completely different matter .

 

[_gabriel]

backup to two pbs server break the super fast backup "dirty map".
sync is the best and the recommended.

 

[mow]

Less bandwidth is required for the communication between the host and first pbs, but additional bandwidth is required for the sync between the two pbs servers.

Sure, but the two pbs have it easier to determine which chunks are missing and wouldn't need to upload so many blocks just for the receiving pbs to discard them.