Hi @Ed4232 -
According to the Veeam RMAN Plugin Guide, the files retention is associated with what is configured for the Veeam Repository:
https://helpcenter.veeam.com/docs/backup/plugins/repos_rman.html?ver=120#hardened-repository
NOTE:
“Backup files in the hardened repository become immutable for the time period specified in the backup repository settings. During this period, backup files stored in the repository cannot be modified or deleted.”
Let me know if you have further questions.
This page here explains how retention and immutability work together for backups - How Immutability Works - User Guide for VMware vSphere
Hi @Ed4232
If I understood correctly with RMAN script you save dumps and archive logs in a share.
Share is backupped with Veeam with 35 days retention.
Immutability is set to 7 days.
When you apply immutability, you need to calculate the retention using the rule on the help center page.
Actual retention = job retention policy + immutability period + Block Generation period
Veeam remove backup files after 35 days.
By the way you can see some examples into my article
immutable backup means, how long backup cannot be deleted from repository by any mechanism
retention means how long they will stay on repository
to be sure how long they will stay, you can use as mentioned (OracleRMANConfigTool --set-force-delete)
only if you will set longer immutable period (40days) then force delete (35days), then they will stay longer (40 days)
Hi @Ed4232 -
Do you still have questions about how Immutability retention works? Are you backing up to a standard Veeam Repo or Object Repo, because that’ll play a part in retention. Let us know if you still have questions.
Best.
Yeah, still have a lot of questions, that’s with an s :-). I wish I manage the Veeam Repo but I don’t. I backup to what they tell is a SOBR = StandAlone Backup Repository? And they have a lot of old files there that we can’t see anymore in the RMAN catalog so if we can’t see them we can’t do a delete of them using Oracle RMAN even if we used force-delete. And some of the backup files we can’t relate to which databases they belong to because the names are not the same names that we see as the backup pieces in the RMAN catalog, the only way to check is to open the metadata file and check from there :(. I really wish I can find a sandpit to test RMAN backup retention and Veeam immutability for free :-)
i have same issue, when customer is complaining that is paying too much :)
so i log into repository server and each server has dedicated directory, so as customer set for delete, i am able to read from job retention and then delete manually old “orphaned” file.
From my statistic i have such issue with around 40 from 100 plugins.
To me it seems, that some things get mixed up here in the thread. 🤓
We have to differentiate a few things as @Marcel.K already pointed out.
With plugin backups, the retention is under full control of the plugin. This has nothing to do with immutability, which is controlled by the repository (e.g. VHR).
Plugin backups can leverage immutability (since V12).
https://helpcenter.veeam.com/docs/backup/plugins/sap_repos.html?ver=120#hardened-repository
Immutability does not delete anything. It just prevents a deletion (by e.g. a ransomware). A difference with plugin immutability is, that it is being set 24h after the backup was created only. So, we’re not immutable right away. It will be removed, once the immutability period is over again.
Therefore, make sure to set your retention to be longer than your immutability. Otherwise, the plugin will try do delete backups because of the retention settings an fail with a warning.
Now for the retention: As being said, retention is controlled by only the plugin. If it is an unmanaged job, this would be your self-created RMAN script only. No way to influence that from within VBR.
For a managed job, you can control it from within VBR, but still, the retention will just remotely be set within RMAN. RMAN is still the one applying the retention.
https://helpcenter.veeam.com/docs/backup/plugins/overview_operation_modes.html?ver=120
As Veeam knows, that this process fails every once in a while, we on top have the option (!) to set a force-delete.
https://helpcenter.veeam.com/docs/backup/plugins/force_delete_rman.html?ver=120
This also is a setting that is implied from the workload side - but now the plugin itself and not the backup tool (RMAN, backint, etc.) above. This makes sure, to delete files if your retention within RMAN (or whatever other supported plugin) fails or is misconfigured. Keep in mind, that you will delete files with force-delete that might still be in the RMAN catalog. So, if you try to restore those, an error will be thrown.
I always advise customers to set a force-delete within the plugin.
Make sure to have Immutability < Retention < Force-Delete to have a happy backup life… ;)
@Ed4232 - just wanted to follow up and see if you were able to get an answer from this thread? If so please mark the best answer or if you figured it out post the answer then mark that one as the best answer.
