Oracle RMAN and Azure IaaS Oracle Backup
RMAN is a Oracle bundled enterprise backup utility.to make backups in most Oracle production environments. On premise RMAN is the ubiquitous tool often coupled with other hardware/software technologies such as Tivoli or Oracle Zero Data Loss Machine IN the cloud the backups are a often managed as part of the PaaS and SaaS services that use Oracle so it is either ‘’transparent’ to the user or a worrisome black hole to the support teams.
To insure both DR and local recoverability. In Azure object storage can be utilized for low cost backup in conjunction with high end I/O service on the +FRA being located in the SDP. Note that RMAN will run seamlessly with RMAN and in fact needs no special SBT tape library function. RMAN will see the Silk SDB based FRA as a Disk device. This greatly simplifies backup and recovery tasks.
Nonetheless unless multi region replication is used, some Blob storage should be presented as either an NFS or SMB based file system to RMAN. These will be in effect your ‘offsite backups’. Once again RMAN is configured as a disk device through the Azure filesystem/blob interface and is configured as an internal RMAN disk. As such no special RMAN libraries are required. Azure Blob storage can be mounted to Azure Linux VM’s using NFS v3.0 protocol or BlobFuse (Linux FUSE).
The steps to do so are below:
The Oracle RMAN syntax once the Azure blob file system is configured is this:
Identify the RMAN utilized file system mount point
df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 3.3G 0 3.3G 0% /dev
tmpfs 3.3G 0 3.3G 0% /dev/shm
tmpfs 3.3G 17M 3.3G 1% /run
tmpfs 3.3G 0 3.3G 0% /sys/fs/cgro (mnt//orabackup) in this case.up
/dev/sda2 30G 9.1G 19G 34% /
/dev/sdc1 59G 2.7G 53G 5% /u02
/dev/sda1 497M 199M 298M 41% /boot
/dev/sda15 495M 9.7M 486M 2% /boot/efi
tmpfs 671M 0 671M 0% /run/user/54321
/dev/sdb1 14G 2.1G 11G 16% /mnt/resource
tmpfs 671M 0 671M 0% /run/user/54322
//orabackup1.file.core.windows.net/orabackup 10T 0 10T 0% /mnt/orabackup
Next RMAN channels are configured that point to this backpoint (or points)
$ rman target /
RMAN> configure snapshot controlfile name to ‘/mnt/orabkup/snapcf_ev.f’;
RMAN> configure channel 1 device type disk format ‘/mnt/orabkup/%d/Full_%d_%U_%T_%s’;
Once this configuration is done normal RMAN backup and restore procedures can proceed.
RMAN> configure channel 2 device type disk format ‘/mnt/orabkup/%d/Full_%d_%U_%T_%s’;
RMAN> configure channel device type disk maxpiecesize 1000G;
RMAN> backup as compressed backupset database plus archivelog;
You have now backed up the database online using Oracle RMAN, with the backup located in Azure Files. This method has the advantage of utilizing the features of RMAN while storing backups in Azure Files where they can be accessed from other VMs.
RMAN can also be used to create a databases online via the duplicate RMAN command . This requires high network bandwidth and low latency to be successful. Typical alternatives over doing duplication ‘over the wire’ are to create multiple RMAN backup pieces that can be streamed up to the cloud in parallel– again restricted only by bandwidth and latency. Subsequently after the DB is reincarnated and recovered, a CDC mechanism will be required to synch it to its on-premise source.
Other uses for RMAN include using it to manage transportable tablespaces and doing source side endian conversions prior to migration. Finally, RMAN is key to instantiation of DataGuard. RMAN remains an invaluable tool for the DBA being able to do Point In Time Recoveries (PITR) to come back from logical operator errors/ malicious intent. RMAN is key to a robust production database environment
Cassandra consulting LLC offers small to medium sized companies with significant Oracle RDBMS footprints but have few Oracle resources. Cassandra Consulting offers high end consulting services centering around HA (high availability), mission critical back up and DR strategies as well as migration and upgrade services to the Oracle RDBMS ecosystem.
The Oracle RDBMS landscape despite being considered legacy by many is indeed a very critical center of data gravity for nearly all organizations that have various mission critical OLTP as well as reporting/compliance challenges to face.
Cassandra Consulting focuses on the practicality of advancing Oracle technologies without major disruption or “throwing the baby out with the bath “as organizations try to modernize and migrate their business-critical applications to more modern infrastructure platforms and dev ops methodologies. While the continuous Integration and DEV OPS gospel is preached– Oracle legacy applications and their underlying RDBMS support need to be carefully vetted before changes are introduced to mission critical production environments. This is not always adhered to in the world of public cloud CI/DEV OPS.
A keystone of the Cassandra Consulting’s consultancy is the less than glamourous aspect of ensuring resiliency, fault tolerance and disaster recovery or perhaps even more key, that near disaster recovery measures technology and procedures are in place. While fire and brimstone events maybe unusual events “near disasters” occur with alarming frequency due to human error, over-zealous and untested patching and ‘upgrades’ in the sacred name of DEV ops efficiency ( break it now fix it in the next release mentality) I cite the Crowd Strike debacle as a primary example. Lots of fingers were pointed in many directions but each organization that was adversely affected might also want to ask why there were not solid image backups to fall back onto and why they were not able to be implemented in a timely fashion.
Cassandra Consulting by its very name assumes the worse and hopes for the best. As many will know “Cassandra” of Greek mythology was a true “Oracle prophetess/princess” of Troy that was gifted by the enamored Apollo with the ability to see the future but also cursed by the god such that no one would listen to or believe her. – We all can see how that turned out.
Cassandra Consulting therefore ‘assumes and plans for the worst’ while hoping for the best. Database fault tolerance, resiliency and backup DR are its primary mission along with smooth migrations and upgrades for legacy systems moving to new and various platforms. Both are high risk low payback propositions but very necessary. Much like paying for insurance it seems very unnecessary until actually needed.
