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:







2 comments:

  1. Great post, thanks for such a clear explanation on AWS on prem. This will so useful for AWS beginners.

    ReplyDelete
  2. Agree with you! Also, I have spent a lot of time choosing the most suitable software for AWS Disaster Recovery

    ReplyDelete