Backup pves on pbs

[TErxleben]

How do I do that?
I have various VMs that are all backed up on a pbs. Now I would like to keep certain VMs for different lengths (prune&gc) of time, for example:
- servers last 30 days and maximum 6 months
- old, unused VMs maximum 2 versions
- Workstations 5 days
Where do I define these rules?
Directly on the PBS or on the PVE hosts?

 

[Dunuin]

You create different namespaces for your datastore and backup different types of VMs to different namespaces. Each namespace could have its own backup retention.

Or you work with different backup jobs for different VM types on the PVE and let PVE prune those VMs backup snapshots. Each backup job could have its own retention too and should work without namespaces.

 

[TErxleben]

You create different namespaces for youe datastore and backup different types of VMs to different namespaces. Each namespace could have its own backup retention.

Or you work with different backup jobs for different VM types on the PVE and let PVE prune those VMs backup snapshots. Each backup job could have its own retention too and should work without namespaces.

In the first case, I simply throw all the VMs of a PVE host onto the PBS. The PBS then takes care of storage etc. all by itself via namespaces?

In the second case, I define this on the PVE hosts and don't need a prune&gc schedule on the PBS?

Have I understood that correctly?

 

[Dunuin]

In the first case, I simply throw all the VMs of a PVE host onto the PBS. The PBS then takes care of storage etc. all by itself via namespaces?

You need to create a new PBS type storage in PVE for each namespace and then select which namespace should store the backups by choosing the correct PBS storage for each backup job. Also keep in mind that the dirty-bitmap will be dropped once you backup the same VM to different namespaces.

In the second case, I define this on the PVE hosts and don't need a prune&gc schedule on the PBS?

No prune on the PBS but you still need to run GC there.

 

[gfngfn256]

Have I understood that correctly?

Yes you've understood correctly. The only point that's inaccurate in your response is the second half of:

prune&gc schedule

"prune" is correct, since this is the action that removes older backups according to the retention policy, but "gc" (garbage collection) is something different, since its the action of removing the actual data blocks (from the PBS datastore), and it needs its own action/schedule to activate it on the PBS.

 

[TErxleben]

Yes you've understood correctly. The only point that's inaccurate in your response is the second half of:

"prune" is correct, since this is the action that removes older backups according to the retention policy, but "gc" (garbage collection) is something different, since its the action of removing the actual data blocks (from the PBS datastore), and it needs its own action/schedule to activate it on the PBS.

It's clear that prune is more like marking the sets to be deleted. GC then sweeps through (and takes a long time) and frees up the corresponding storage space. If I have enough storage space, I run a GC weekly or monthly.

So I miss the possibility on the pbs to define which VMs belong to a prune (&gc) job.

 

[TErxleben]

You need to create a new PBS type storage in PVE for each namespace and then select which namespace should store the backups by choosing the correct PBS storage for each backup job. Also keep in mind that the dirty-bitmap will be dropped once you backup the same VM to different namespaces.


No prune on the PBS but you still need to run GC there.

And how do I define on the pbs which VMs are affected in a prune&gc job?

 

[gfngfn256]

prune is more like marking the sets to be deleted

To be accurate prune removes the metadata/index and garbage collection removes the actual data/blocks

 

[TErxleben]

To be accurate prune removes the metadata/index and garbage collection removes the actual data/blocks

Just like deleting files in every filesystem.

 

[Dunuin]

So I miss the possibility on the pbs to define which VMs belong to a prune (&gc) job.

Again, that is what namespaces are for.

 

[gfngfn256]

Just like deleting files in every filesystem.

Similar but not "just like". With pruning its still using space in the datastore until garbage collection. On a "normal" (not every!) filesystem, after deletion, the file is really gone, that is the system is now completely unaware of it.
Anyway, I think were down to semantics now. Forget it!

 

[TErxleben]

Again, that is what namespaces are for.

Thank you for your clear statement. Without namespaces, my idea as described will not work.

 

[gfngfn256]

Without namespaces, my idea as described will not work.

