Druva is highlighting how Oracle products and supporting technologies offer its end-user community a treasure trove of feature-rich backup capabilities, and how Druva products enable them in our ongoing Oracle in-depth blog series. In the first of the series, we examined the complexities of Oracle recovery manager (RMAN) and its capabilities to simplify RDBMS backups, before exploring block change tracking (BCT) and incremental merge in part two.
In this edition, we’ll take a dive into Druva’s new direct-to-cloud products for RMAN backup sets, including our proprietary serial backup tape (SBT) library capable of streaming RMAN or RMAN SBT backups direct to the Druva Cloud within an AWS EC2 environment. This protects Oracle workloads by removing any dependency on intermediate appliances, tapes, tape libraries, hardware, or software.
Oracle SBT: history and advantages for backup
The Oracle SBT library was one of the great technological advances that Oracle developed as a mainstay of the relational database technological base. As backup and recovery are the first responsibilities of a systems administrator or database administrator (DBA), the development of stable, reliable, and robust backup methodologies via tape or disk made the Oracle RDBMS an industry standard. The SBT library, and what was known as the media management layer (MML), became a gold standard of backup and recovery as Oracle and many third-party backup vendors strove to integrate their products with RMAN. The tape library also enabled organizations to archive their data and store it offsite as a tertiary modality of backup protection. It also afforded organizations the ability to prove regulatory compliance, that data was safe, secure, and viable with large archiving vendors like Iron Mountain.
During the early days of the development for the SBT library, there were no storage area networks, disk storage, or disk arrays that we are familiar with today. Arrays were smaller and very costly. The attendant disk I/O subsystems were also slower than present technologies and did not scale well. In many cases, relational database architectures relied upon local disks or JBODs, an acronym meaning “Just A Bunch of Disks.” This was essentially a group of disks daisy-chained together to make up the relational database storage. As a result, tape backup methodologies and tape library vendors exploded in terms of their rapid growth, and adoption across all sectors of industry. These libraries streamed data efficiently to tape and afforded a modality for archiving with which disk storage simply could not compete. At this time, disk storage was expensive and did not yet scale.
The SBT library is very straightforward, and each vendor developed a “libobk.so,” a standard C library that was linked into the Oracle environment or placed into a static directory, and enabled RMAN to stream the data to tape. In our previous blogs, we discussed what are known as backup sets, and that they are the default method for any RMAN backup, whether tape- or disk-based. An RMAN backup set comprises one or more backup pieces in a highly proprietary format. The backup set is a logical structure holding physical files including either one or more datafiles, archivelogs, or control files. All physical files that require backup for the DBA to properly restore or recover an Oracle RDBMS.
The best reference for this material is, of course, metalink, Oracle’s support website wherein this is discussed in “Getting Started with Recovery Manager (RMAN)” (Doc. ID 360416.1). The document juxtaposes the RMAN image copy versus the backup set, which we explored in our second blog of the series.
“If you specify BACKUP AS COPY, then RMAN copies the files as image copies, bit-for-bit copies of database files created on disk. These are identical to copies of the same files that you can create with operating system commands like cp on Unix or COPY on Windows. However, using BACKUP AS COPY will be recorded in the RMAN repository and RMAN can use them in restore operations. Image copies cannot be created on tape.”
Example syntax: RMAN> BACKUP AS COPY DATABASE;
A backup set is described in the document is as follows:
“If you specify BACKUP AS BACKUPSET, then RMAN stores its backups in backup sets. A backup set, consisting of one or more backup pieces, contains the physical file data being backed up. This backup set is written in a format that only RMAN can access. Only RMAN can create and restore backup sets. Backup sets can be written to disk or tape, and they are the only type of backup which RMAN can use to write backups to tape.”
Example syntax: RMAN> BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG;
The advantage of a backup set methodology is that it allows for multiplexing the backup pieces, meaning RMAN is able to write Oracle blocks from disparate datafiles into the backup piece. This feature is not available with an image copy methodology. Again, from our above reference, another differentiation is the fact that RMAN will not back up empty blocks with a backup set, but an image copy in point of fact will still back up empty blocks. Thus, RMAN backup sets are more efficient in terms of a disk backup as we save on backing up the empty blocks.
Note:
“Backing up data files as backup sets on disk can save disk space and time because RMAN will skip backing up some unused datafile blocks. Backup sets, once written on disk, can be moved to tape with the BACKUP BACKUPSET command. See the description of unused block compression in Oracle Database Backup and Recovery Reference for details.”
RMAN does however favor using image copies. If a DBA is restoring a database and has RMAN backup sets as well as image copies available from the same timeframe, RMAN will leverage the image copy in the restore scenario over a backup set. As a result, the attendant restore is done with greater alacrity by avoiding the complex processing of disparate datafiles in the many backup sets. In our previous blog, we also discussed the advantages of the “switch database to copy” syntax, which allows RMAN to quickly switch the copy to a datafile effectively by renaming it. This also allows the DBA to spin up very rapid cloned copies of the database to either an alternate node host or an alternate destination, or even a different disk storage modality, such as moving a database from ASM (automatic storage management) to a standard file system.
SBT and how Druva plays a role
This leads us to the latest innovations in SBT library technology at Druva. In an upcoming release, Druva will introduce Oracle backup teams and the end-user community to a functionality called “direct-to-cloud” (DTC). The DTC release will introduce a new Linux agent that, once loaded into the OS with an rpm file, will start an agent that auto-discovers all databases on a particular host where the rpm is installed. At the same time, it loads a libphxsbt.so into the Oracle configuration such that RMAN and the agent may leverage it to back up any and all Oracle databases directly to the cloud and into the Druva file system. The library which is built from C structures is, of course, the same proprietary code that Oracle is built from. It is responsible for compressing the data as well as encrypting and globally deduplicating it.
The proprietary format of the Druva file system is highly secure in the Druva Cloud, thus protecting the RMAN backup sets from ransomware attack. This library ultimately leverages the standard RMAN backup methodology of backup sets. Hence, every Sunday the DBA may schedule a level zero full backup and incremental level one backups nightly. The level one backups in RMAN are either differential or cumulative incremental backups. In our proprietary technology, we have chosen to leverage the default of differential level one incremental backups. This is set within the backup policy utilized by the DBA via a highly innovative and new UX, developed concurrently with our new RMAN C library to offer the Oracle end-user a truly feature-rich backup and recovery experience. This allows the DBA to schedule and launch backups with the agent and Druva UX.
Key takeaways
In short, this single pane of glass will allow the DBA to maintain and manage all database backup and recovery for all databases. All RMAN scripting and execution is automated in the UX, and the DBA may expose the source code that is being executed by the agent. It even gives the DBA the ability to use manual command line arguments with backups that are created by this innovative tool. This includes database recovery and restoration operations for a single tablespace and/or datafile, or the entire database within the UX. An early access (EA) offering is taking place in February 2021. A general availability release will follow in 1H 2021 and support a variety of standard Oracle configurations like RAC, (Real Application Cluster), standalone databases running on automatic management storage or standard filesystems, Oracle Data Appliance, Oracle Exadata, and other assorted Oracle implementations in the current production, development, and test environments of the end-user community.
Looking for more information on Druva’s innovative products for Oracle applications? Stay tuned for the next edition of the Oracle in-depth blog series, where we’ll further explore the Druva SBT library and how it works with RMAN and the Oracle RDBMS. To learn more about Druva for Oracle, watch the video below for a demonstration of our products in action!
