When I had the privilege of teaching Oracle courseware for Oracle University, I always led the course with a question about a database administrator (DBA)’s most sacred of duties. The question in a nutshell was, “what is a system administrator’s and/or a DBA’s first duty?” The answer to the question is, of course, backup and recovery! A DBA must ensure with absolute certainty that the data he or she maintains is protected at all costs! The history of backup and recovery therefore entails a number of different modalities to perform this most sacred of duties, and it is the evolution of these products that is the topic of our discussion today.
RMAN for Oracle databases
Oracle Corporation over time developed one of the most sophisticated relational database platforms in the history of relational database technologies. The feature-rich platform attracted and held many devotees over several decades with great success. The hallmark of this technology was the development of a number of proprietary tools that perform Oracle RDBMS backups, namely RMAN, or recovery manager. RMAN affords the DBA to invoke either the SBT tape library methodology or the disk based methodology. Thus, every third-party backup and recovery vendor strives to integrate its product with RMAN through what was known as the media management layer or MML.
The MML entailed having a library that the third-party vendor developed and then tested with Oracle and its RMAN technology for certification. This process proved costly and onerous, and Oracle discontinued the practice. As time progressed, Oracle developed a number of outstanding technologies with RMAN. When it was released, the most popular method of backup was to create what are known as “RMAN backupsets.” Leveraging PL/SQL blocks of code, RMAN creates a backup of every Oracle block, the smallest increment of storage in an Oracle RDBMS. A default block size of 8K was the standard that Oracle settled on, but other block sizes were ultimately available, including 4K, or 16K block sizes that were used with OLTP (online transaction processing systems) and DSS (decision support systems) respectively.
Thus, Oracle worked tirelessly to develop a code base that enhances the RMAN backups and strategy by affording the DBA the ability to enable and use encryption and compression algorithms that greatly enhanced the RMAN backup strategy. Ultimately, many of these compression and encryption algorithms were adopted by other third-party backup vendors or were integrated with their products. The end result was a number of industrywide technological standards, like AES-256 encryption for example. It is used by Oracle for its TDE or transparent data encryption product, as well as by many other technology stacks.
Enhancing RMAN to protect your data
Enter the evolution of products and new exciting technology platforms including those offered by Druva. Druva’s SaaS-based backup and recovery service, part of the Druva Cloud Platform which is powered by AWS, which also uses the AES-256 cipher to encrypt your backup data at rest. The rise of ransomware attacks has resulted in the need for ever more secure methods of backup and recovery, thus Druva developed solutions to not only compress your data, but also the ability to globally deduplicate and air gap it from ransomware attacks. This includes separating and/or sharding the backup metadata from the backup data to protect it even further. The older standards of just compressing and encrypting your tape and/or disk backups with RMAN have evolved greatly over time, and this is another example of how a third-party backup vendor is able to add value to the Oracle technology stack, by not only leveraging Oracle technologies, but dovetailing with the technology stack to afford even greater performance enhancements as well as protections to your data.
The Druva technology stack also makes multiple copies of the data by storing them in separate locations of the Druva Cloud, alleviating the need to make multiple copies of your database with RMAN. The global deduplication mechanisms of the Druva Cloud also dovetail with the Oracle technology stack by leveraging block change tracking (BCT) with the Oracle incremental merge backup methodology, which we will discuss in detail in a later blog post. Incremental merge leverages RMAN image copies rather than backupsets, and is an incremental level one forever backup methodology that is Oracle-based, but is utilized in the Druva Cloud. As a result of this, Druva Phoenix for Oracle backup protection is able to transmit only the changed blocks via the network to the Druva Cloud via Druva’s proprietary global deduplication mechanisms. The Phoenix Backup Store, or PBS, is the software appliance that is responsible for performing this on-premises or in the cloud client-side global deduplication.
It also uses its own proprietary ZFS algorithm to compress the data. This allows the Oracle DBA to turn off RMAN proprietary compression and encryption, affording the DBA and his/her organization faster backups with fewer CPU cycles. Since PBS compresses and encrypts (TLS 1.2) the RMAN data on the fly, the backups are highly secure and always encrypted in flight as well. In actual proof-of-concepts (POCs) conducted in AWS in the EC2 environs, Druva Phoenix was able to compress an 8.5 terabyte Oracle for SAP database down to 1.7 terabytes on the PBS software appliance, which is a small virtualized appliance that performs client-side global deduplication and ZFS compression, such that when the data is snapshotted to the Druva Cloud the data is already in a compressed format and is globally deduplicated to reduce network traffic to the Druva Cloud whether or not your database is in a traditional on-premises data center or in the AWS EC2 environs.
The PBS is both a NFS and ZFS software appliance offering its own zpool of virtualized storage, whether an on-premises VMware vCenter providing storage from a datastore, or EBS volumes in the AWS EC2 environs. The PBS provides the DBA with a NFS target exposing storage from the PBS to the Oracle RDBMS host, thus offering a simple and straightforward disk target to backup the database via RMAN. This simple disk backup solution is also integrated with OEM, so the DBA may use either Oracle Enterprise Manager Cloud Control to schedule and launch backups, or traditional methods like the Unix based cron daemon, or other third-party schedulers. The PBS is viable with an Oracle recovery catalog or without. The elegant simplicity of the PBS makes backing up an Oracle RDBMS as simple as possible by leveraging the best that Oracle has to offer in terms of RMAN, as well as the best that AWS and/or Druva have to offer in technological advancements. This is truly a marriage made in heaven, or what we now know as the cloud!
Transform Oracle data protection
Druva Phoenix, a scalable, all-in-one backup, disaster recovery (DR), archival and analytics platform, simplifies data protection, dramatically reduces TCO up to 50%, and improves data visibility for today’s complex information environments. Watch the video to discover Phoenix’s unique set of advantages for Oracle data protection, and visit the Druva for Oracle page to learn more.