Managing Oracle backups on AWS
Oracle DBAs will be familiar with setting up backups for their databases, but there are a few differences and options in AWS that it’s useful to be aware of.
We look at these in todays’s blog post.
RDS Backups
Managing backups with RDS is fairly straightforward as it is a simple checkbox to configure; the only decision to be made is what retention is required beyond the standard 30 days.
Self managed Backups
If you are Self Managing the database then a backup strategy needs to be worked out. There are two paths for configuring backups for Oracle Databases whether you use Oracle native tooling Recovery Manager (RMAN) or you use the native AWS snapshot tools to manage backups.
We examine both of these below.
RMAN backups
RMAN is a tool loved by DBAs for managing backups as it is aware, down to the block level, of changes within an Oracle database. Because of this feature it processes only those blocks that have changed within the database and gives us the added advantage that it can provide a useful daily check for Block Corruption within the database.
In the example above you’ll see we use an S3 bucket. The downsides of using RMAN with an S3 bucket as a virtual tape store is storage costs. Because AWS will regard each backup as a fresh set of data the cost of the bucket hosting the backup can spiral. Also as the blocks are being physically copied to another medium the database server performance is impacted while the backups occurs.
Snapshot backups
An alternative to backing up the database using RMAN is to use snapshots within the AWS storage layer. Until recently to guarantee good backups the database would have to be placed in backup mode while the snapshot was taken, however as of the last couple years it has become possible to freeze the disks while the snapshots are initiated and also instruct for snapshots to be taken at instance level so all disks attached to an instance have a snapshot taken at the same point in time.
AWS have also introduced AWS backup which allows for backup policies to be defined at account level to remove the process of setting backups on a per server basis.
The main advantages of this approach are that the storage costs for snapshots are much better contained as only blocks that have been changed have to be retained on each backup, also the impact of making the backup is offloaded into the storage layer away from the database server.
Backup is nothing without recovery
As any DBA knows the backup regeime is only as good as the last time it was tested. Nothing has changed when we run Oracle on AWS!
The principal attraction of RMAN has always been the simplicity of recovering the database in the event of some kind of data loss event. The steps to reinstate the database are as simple as typing “recover database” at the RMAN command prompt.
However, the steps involved in recovering the database in the snapshot scenario are much more involved and require working in multiple toolsets. While automating this process is eminently possible the recovery involves many more moving parts in a high stress scenario.
