Hello,
you might want to read the chapter on ransomware protection of the PBS manual:
https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery
In my opinion it's always better to have one local and one remote backup. A local one for fast restore and a remote one so you still have your data in case your local data is lost beyond repair. This also ensures that your backup strategy conforms to the 3-2-1 rule: You should have at least three copies of your data (one production plus two backups) , two of them on different storage media (so not the same disc or server!) and one of them offsite.
Obviouvsly your network will be the main bottleneck for the actual backup but that's not the whole story: PBS also will need to run verify and garbage collection jobs from time to time (e.G. daily or weekly) for two reasons:
- To verify, that the data is still consistent, readable and restorable (you will still want to do a manual restore test from time to time, but this automation is a good foundation)
- To remove any data not needed anymore
For this the choice of storage media is quote important since both operations needs huge IOPS which HDDs simply don't have. The reason is that PBS splits all data in a lot of small files (called "chunks"). The actual backup snapshots don't store the data, instead they have references to the chunks. If no snapshot references a chunk anymore that chunk can be removed to free some disc space which is done by the garbage collection jobs.
To illustrate this here is an excerpt from a recent garbage collection job on my PBS:
2025-05-27T02:00:21+02:00: Original data usage: 64.77 TiB
2025-05-27T02:00:21+02:00: On-Disk usage: 273.444 GiB (0.41%)
2025-05-27T02:00:21+02:00: On-Disk chunks: 248819
2025-05-27T02:00:21+02:00: Deduplication factor: 242.55
2025-05-27T02:00:21+02:00: Average chunk size: 1.125 MiB
So my backups would need 64,77 TiB if I want to restore everything (which I don't since they also include the older copies), thanks to the storage as chunks they only need 273,44 GiB and are split on 248819 small files. This space saving has a cost though: Any garbage collection job needs to check the metadata of every chunk file to see whether they were referenced in a backup snapshot in the last 24 hours. Only if they are not referenced in a snapshot for more than 24 hours and five minutes they will be removed. And the verify job will need to not only read the metadata but also the actual data. As one can imagine this is quite slow on classical HDDs since their rotor head need to move around the whole time.
With other words: A HDD only datastore will need a long time for the garbage collection or verify jobs, in this forum people reported durations of 10 hours and more (depending on the amount of data). ZFS has a nice feature though to mitigate this: If you add SDDs as metadata cache ("special device") to your HDD pool the metadata of any new file will be saved on the HDD. Thus any operation accessing the metadata (like most operations of the garbage collection job) will perform a lot better than with a plain HDD ZFS pool:
https://pve.proxmox.com/wiki/ZFS_on_Linux#sysadmin_zfs_special_device
This has some caveats though:
- The redundancy of the special device should match the redundancy of the HDDs, meaning that if you have two HDDs in a mirror for your datastore your special device should be a mirror of two SSDs. If you have a RAIDZ-ZFS-pool with three HDDs, your special device should consist of three SSDs etc.
- The capacity of the SSDs should be around 2% of the HDDs (this is a rule of thumb from several forum discussions here and on the TrueNAS forum, the recommendations ranged from 0,02 % to 2%)
- If the special device gets (for whatever reason) broken, you also loose everything in your HDD pool
Another thing to consider: ZFS RAIDZ is better for data safety (more redundancy, you have more random discs which might fail) but a striped mirror (ZFS jargon for RAID10) is way better for performance and IOPS (which are as said quite important for PBS).
So I would have a local small PBS with SSDs and a relative short retention policy for fast local restores and one large remote PBS as long-time-backup/archive with a ZFS striped mirror con HDDs with four SSDs as special device and a long term retention policy.
In terms of deduplication: As far I know a sync job will always check first, whther the chunks to be synced are already present on the target datastore. So the local PBS should do most of the deduplication. This assumes of course that you use sync jobs (recommended!) instead of configuring one backup job per PBS (not recommended!)
Personally I would use a pull sync job. It allows you to setup the remote PBS that any sync from your local PBS will only allow adding new data but not altering or removing any data which is a good strategy in terms of ransomware protection:
https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery
Even better you could create a firewall rule that your local PBS can be accessed by the remote PBS (to pull-sync backups from the local PBS to the remote one) but not vice versa. So even if your whole local infrastructure is taken over by a bad actor he won't be able to do any harm to your remote PBS.
So after you wiped your complete local infrastructure you could temporary enable access to the remote pbs to restore and rebuild everything.
Hope this helps
