Oracle databases have become a critical part of many businesses. Everything from employee and customer data, sales records, and inventory can be stored in these databases. If the database becomes corrupt or unavailable it can lead to millions of dollars of lost revenue per hour or potentially a company ceasing to exist. Just imagine the number of sales lost if the database hosting Amazon.com went down during Prime Day! Therefore, it is no surprise that databases are considered a mission-critical workload that must not only be protected from physical outages, but also against user mistakes, logical errors, or malicious intentional actions. Often database admins (DBAs) don’t want to rely on another team for this protection, especially when their job of keeping the database up and running is on the line. At the same time, backup teams are trying to figure out how to ensure that compliance and other business requirements are being met, and most times these are at opposite ends of the spectrum with each team deciding to do things on their own.
In this blog, we’ll explore some best practices we can follow to satisfy all maintenance requirements to efficiently protect and recover Oracle databases.
Not just a single piece
Backing up Oracle is significantly more complex than a virtual machine or a file system. The database is composed of multiple components including datafiles, control files, and redo logs. You can’t just copy a single piece and get a backup of the entire database. All pieces work together to construct the point in time for the database. When you back up the transaction logs (archived redo logs), you can now recover to any point in your database. You can go back to a single transaction right before an issue happened, or roll forward from the last backup of your datafiles to a more recent point in time.
Backups being consistent are also important to Oracle DBAs. Taking an independent snapshot on the storage array hosting the Oracle database doesn’t mean that you can recover the database. It is important that your Oracle backup is consistent, so you can guarantee it can be recovered. There are different ways to get consistent Oracle backups — bringing the database offline, putting it into hot backup mode, or leveraging Oracle-native tools, which we will cover later in this blog.
All these pieces and methods are important for backing up Oracle databases since they allow DBAs different ways to recover their database from different failures. Therefore, it is also important that your backup solution provides a way to back up the different pieces (potentially with different retention) in a consistent way such that your DBA can always recover the database.
Use forever incremental backups
While Oracle supports your traditional full and incremental backup types (in addition to backing up archived redo logs), one interesting feature it also supports is called Oracle Incremental Merge (OIM). OIM allows you to have an incremental forever backup strategy by merging an incremental backup with the full and creating a new updated full. This way you can avoid ever having to do a full again (which can be near impossible with large databases). But in order to use OIM, you need to be able to do image backups of the database to a local mount or NFS share (OIM doesn’t work with tape or backups to disk created using the SBT library). Your DBAs want the flexibility to use the capabilities provided by Oracle. If your backup solution doesn’t provide support for OIM, then the DBAs will protect the database on their own, leaving the backup team without visibility into these ongoing efforts.
Simplify using native Oracle tools
In addition to providing different ways to back up and recover your database, Oracle has done an amazing job providing a native backup tool called Oracle Recovery Manager (RMAN). RMAN eliminates the database admin having to figure out what components of the database to back up when doing a specific backup, or even more valuable, lets them easily do a recovery without having to figure out the 50 files across 20 backups that might need to be restored. Remember, most times you aren’t just restoring a single point in time when recovering your database. Some files may be from old backups (like your previous full), while others may be needed (like archived redo logs to get up to the right point in time). And some backup options (like OIM) require RMAN as it manages the merging operation.
However, every Oracle DBA I have met only wants to use RMAN for Oracle backups — they don’t want to use the backup admin’s tool. In fact, I’ve seen cases where in order to avoid having to use the backup admin’s tool, the DBA does backups of their Oracle database to expensive Tier 1 primary storage. And yes, they kept multiple backups on their primary storage, leading to the storage team wondering why a database was actually consuming 6x the space it should be using. All this confusion could have been avoided had the DBA just trusted RMAN’s admin tool.
Work together to get things done
We know that Oracle DBAs want to use RMAN to back up and recover their database and cares most about ensuring the database is up and running. DBAs will only keep enough copies to ensure they can recover their database within the recovery window defined in RMAN. The backup team, on the other hand, wants to make sure that backups are being taken and that those backups meet the 3-2-1 rule (3 versions of data on 2 separate media, 1 of which is offsite), and are retained for the right amount of time. The previous example of the DBA doing backups to primary storage fails to meet the “2” and “1” of the above rule, and as such I wouldn’t consider it a backup.
So how can the backup team and the database team meet their business needs for protecting Oracle? There is no reason that the backup team needs to take another backup of the Oracle database — allow DBAs to take the backups to storage using RMAN. DBAs can still control their own backups and restores just like before, but what the backup team can now do in addition is manage the lifecycle of the backups from that storage. They can move it offsite, and ensure that it can’t be deleted before retention is met (even if DBAs shorten the RMAN recovery window or try to manually delete the backup). However, it is important that this isn’t treated like a file system backup. The backup team needs visibility into what is being backed up so they can know that it is being protected. By working together, the backup team and database team can each meet their objectives while not duplicating infrastructure or costs.
Go forth and protect
Oracle doesn’t have to be this mythical application that is difficult to protect, and database and backup teams don’t have to be sworn enemies. Let’s summarize these best practices for backing up Oracle:
- Oracle is complex, so make sure you are backing up all its pieces in a consistent fashion
- Simplify backups and recoveries by using Oracle RMAN to eliminate many DBA concerns and ensure that your backups and recoveries are reliable
- Provide the flexibility that your DBAs desire by offering Oracle Incremental Merge (OIM)
- Don’t do double backups of your Oracle database; work together to manage the retention of your Oracle backups for the different needs of the business
Druva helps customers protect Oracle by allowing DBAs to use RMAN to back up their database to a local software appliance. Once backed up, the lifecycle of the backup is managed by the backup admin to ensure compliance is met and copies follow the 3-2-1 rule by moving the copy into Druva’s cloud. DBAs still have full access to the backups done and can leverage all the functionality of RMAN (including OIM). And with Druva’s upcoming Oracle direct-to-cloud feature, backup admins can take consistent Oracle backups directly to Druva’s cloud — removing the burden of backups from database admins.
At Druva, we know that Oracle is mission-critical for your business and want to ensure that your database team has the options they need to protect, and more importantly recover their databases. To learn more about Druva for Oracle, read our Oracle in-depth blog series and watch the video below for a demonstration of our products in action!