Sanity check - clone offsite or duplicate backup?

Y

yatesco

Renowned Member
Sep 25, 2009
230
10
83
Hi, I have a local PBS server (in a CT on Proxmox) and an offsite one. If I merely "sync" them then any bug in the onsite PBS is replicated to the offsite one and I've lost the resilience of the 3-2-1 strategy. OTOH, backing up separately to the local one and remote one seems really inefficient, and opens the doors to more complexity (https://forum.proxmox.com/threads/concurrent-backups.162680/).

What do you all do?
 
I have
  1. Primary hardware/baremetal SSD PBS systems doing backup.
  2. Secondary virtual PBS syncs from that and provides capacity storage and acts as the sync hub.
  3. Geographically remote secondary virtual PBS syncs with that.

I don't understand your point about the bugs.
There can in fact be corrupt data in PBS, and it doesn't fix itself well, and yes that corruption can sync. (They've just applied some fixes for some of this.)

How is this different from say Veeam, where you have a Forever Forward scenario? Or really any scenario with a root backup and incrementals?
If your root backup or any incremental along the way is damaged, you can't restore.
Just like PBS.

GIGO is definitely a thing. But all forms of backup/restore suffer from it.
 
Last edited:
  • Like
Reactions: yatesco and Johannes S
the point about bugs is simply that bugs happen, and the more you replicate the more the window of opportunity for that bug to propagate. Three separate backups _might_ be better than one backup replicated two times. Then again, it might not. I'm just interested in what people are doing :-)

I'm tempted to do one proxmox backup + offsite sync and one zfs send/recv.
 
  • Like
Reactions: tcabernoch and Johannes S
if you want two different sync-like parts of the code that hopefully don't share too many bugs, you can consider the tape feature as another way to replicate for long term storage. the problem with manually syncing the datastore is that unless you are very aware of the internals of PBS (now and for any future changes), your copy will be inconsistent unless the datastore is completely quiet during the sync with no ongoing operations whatsoever.
 
  • Like
Reactions: yatesco and Johannes S
My current thinking is (wrt to the infamous 3-2-1):
- I've fat fingered a CT/VM: PBS for hourly/daily backups stored locally
- the dog peed on the server and fused the drives: separate PBS backups to another server in my (garden) office
- my house and garden office get destroyed: deduplicating (kopia, restic, Borg) file based backup of ZFS volumes offsite (S3, Hetzner, back blaze etc.)

I might also run ZFS snapshots (sanoid) and offsite those (zfs send/receive/syncoid) just because they are so cool ;-).

The *big* issue I see with ZFS snapshots and subsequent file based backups is that I can't flush the guests. Snapshotting ZFS is awesome, but if the guest CT/VM is part sync then oops. But I'm sure a little script which flushes then pauses all VMs/CTs, snapshots ZFS, unpauses all VMs/CTs would be doable.

I'm *definitely* overthinking this, but hey, that's part of the fun ;-)
 
  • Like
Reactions: Johannes S
Yes. You are overthinking it.
If you want two different formats, they are sitting there ready for you.

It doesn't really say this, but the output of a backup job depends on the storage type.
  • If you backup to PBS, the data goes into the mysterious PBS dedupe filepart-database-storage thing called .chunks.
    • From here you can sync to another site for that aspect of your 321. (Meaning the target is another PBS server linked via the PBS Remote feature, using a PBS Sync Job.)
    • You can also output to tape from PBS to get another data medium for your 321.
  • If you backup to a NAS, the backup becomes a tar gzipped file that you can then transfer anywhere else you like.
    • These are standalone backups, suitable for old-skool data replication methods to other sites or mediums.
 
Last edited:
tcabernoch said:
  • If you output to PBS, the data goes into the mysterious PBS dedupe filepart-database-storage thing called .chunks.
    • From here you can sync to another site for that aspect of your 321.
    • You can also output to tape from here, to get another data medium for your 321.
Click to expand...

This works until it doesn't:
https://forum.proxmox.com/threads/datastore-synced-with-rclone-broken.154709/

I wouldn't use anything than PBS native sync function for that reason. It's a pity really, because a native support for something like rclone would also offer the benefit to have native cloud backups for PBS which would be another reason people might switch from Veeam or other "Enterprise-grade" software to PVE and PBS.
 
  • Like
Reactions: yatesco and tcabernoch
You must log in or register to reply here.
Top Bottom