Question about retention and pruning

[markf1301]

Environment - 2 servers at production. 1 is PVE and the other is PVE/PBR.
Remote site has pve/pbr on it. It is configured to connect to production office and pull backups from that store.

The dr side (prune job) is configured as such -



All works in this solution as I have different numbers of backups at the production side. For example - server 101 has a backup set for 5 days, and server 200 has a job scheduled for 30 days.

question about retention at production and dr side.
I have need to keep different number of backups at the production, then at the DR site. This seems to be working - so far. The issue is that at the DR side, some backups are needed for a shorter time than others, and I don't seem to be able to create multiple prune jobs - for specific devices because the 'max depth', I believe is referring to all my backups. For example - if i am replicating 40 servers but only need to keep data/backups for 5 of those servers - for 10 days, and not 30 days I don't seem to be able to do this.
Is this possible and I just don't know how to do it?

thanks in advance,
mark

 

[Chris]

I have need to keep different number of backups at the production, then at the DR site. This seems to be working - so far. The issue is that at the DR side, some backups are needed for a shorter time than others, and I don't seem to be able to create multiple prune jobs - for specific devices because the 'max depth', I believe is referring to all my backups. For example - if i am replicating 40 servers but only need to keep data/backups for 5 of those servers - for 10 days, and not 30 days I don't seem to be able to do this.
Is this possible and I just don't know how to do it?

Hi,
the setting max-depth is related to namespaces, not the snapshots directly. So if you require different retention settings for a subset of your snapshots, namespaces are what you need, see https://pbs.proxmox.com/docs/storage.html#backup-namespaces
You would then sync the snapshots to different namespaces (by different sync jobs with filter if needed) and can then setup different prune jobs for individual namespaces, adapting the retention settings to your needs. Here the max-depth comes into play, as it tells you how deep the job will look into nested namespaces.

 

[markf1301]

Ok - I'll look into it.
Quick question - If I already have backups for my servers, and I create new jobs to support the namespaces - does that mean that I am duplicating the backups both locally, and then remotely until I have the retention level that I need? For example, I have a server called - 101 which is part of the global list of backups and I have 20 copies of that backup. If I create a new 'namespaces' job and do 10 backups for it does that mean that I now have 30 copies of that server both locally, and remote until I create the different prune jobs to 'clear' out the data not needed any more?

 

[Chris]

Ok - I'll look into it.
Quick question - If I already have backups for my servers, and I create new jobs to support the namespaces - does that mean that I am duplicating the backups both locally, and then remotely until I have the retention level that I need? For example, I have a server called - 101 which is part of the global list of backups and I have 20 copies of that backup. If I create a new 'namespaces' job and do 10 backups for it does that mean that I now have 30 copies of that server both locally, and remote until I create the different prune jobs to 'clear' out the data not needed any more?

Well, this is a bit more subtle: If you already have 20 snapshots, and add new 10 snapshots in a sub-namespace on the same datastore, then yes you will have 30 snapshots in total (as long as there is no prune job on PBS side or retention policy on PVE side removing snapshots). All these snapshots would however use the same underlying chunk store, therefore de-duplicating also the new snapshots, which the PVE side however is not aware of for the first run in the new namespace. It would therefore reupload all chunks, then de-duplicating them server side.

You could however use a local sync job to move the already per-existing snapshots into the new namespace.