Showing posts with label disaster recovery. Show all posts
Showing posts with label disaster recovery. Show all posts

Wednesday, May 1, 2013

AWS disaster recovery for applications, database and storage


When coming up with an approach to perform disaster recovery on AWS from your on premise environment,  you need to look at these layers of your system as individual entities.  This is because for each of them their are different tools and approaches.
1. Storage Layer: The storage layer includes multi media files, batch files, log files and any other files that not directly owned by the application or database server.  These files are typically on SAN or NAS devices on premise.
More information here:

2. Database Layer:  This would be data files associated with your relational or NoSQL database.  There are many database vendor specific tools. So the best approach is typically to use the tool or facility provided by the DB vendor.  
More information in these blog entries:
http://cloudconclave.blogspot.com/2013/01/disaster-recovery-in-cloud-options.html
http://cloudconclave.blogspot.com/2013/03/aws-ebs-snapshot-volumes-for-mysql.html – More on snapshots as apply to MySQL


http://cloudconclave.blogspot.com/2013/03/aws-ec2-oracle-database-backup.html - OSB or EBS snapshots
http://cloudconclave.blogspot.com/2012/10/oracle-helps-amazon-save-money-on.html – More on OSB
http://cloudconclave.blogspot.com/2013/01/oracle-exadata-dr-to-cloud.html - Exadata
http://cloudconclave.blogspot.com/2013/02/oracle-secure-backup-restore.html – Recovery speed for OSB



3. Application Layer:  The application layer includes all source code (Java, PHP, Ruby, HTML etc), log files and anything else associated with your application server.
More entries in these blog entries:







Friday, January 25, 2013

Disaster recovery in the cloud options

These are by all means not all the options, but at a high level these are the common options:

  • Backup and restore - Have to set up security groups set up and set up Route53. Data is not being mirrored or replication. You are doing an import and export from database to S3. When system goes down then resource S3 data to the database. You also have to provision AMIs.
  • Pilot light – In this case, you are doing Data mirroring/replication from source system to DR site. Could run GoldenGate. The EC2 instances are present but stopped. Have to prepare all required resources from automatic start – AMIS, network settings, load balancing etc.
  • Fully working low capacity standby – Blurring lines between HA and DR. In this case have an issue with RDS as the data needs to replicated both ways as traffic could go to either configuration.
  • Multi-site hot standby – production load on both sides. Cost and data sync are the biggest challenges.