When the well-renowned Oracle database started penetrating the enterprise, database administrators typically backed up to tape and disk, with the former being the preferred target. To support the various tape and disk vendors in the marketplace, Oracle came up with the concept of a media management layer that allowed vendors to provide front-ends to their tape or disk devices. The media management layer was designed to support append-only backup streams and the main construct in the layer was a concept called the backup set. The backup set can be loosely considered to be a collection of backup files (data files, archived redo logs, and control files) and a database backup is considered to be a collection of backup sets.
Backups using backup sets can be streamed to and from disk or tape devices in parallel, leading to faster backup and restore times. Backup sets can be both full and incremental, but the standard practice is to take a full backup once every so often (typically a week) because of the high time required in applying incrementals to a full backup. Another disadvantage of backup sets is that databases cannot be mounted on them as the format of backup sets is logical.
As databases started to grow larger and larger, taking full backups every so often became prohibitive as disk speeds did not improve at the same rate as database sizes grew. Enterprises with petabyte size databases soon realized that weekly backups would not finish in a week. In response, Oracle came up with a new concept called image copy backup as well as an associated concept called Incremental Merge.
An image copy is a byte-for-byte backup of Oracle database files which can be stored only in disk. One advantage of an image copy is that databases can be mounted directly off an image copy leading to interesting applications such as cloning for dev-test workflows. A question then arises as to how to manage incrementals in such a scenario. To address the question, Oracle introduced the Incremental Merge technique where changes to the database can be applied to an image copy creating a new image copy with the applied changes. This means that image copies with Incremental Merge can allow organizations to adopt a forever incremental strategy and avoid having to take weekly backups of large Oracle databases.
However, one disadvantage of Incremental Merge is that large database files cannot be restored in parallel, yet another is that backup set streams are more storage efficient than image copies because of the need for a byte-for-byte equivalence. When backups are taken with Incremental Merge, the entire size of the database is backed up, while in the case of backup streams, only used blocks are backed up. Finally, when Incremental Merge is used with a large number of data files in the Oracle database being backed up, there is additional metadata pressure on the backup target. This is not only due to the large number of files being backed up, but also because the metadata of the files needs to be kept consistent across multiple backup points.
Enter Rubrik, we have come up with a new solution called Rubrik Incremental Merge that combines the best of both backup sets and image copies with Incremental Merge. Not only does Rubrik Incremental Merge provide the advantages of image copies with incremental merge, the technique also allows for parallel restores and backups of a single large database file as well as efficient support for backing up and restoring databases with thousands of files. Finally, Rubrik Incremental Merge is storage efficient without compromising the byte-for-byte equivalence imperative for an image copy. Furthermore, Rubrik Incremental Merge provides immutability guarantees for all backups, does not alter the previous copy of a backup and maintains a storage efficient representation of the merged backup.
Rubrik Incremental Merge can be visualized using the diagram below. An Oracle database is backed up using the RMAN component provided by Oracle that generates backup streams. The backup streams are intercepted by an Injection layer that provides many optimizations such as parallel backup and recovery at both an intra-file and an inter-file granularity. The backups are then transported over a secure Thrift communication protocol over to the Rubrik CDM cluster. The Rubrik Oracle Snappable then takes charge of the backups, provides critical metadata management and sends the backups to the Aligned File Aggregation Format (AF2) layer. The AF2 layer not only handles the metadata pressure of a large number of files but provides a distributed deduplication capability. Finally, the backups are routed to the Merged Journal file (MJF layer) which provides strong immutability guarantees as well as a compact storage representation.
Contrary to the perception that database backup for a well-established vendor such as Oracle is truly settled, Rubrik has come up with an innovative solution that provides a best in class experience for database administrators not only in terms of supporting various database features that Oracle provides, but also in key metrics that makes the life of database administrators easier:
Features such as ACO (Advanced Cloning Option) that vastly simplifies and automates complex steps in the recovery process leading to faster recovery and a superior experience.
Performance enhancements using AF2 and Secure Thrift that allow us to quickly backup and restore both a small number of large data files as well as a large number of small data files at the highest scales Oracle can support.
As enterprises move to the cloud, Rubrik is committed to developing innovative data protection solutions that are cutting edge in terms of security and resilience.