RMAN Backup Copy target

[ferrus]

One of the features of v12 we were looking forward to, was the direct backup to object storage, without requiring a SOBR.
While we are looking to move more of our backup copies to object storage - the only one we currently have is our RMAN backups, of Oracle DBs currently hosted on physical Linux servers.
The jobs were designed this way - as prior to v12 only object storage gave immutability for RMAN backups.

I tried setting up a new bucket/repository for testing, following the v12 upgrade - but it doesn't appear in the list of target repositories, for an RMAN job.

Is this a restriction for 'Application Backup' jobs (the only restriction mentioned in the online guide is Cloud Connect repositories), or a issue with the way I've configured the job?

[PetrM]

Hello,

Application plug-ins including RMAN cannot write directly to object storage, it's one of the main feature requests for our future versions. You can enable the Capacity Tier for your SOBR to offload or copy RMAN backups to object storage. This limitation applies to both standalone plug-in backup jobs and application backup policies.

Thanks!

[ferrus]

Thanks.
From testing it looks as though we can't combine Application Backup policies and standalone backup jobs.

Our Oracle DBA prefers the control over keeping the standalone backup jobs. I'm just making sure that we're not missing out on any important features.
Do RMAN backups created through Application Backup policies enable fast-cloning on the target repo?
I know this was always a limitation of the standalone RMAN client, as Veeam didn't have control over the backup.
I'm not sure whether it's still seen as an external backup with Application Backup policies - just with extra visibility, or if they bring the data under Veeam control for the block cloning feature.

[PetrM]

Hello,

From a technical perspective, the policy is a tool for orchestration on top of the already existing standalone jobs with enhanced monitoring and greater flexibility, because it supports different settings for individual databases. Long story short, the policy triggers standalone jobs on schedule and these standalone jobs produce backups, therefore similarly to standalone backups, there is no fast clone for backups created with the policy.

Thanks!