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
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.
Once this is configured, we can check and see if our mount is working.
[root@swingbench2 tmp]# ls /BlobFuse
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
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:
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:
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
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.