No. As Dunuin pointed out, you could set up different Backup Jobs (On PVE datacenter) for different VMs, each with its OWN retention policy. You would then also choose a general GC schedule on the PBS.
I would actually go for this, as I think in the long run, it may be more granular to your needs, and possibly easier for you to to manage/understand.

 

[TErxleben]

No. As Dunuin pointed out, you could set up different Backup Jobs (On PVE datacenter) for different VMs, each with its OWN retention policy. You would then also choose a general GC schedule on the PBS.
I would actually go for this, as I think in the long run, it may be more granular to your needs, and possibly easier for you to to manage/understand.

So I define the retention on a pve host and push it including VMs to a pbs?
Is this information retained there?
prune&gc on the pbs are based on this?

I would wish...

But I'm a little confused.

 

[Dunuin]

Is this information retained there?

No. The PVE will then decide what backups to keep on a per job basis and will tell PBS "delete backup snapshot X,Y,Z of VM A,B,C". The PBS isn't then pruning anything on its own. PBS just frees up space of stuff that PVE deleted by running the GC.

I would actually go for this, as I think in the long run, it may be more granular to your needs, and possibly easier for you to to manage/understand.

Yes. But biggest downside with this is missing ransomware protection when a compromised PVE node is able to destroy all backups of its guests.
So from a security perspective I still prefer the namespace way...even if that means lots of storages spamming PVEs webUI and slower backups.

 

[gfngfn256]

I'll try and make it as simple as possible:

1. In PVE (Proxmox Host) you go to Datacenter (Left Pane) click on it, and choose from the main view (Right Pane) the Backup section.
2. Choose Add from the top to create a new Backup Job, and fill everything out, selecting which VMs CTs to backup, when to backup, storage to backup to (in your case PBS storage) and choose the retention policy for this backup (second tab from the left Retention). Click create when finished.
3. Do the above (2.) for every group you wish to create, with its OWN retention policy.
4. In the end you will have a list of Backup Jobs, which you can review/edit/add at your leisure.
5. On the PBS just setup a general GC schedule.

Thats it. Not complicated.

 

[gfngfn256]

Yes. But biggest downside with this is missing ransomware protection when a compromised PVE node is able to destroy all backups of its guests.

I'm not a world expert on compromised servers etc. But the PBS node itself could become compromised, through itself, or through a compromised PVE node that has access to the PBS?

 

[Dunuin]

But the PBS node itself could become compromised, through itself, or through a compromised PVE node that has access to the PBS?

Everything is possible. But my guess would be that it is much more likely that a PVE node gets compromized because of running all those different guests that might by accessible from the internet. Best case your PBS isn't public and with privileges set up so PVE nodes are only allowed to create backups and do restores but without any rights to delete/prune backups. And in case your PBS gets compromised you better have another PBS the backups gets synced to and even better additional backups exported to a tape library that is offline. See: https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery

And its not just ransomware...search this forum and see how many admins ask if there is any way to undo a prune because they accidentally deleted important backup snapshots

 

[TErxleben]

I'll try and make it as simple as possible:

1. In PVE (Proxmox Host) you go to Datacenter (Left Pane) click on it, and choose from the main view (Right Pane) the Backup section.
2. Choose Add from the top to create a new Backup Job, and fill everything out, selecting which VMs CTs to backup, when to backup, storage to backup to (in your case PBS storage) and choose the retention policy for this backup (second tab from the left Retention). Click create when finished.
3. Do the above (2.) for every group you wish to create, with its OWN retention policy.
4. In the end you will have a list of Backup Jobs, which you can review/edit/add at your leisure.
5. On the PBS just setup a general GC schedule.

Thats it. Not complicated.

That was my wish. Almost too good to be true. Your point 5, for example GC on the pbs every Sunday, does the definitions of the pves follow?
Unfortunately, I think I'll have to do the puzzle myself.
I would like to thank you in advance for your exchange of ideas and I am always happy to hear your further thoughts.

 

[gfngfn256]

Everything is possible. But my guess would be that it is much more likely that a PVE node gets compromized because of running all those different guests that might by accessible from the internet.

I think you make an excellent argument, for a fully hardened bare-metal PBS that doesn't host anything else. Just look out in the market - as to what's going on; cloud & elsewhere.
Thanks for your insight.