Azure BlobFuse for Oracle RMAN Backups

Operationalizing an Oracle database on Azure IaaS includes setting up an RMAN backup schedule much like the backup patterns used on premises. This is is important because despite whatever media you might have as a primary storage mode – it can fail. A backup destination based on a different tech stack is required for true recoverability in this case. A cost effective scenario would be a combination of near online  RMAN backups in the Silk-based ASM Diskgroup +FRA and an ‘offsite’ or rather off platform/region standby and/or backup plan.  This gives both good recovery time objective (RTO) and high durability (MAA). DBA best practices dictate that you have multiple copies of the data—on different media — a BlobFuse backup destination checks this box.

Azure provides a very powerful open source-based feature for its IaaS Linux based VM’s. It is called BlobFuse for Azure.

With BlobFuse for Azure installed on your Linux VM, Blob storage can be presented to a Linux-based VM as a file system. Why is Blob storage of interest to the Oracle DBA? It is cheap, plentiful, sturdy, and remote storage for archival backup. 500 Terabytes of Azure GRS Blob storage is around $2300/month list price. This will give you great redundancy and durability to supplement the near online backups that would be utilized for most restore events except the most grievous. Ideally, you’ll never want to have to go to your ‘off site’ RMAN backups but having them can be a career and even company saving long term strategy. Stuff breaks –sometimes quite badly.

Oracle OCI approaches provisioning this type of storage differently. They have created a special SBT type driver that masquerades their Blob storage as an RMAN tape device – another driver/library to support. With Azure BlobFuse, the RMAN target device type remains disk. To this humble DBA, it seems a simpler, more maintainable backup software stack can be achieved with BlobFuse. You can maintain BlobFuse while SBT tape library driver management is a manual process.

BlobFuse is installed via the RPM Utility for the Fedora/RedHat/OEL branch of Linux. A number of dependencies need to be installed first. Here is an example for a Fedora based Linux install:

First, these library dependencies have to be pre-installed:

sudo yum install git cmake fuse-devel libcurl-devel gcc gcc-c++ gnutls-devel libgcrypt-devel libuuid-devel boost-devel fuse -y

And then the actual RPM for BlobFuse:

rpm -i BlobFuse-1.4.3-RHEL-7.8-x86_64.rpm

warning: BlobFuse-1.4.3-RHEL-7.8-x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID be1229cf: NOKEY

Confirm installation:

yum install BlobFuse fuse

Loaded plugins: langpacks, ulninfo

Package matching BlobFuse-1.4.1-1.el8.x86_64 already installed. Checking for update.

Package fuse-2.9.4-1.0.9.el7.x86_64 already installed and latest version

(Your particular RPMs and versions will vary based on the Linux flavor and version.)

Once installed a command like the following below ephemerally mounts the container as a file system. I’ve pre- created the directory/mount point  /mnt/BlobFusetemp:

BlobFuse   /BlobFuse  –tmp-path=/mnt/BlobFusetmp -o attr_timeout=240 -o entry_timeout=240 -o negative_timeout=120 –config-file=./connection.cfg –log-level=LOG_DEBUG –file-cache-timeout-in-seconds=120.

Here are the contents of the connection.cfg file. This has account and security specific information in it.

Connection.cfg:

accountName bjltest

authType SAS

sasToken sp=racwdlmeop&st=2022-05-25T15:25:56Z&se=2022-05-25T23:25:56Z&spr=https&sv=2020-08-04&sr=c&sig=XAXL4i7urPOv0KNSBhII8bGmtp4wNsW4B9tPZ9Wn4PQ%3D

containerName bjltest

Once this is configured, we can check and see if our mount is working.

touch /BlobFuse/foo

[root@swingbench2 tmp]# ls /BlobFuse

foo

Now we can persist this mount through reboots by configuring the following in /etc/fstab:

BlobFuse /BlobFuse fuse delay_connect,defaults,_netdev,–tmp-path=/home/azureuser/tmppath,–config-file=/home/oracle/connection.cfg,–log-level=LOG_DEBUG,allow_other 0 0

This script will run each time as fstab is evaluated during boot or mount commands.

We can now configure RMAN to use Blob storage via this file system we have created to interface to it. Again, in RMAN our device type will be DISK not SBT. This is very straightforward as the default target type is disk.

RMAN> connect target /

connected to target database: SWING1 (DBID=1694798414)

RMAN> show all

2> ;

using target database control file instead of recovery catalog

RMAN configuration parameters for database with db_unique_name SWING1 are:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

CONFIGURE BACKUP OPTIMIZATION OFF; # default

CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default

CONFIGURE CONTROLFILE AUTOBACKUP ON; # default

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’; # default

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE MAXSETSIZE TO UNLIMITED; # default

