“We have absolutely no backups of Paris whatsoever?” were the words I heard that would change the trajectory of my career in backups. It was 1993, and we had lost a disk drive containing part of an Oracle database that was the purchasing database for a $35 billion company. And we had absolutely no backups – whatsoever. It was my first job in backups and I’d been there just long enough for it to be my fault.
Amazingly, I was not fired, and I resolved to learn everything I could learn about backup and recovery – especially Oracle backup and recovery – because that wasn’t going to happen to me again. Fast forward 26 years and I find myself writing a blog post about how the Druva Cloud Platform supports data protection for Oracle databases. Since I know all too well how complicated Oracle backups can be, let me assure you we made it as simple as possible, while also ensuring RMAN backups are stored in the cloud for DR, long-term retention, and protection against ransomware.
RMAN is your friend
Recovery Manager, also known as RMAN, is the supported way to backup an Oracle database, and some have shied away from it because its syntax can be a little intimidating. The good news is RMAN is well-documented and Oracle is more than happy to support you in developing and refining RMAN scripts. Druva is part of the Oracle Backup Solutions Program (BSP) and provides a solid RMAN script that automates the entire backup process.
RMAN manages the entire backup and recovery process, including the deletion of backups and archived redo logs that are no longer required. You can perform full and incremental backups, and can even merge incrementals into the full, allowing you to adopt an incremental forever methodology. This methodology reduces the impact backups have on the performance of the database being backed up, the amount of network bandwidth needed to transfer backups, and the amount of disk space needed to store them.
RMAN also allows you to put database backups in the hands of those who are most concerned about them: the DBAs. RMAN commands can be run by any properly authorized user, allowing your DBAs to ensure backups run on a schedule they prefer, as well as running a backup manually prior to an upgrade.
As a backup person who has always preferred centralized control of backup scheduling, I have historically not been a fan of DBA-initiated scheduling, but I have recently acquiesced to the DBAs for two reasons. First, I realized the DBAs that want to schedule their own backups are very interested in making sure it happens, and that’s a Good ThingTM. Secondly, as long as I can have centralized monitoring showing the DBAs are backing up the databases in question, then everyone gets what they want.
Oracle backup and recovery challenges
Once you get past the complexities of RMAN, the next thing you need to recognize is the aggressive RTOs that Oracle databases often have, for both day-to-day recoveries and DR. Cloud-based data protection is great at a lot of things; it’s incredibly scalable, highly efficient, and less expensive than the alternatives, but how does one meet an aggressive RTO of a large Oracle database if your only protection copy is in the cloud? You’re going to need a local copy as well. It would be even better to have a local copy of the last few days’ worth of backups – perhaps even a week – to ensure you can recover your Oracle database to multiple points in time. Of course, you also need to make sure the latest backup is stored off-site, and retained for a longer period of time in case it is needed for any compliance issues. Having an onsite and offsite copy can be quite challenging, given the size of many databases.
Enter Phoenix Backup Store
Druva is meeting these challenges with our new offering, the Phoenix Backup Store (PBS), which is Druva technology leveraging NFS as a target, and ZFS for its native compression. This can be a Linux server of your choice, or a VM running in your local hypervisor, or even in the public cloud. Druva will provide an RMAN script to automate the backup process, which your DBAs can also customize if they wish.
The backup process is as follows:
The Druva-provided RMAN script automates the entire backup process. After ensuring the Oracle server can access the NFS mount on the PBS, and the PBS is properly authenticated with Druva Phoenix, it will initiate an RMAN backup to the NFS mount. Once the backup is successful, it will merge the oldest incremental backup into the full (more on that later), then initiate a Phoenix snapshot of that data to the cloud. Druva global deduplication will ensure only new, unique bits of information found in the RMAN backup will be sent to the cloud, reducing the amount of bandwidth and processing needed to perform the cloud backup, and reducing the amount of storage it will require in S3 – which is what you are billed for.
When the script directs RMAN to merge incremental backups into the full, it actually directs it to merge only incremental backups that are older than n days. Customers will decide the number of versions (n) of the database they would like to retain on the PBS, which allows them to recover any version of Oracle in the last n days without having to restore anything from the cloud. Reducing the number of versions (n) will save disk space on the PBS, but reduce local recovery options. Increasing the number of versions will increase local recovery options, but also require more disk space. How much more disk space a higher n value will require would depend on how much data tends to change every day in your Oracle database.
If a customer needs to restore a version of Oracle older than n, they have lost the on-site copy, or would like to restore Oracle to a different site, they simply use Phoenix to restore that snapshot to any location of their choosing. After that, the customer can restore the database using RMAN from wherever they restored the snapshot.
The best of both worlds
The PBS gives DBAs access to a local copy of their database to satisfy much more stringent RPO/RTOs. Copying PBS data to the cloud allows you to take advantage of the scalability and usability of the cloud – as well as paying only for what storage you use in the cloud after deduplication – while also retaining as many copies as you would like for long-term storage for compliance reasons. Storing a copy in the cloud also allows you to recover your Oracle database to any location you choose, including to a VM in the cloud.
Ask for more details about Druva Phoenix and the Phoenix Backup Store. That way you won’t ever find yourself asking whether or not you have backups of your purchasing database.