PBS inside PVE

[arieljlira]

Hi,
I would like to ask for some advice in order to have a more reliable (but still low budget) backup approach for two PVE hosts in a public state university.

PVE hosts are A and B, both independent/not clustered, enterprise servers with hardware raid cards with bbu. They don't use ZFS.

Backups are crossed between them, meaning host A has scheduled local vzdumps and daily rsyncs to host B. The same in host B, copied to host A. In the coming months it will get access to SAN disks through an HBA but not for now.

1) What do you think about installing PBS in host A to handle B backups, and another PBS in B to keep A backups?. This way I would get some benefits of PBS (deduplication, compression, incremental vm backups, etc).
2) Can PBS be used this way?
3) Does PBS require ZFS storage?

I know a third server dedicated for backups would be the best, but it is not an option right now due to budget limitation. The only thing I can add right now is a slow external NFS for offsite copies.

Thanks you very much for any guidance.
Regards

 

[fabian]

1) What do you think about installing PBS in host A to handle B backups, and another PBS in B to keep A backups?. This way I would get some benefits of PBS (deduplication, compression, incremental vm backups, etc).

you can do that, but keep in mind that PBS needs some resources as well (memory, CPU, network bandwith). probably more than just a plain NFS export/rsync via SSH

2) Can PBS be used this way?

yes. you can also backup A->A and then sync A->B, and backup B->B and sync B->A (or even do the initial backup crossover, and then sync back, but that doubles the load on the network obviously).

3) Does PBS require ZFS storage?

no. ZFS with spinning disks and NVME special vdevs is a good way to get lots of space with fast metadata access, but there is no requirement to use any specific file system as the underlying storage.

 

[arieljlira]

Hi Fabian,

you can do that, but keep in mind that PBS needs some resources as well (memory, CPU, network bandwith). probably more than just a plain NFS export/rsync via SSH

yes, we should test more. Our biggest limitation is storage space right now.

you can also backup A->A and then sync A->B, and backup B->B and sync B->A (or even do the initial backup crossover, and then sync back, but that doubles the load on the network obviously).

Great. With "sync A->B" are you referring to sync jobs to pbs remotes ( https://pbs.proxmox.com/docs/managing-remotes.html#sync-jobs ) o just to plain old rsync/mirroring jobs?

if pve@A->pbs@A and then sync pbs@A->pbs@B, the it should be at least 3 copies of all each CT right? I thinks it is similar to what we have now, with the benefit of incremental CT/VM backups and may use less storage because we only have full vzdumps now.

I'll read more about remotes and test how PBS work along PVE.

Thanks a lot!
Regards

 

[fabian]

ool

Hi Fabian,

yes, we should test more. Our biggest limitation is storage space right now.


Great. With "sync A->B" are you referring to sync jobs to pbs remotes ( https://pbs.proxmox.com/docs/managing-remotes.html#sync-jobs ) o just to plain old rsync/mirroring jobs?

the former (sync jobs).

if pve@A->pbs@A and then sync pbs@A->pbs@B, the it should be at least 3 copies of all each CT right? I thinks it is similar to what we have now, with the benefit of incremental CT/VM backups and may use less storage because we only have full vzdumps now.

yes, you have the original data on A, the backups on A, and the backups on B. note that original data on A and backup on A only count as two if they are on separate storage (and even then, some people might not count that since they share motherboard/.. as source of failure that could easily fry both copies at once).