Restore Veeam plug-in backups from object storage in DR case

Setting the stage

With Veeam Backup & Replication v11 you now can offload Veeam Enterprise Plug-In backups (SAP HANA, Oracle RMAN or Oracle SAP Backint) to your SOBR Capacity Extent.

So setting the stage:

• You’re running VBR v11
• You’re backing up using one of the Veeam Enterprise Plug-Ins to a SOBR
• The SOBR’s Capacity Extent has the Copy policy enabled, so newly created backups are directly transferred to the object storage (when using just the move policy the restore will work the same – but only from older backups of course)

Now let’s assume a DR case when you lost all your Performance Tiers and environment and you only have the object storage left to restore from. So you start off with a fresh installation of VBR on some server and you have your DB system running again but you want to have the latest application backups restored now. I’ll use Oracle RMAN backups in this example, but the procedure will be the same for the others.

Requirements

For image level backups on an object storage you can start restores directly after adding an object storage repository and importing it. However, this does not work with the application backups. You’ll need a SOBR to which you can attach your object storage as Capacity Tier.

• Create a simple repository which can be used as a SOBR Performance Extent – it will just store the cached meta-data, so there are no high requirements for capacity or speed.
• Create your object storage repository with the bucket where your application backups are located

Preparing VBR

Now let’s create a new SOBR with the simple repository as Performance Extent and the object storage repository as Capacity Tier.

Important: Do not tick the copy or move policies here unless you really want to continue putting backups to this capacity extent – as soon as you attach your DB systems you might start getting backups in (e.g. logs from HANA) which might break your backup-chain (or at least make restores much more complicated).
You can even seal your object storage extent to make sure there will be not backups put to it.

When adding the Capacity Tier VBR will automatically detect that there are already some backups in the SOBR and of course you want to import them.

Depending on the amount of backups the import/synchronization process might take some time. Note that in this phase only the meta-data copies are pulled down from the object storage and put to your local Performance Extent.

When the resync finished you can find your application backup meta-data in your Performance Extent:

In VBR you will now see the your application backups popping up n the “Object Storage (Imported)” section:

Remember to modify the access permissions for the newly created SOBR so that the user you’ll use in the plug-in configuration later can access the repository.

Configuring the application side

Now let’s go down to the application. Install the respective Veeam Enterprise Plug-In on your system if you didn’t do that already and configure it to point to your new VBR server and the newly created SOBR.

Running the plug-in wizard you might notice the following message if you’re not accessing the repository with the same user as you did the backups. If that’s the case ensure now that the user has either the Backup Administrator or the Backup & Restore Operator roles before you agree to proceed.

Please ensure the following roles are assigned to the user in Users and Roles settings on the backup server:
Backup Administrator, or
Backup Operator and Restore Operator

Alternatively, select a backup repository that does not have existing application backups created from this server under another user account.

Proceed anyway? (y/n):

The rest of the plug-in configuration runs as usual.

In the next step you must map the application backups to the newly registered system. For this run the Config Tool with the --map-backup parameter – with this running successful you will see that the backups in the VBR console moved from “Object Storage (Imported)” to “Object Storage”:

And that’s it – you’re done with the setup and can start restoring now.

Running restores

After mapping the backups you’re all set for restores. Whether the backups are on the Performance or the Capacity Tier of a SOBR is transparent for the restoring application.

For Oracle RMAN backups you now also have the ability to use the Veeam Explorer for Oracle to restore, but of course you can also use the native applications like RMAN or HANA Cockpit.

In RMAN for example you now can run a crosscheck to verify if the backups are available:

RMAN> crosscheck backup;

using target database control file instead of recovery catalog
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=38 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Veeam Plug-in for Oracle RMAN
allocated channel: ORA_SBT_TAPE_2
channel ORA_SBT_TAPE_2: SID=285 device type=SBT_TAPE
channel ORA_SBT_TAPE_2: Veeam Plug-in for Oracle RMAN
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=58 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=273 device type=DISK
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=d5f2ed52-f565-47d5-8b24-70aff5870a3e/RMAN_2827497104_ORCLCDB_20210309_c2vpacl9_1_1.vab RECID=176 STAMP=1066742441
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=d5f2ed52-f565-47d5-8b24-70aff5870a3e/RMAN_2827497104_ORCLCDB_20210309_c1vpacl9_1_1.vab RECID=177 STAMP=1066742441
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=d5f2ed52-f565-47d5-8b24-70aff5870a3e/RMAN_2827497104_ORCLCDB_20210309_c3vpacm2_1_1.vab RECID=178 STAMP=1066742466
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=d5f2ed52-f565-47d5-8b24-70aff5870a3e/RMAN_2827497104_ORCLCDB_20210309_c4vpacm2_1_1.vab RECID=179 STAMP=1066742466
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=d5f2ed52-f565-47d5-8b24-70aff5870a3e/RMAN_2827497104_ORCLCDB_20210309_c5vpacmh_1_1.vab RECID=180 STAMP=1066742481
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=d5f2ed52-f565-47d5-8b24-70aff5870a3e/RMAN_2827497104_ORCLCDB_20210309_c6vpacmi_1_1.vab RECID=181 STAMP=1066742482
Crosschecked 3 objects

crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-2827497104-20210309-00_RMAN_AUTOBACKUP.vab RECID=182 STAMP=1066742497
Crosschecked 4 objects

With all the backups available you can start a restore. When the session is running you can see that all the data will be pulled directly from your object storage repository (130.117.252.10 is Wasabi in my case and 192.168.17.31 is the application system).

Note that these restores will not download the data to the Performance Extent before restoring. This will be piped directly from the Capacity Tier to the target system. That means if you want to restore multiple times the same backup you’ll always have to download it. To prevent this you can of course before doing the restore download the backups to the Performance Tier from the VBR console

Summary

As you can see restoring with Veeam from object storage in a DR case is very easy and straightforward. When you’re testing this make sure not add backups to the capacity tier when you’re failing it over to your DR installation so that you can work with a consistent state of backups.