I have discussed already one of the great pillars of system administration – Security. In this post I want to talk (at a high level) about the second – Backup and DR.
Backup within the cloud is a little strange, there are no tape units but there is an abundance of cheap disk with Snapshot capability.
So if we take the major components one at a time
Operating system – backing up the O/S is really done by bundling the instance. So when you apply patches or change the configuration, you should bundle the instance into a new AMI.
The best thing about this is the ability to restart the new AMI, and see if the instance is stable enough to run SAP on. Other than the bundling I have not found a way to backup the O/S using a method that would facilitate a bare metal recovery.
SAP System – Utilising the ability to snapshot the SAP Volumes is the most expedient way to provide a point in time snapshot, of course there are some synchronization issues with Java stacks and the annoying insistence of Java to use file system persistence.
My advice is to take the snapshot after the database backup, that way you can use a point in time recovery to bring your filesystem into line with your database backup.
Database backups – Given that I am running a Proof of Concept (POC) I really only need to backup the system every once a week or so, but I’m a thorough guy so I decided to backup every night to test various configurations.
Through my experiments I have found the following works very well and is very cheap.
1. Allocate enough disk space to contain 7 nights backup, this will be your online disk to disk backup storage. Although be careful with this, if you’re getting into realms of 1.5TB or more I would create smaller volumes and bring them on and off-line as required.
2. Using standard database tools – write a script to backup the database to the backup storage area every night.
For my POC, because I am using DB2 and MSS I have easy access to online tools for backup that will write to disk quickly and easily. The Oracle and RMAN heads will have to workout their own issues on this one.
3. Set up a script that will snapshot your disk to disk backup storage unit every week, or you can do it manually
This setup allows you to easily keep 14 nights backups at reasonable expense, I have tested this on a small drive so I would need to perform larger scale tests to make sure it scales.
In this example, I am putting 14 days backups on two sets of disk volumes which might not the best idea in a single SAN environment. Of course we are using S3 as our storage provider, so we have no idea where the disks are in relation to each other (so lighten up)
There are lots of backup utilities that work very well (Netbackup, CommVault), but do you really need them in the Cloud where you have few resources and no tape drive.
I think for the recovery of databases, the answer is YES.
Most backup utilities can simplify stressful restorations by automating the recovery based on parameters entered by the administrator. Also you probably already pay for an Enterprise license – so if the licenses are there, use them to create simpler DR processes.
Everyone has their own opinion of what is the best method for backing up their systems, to be honest very few people care how the data is backed up. What they care about is, can their data be recovered and how quickly it can be done.
Your process – whatever it may be- must be practiced at least once a year and be a simple as possible.