Skip to main content
  • EN

Hi,

A newbie here with using Veeam for Oracle RMAN backups.

I am trying to understand/visualize whether the RMAN retention and Veeam Immutability are independent of each other or are they related in some way.

We run our backups on the Oracle DB server using shell scripts and cron and using a RMAN catalog.

We have set  CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 35 days.

We do RMAN delete obsolete as well.

The Veeam Immutability is 7 days.

Does Veeam delete the backup files if they are 7 days old or does it delete the files if RMAN fails to delete them after 35 days? Or does Veeam do nothing unless we uses the force-delete?

Kinda hoping someone has a presentation of some sort to show how this works. Have read thru the documentation and can’t find any that explains this. Or maybe it is explained more clearly/visually in any Veeam documentation and I just can’t find it.

Any reply will be much appreciated. Thanks in advice.

 

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… ;)

Terms & ConditionsAccessibility statement