CONFIGURE ENCRYPTION FOR DATABASE OFF; # default

CONFIGURE ENCRYPTION ALGORITHM ‘AES128’; # default

CONFIGURE COMPRESSION ALGORITHM ‘BASIC’ AS OF RELEASE ‘DEFAULT’ OPTIMIZE FOR LOAD TRUE ; # default

CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘/u01/app/oracle/product/19.0.0/dbhome_1/dbs/snapcf_SWING1.f’; # default

We next set the RMAN default device type to DISK (in this case, it already was).

….

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK;

new RMAN configuration parameters:

CONFIGURE DEFAULT DEVICE TYPE TO DISK;

new RMAN configuration parameters are successfully stored

Then we specify our target format and destination:

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/mnt/BlobFusetmp/%U’;

new RMAN configuration parameters:

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   ‘/mnt/BlobFusetmp/%U’;

new RMAN configuration parameters are successfully stored

Here we have set the device type disk to place files on the /mnt/BlobFuse filesystem and to include time/data stamp information (%U).

Now we can execute an Oracle backup to Azure Blob storage via RMAN.

Here is the simplest of all RMAN backups:

backup database;

Starting backup at 25-MAY-22

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=10735 device type=DISK

channel ORA_DISK_1: starting full datafile backup set

channel ORA_DISK_1: specifying datafile(s) in backup set

input datafile file number=00003 name=/oradata1/swing1/undo_01.dbf

input datafile file number=00001 name=/oradata1/swing1/system1.dbf

input datafile file number=00002 name=/oradata1/swing1/sysaux1.dbf

input datafile file number=00004 name=/oradata1/swing1/user01.dbf

channel ORA_DISK_1: starting piece 1 at 25-MAY-22

channel ORA_DISK_1: finished piece 1 at 25-MAY-22

piece handle=/mnt/BlobFusetmp/010ude7o_1_1 tag=TAG20220525T180752 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

Finished backup at 25-MAY-22

Starting Control File Autobackup at 25-MAY-22

piece handle=/u01/app/oracle/product/19.0.0/dbhome_1/dbs/c-1694798414-20220525-00 comment=NONE

Finished Control File Autobackup at 25-MAY-22

Here are the files on the BLOB mount point:

df

Filesystem      1K-blocks     Used  Available Use% Mounted on

devtmpfs          8122612        0    8122612   0% /dev

tmpfs             8133424        0    8133424   0% /dev/shm

tmpfs             8133424     9340    8124084   1% /run

tmpfs             8133424        0    8133424   0% /sys/fs/cgroup

/dev/sda2        30431232 23108940    5709396  81% /

/dev/sda1          508588   244212     264376  49% /boot

/dev/sda15         506608     7664     498944   2% /boot/efi

/dev/sdb1        77275908  2150432   71177036   3% /mnt/resource

tmpfs             1626688        0    1626688   0% /run/user/54321

tmpfs            16777216   710960   16066256   5% /mnt/BlobFusetmp

/dev/sdc1      2113645484  5833748 2000421224   1% /oradata1

[oracle@swingbench2 dbs]$ cd /mnt/BlobFusetmp/

[oracle@swingbench2 BlobFusetmp]$ ls -lrt

total 710960

drwxrwx—. 2 root   root            40 May 25 15:35 root

-rw-r—–. 1 oracle asmadmin 728023040 May 25 18:07 010ude7o_1_1

So that is how (relatively) easy it is to utilize Azure Blob storage for RMAN based Oracle backups. Once BlobFuse is configured the familiar RMAN interface and features take over. Having an out of region backup for true disaster recovery (DR) is a real necessity for any mission critical app. This architecture provides a cost-effective means to do so.

The idea is to have your near online backups and archive log files on the very fast, capable Silk Cloud Platform. Ideally there will be two different Silk Data Pods for supporting a DataGuard installation. The suspenders to the belt is the Azure Blob storage that gets your backed up data to another system and geographic region.

It is great to have a backup of your database available on durable media remote from your primary site. This is an ideal, cost-effective way to get your data into an Azure multi-region resiliency mode for cheap money. An ideal “belt and suspenders” solution, though, would provision a third Oracle server to serve as the second standby cascading out of the first. The first would be in synchronous mode and the standby would span into another availability zone. Active DataGuard would be used for some reporting and — most key — the backup would take place from this server. Ideally an asynchronous DataGuard configuration would cascade off this first standby and be located in another Azure region. There are however significant costs associated with that. The RMAN backup to regionally replicated object storage is significantly less costly and gives a good degree of durability. The cost of recovery time RTO will be higher but day to day operating costs much less.

Click here to learn more about how Silk can give your Oracle workloads on Azure the performance they need.