Oracle Database on Amazon Web Services Book

The first book that covers running Oracle on Amazon Web Services:
http://www.amazon.com/Oracle-Databases-Amazon-Web-Services/dp/012800956X

Written by these companies:
http://www.appsassociates.com/awslabs/
http://aws.amazon.com/rds/partners/dbvisit/
http://www.e-dba.com/oracle_labs_aws.html

MySQL supports AWS S3 for backup

MySQL Enterprise Backup(MEB) now supports backup to the cloud with support for direct backup to AWS S3.

https://www.linkedin.com/nhome/updates?activity=5889951769257070592&goback=&trk=hb_ntf_LIKED_UPDATE_YOU_CREATED

and the tweet: 

https://twitter.com/paintrichpaint/status/484332341892890624 

Oracle RDS GoldenGate support

Oracle GoldenGate can be used with Amazon RDS for Oracle for active-active database replication, zero-downtime migration and upgrades, disaster recovery and data protection, and cross region replication. 

More information here: http://aws.amazon.com/about-aws/whats-new/2014/04/03/you-can-now-use-oracle-goldengate-with-amazon-rds-for-oracle/

Backup of an Oracle DB on RDS and EC2

When you use RDS, the Oracle database is automatically backed up to S3 for you. You can also take a DB snapshot at anytime or schedule snap shots.  The cost of the backup is included in the price of the database.  You will be charged for the storage in S3 for snapshots.

Amazon RDS enables automated backups of your DB Instance with a 1 day retention period. Free backup storage is limited to the size of your provisioned database and only applies to active DB Instances. For example, if you have 10GB-months of provisioned database storage, AWS will provide at most 10GB-months of backup storage at no additional charge.

You can not use tools like Oracle RMAN or the Oracle Secure Backup for S3 to backup Oracle RDS.

Accenture white paper : Disaster Recovery with Amazon Web Services

Disaster Recovery with Amazon Web Services:

A Technical Guide
The paper covers

1. Define the challenges that enterprises face in adopting public cloud solutions for disaster recovery.

2. Describe the value that large enterprises can gain by adopting cloud-based DR with services such as Amazon Web Services (AWS) for disaster recovery.

3. Provide recommended disaster recovery architecture patterns.

http://www.accenture.com/microsite/reinvent-2013/Documents/Accentue-Smart-Disaster-Recovery-with-Amazon-Web-Services.pdf

RDS cross region snapshots

Great news for AWS RDS users looking to provide extra DR protection to their SQL Server, Oracle and MySQL databases: http://aws.amazon.com/about-aws/whats-new/2013/10/31/announcing-point-and-click-copy-of-amazon-rds-db-snapshots-across-aws-regions/

Oracle Secure Backup details

If you are just getting started with Oracle Secure Backup for AWS, here are some resources to help you get started:

• Oracle White paper : http://www.oracle.com/technetwork/database/features/availability/twp-oracledbcloudbackup-130129.pdf

• Oracle web page : http://www.oracle.com/us/products/database/secure-backup/overview/index.html

• Oracle in the Cloud : http://www.oracle.com/technetwork/database/enterprise-edition/oracle-in-the-cloud-datasheet-1-133113.pdf?ssSourceSiteId=ocomen

• Amazon.com case study : http://aws.amazon.com/solutions/case-studies/amazon/

• Amazon.com detailed case study : http://media.amazonwebservices.com/AWS_Amazon_Oracle_Backups.pdf

• Avnet Offering : http://www.avnetcloudready.com/solutions/backup-disaster-recovery/cloud-backup-for-oracle-database/
• Getting Started with Oracle Secure Backup and RMAN with Amazon S3 http://aws.amazon.com/backup-storage/gsg-oracle-rman/

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:

http://cloudconclave.blogspot.com/2013/04/on-premise-application-replication-and.html

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:

http://cloudconclave.blogspot.com/2012/11/aws-storage-gateway-for-application-dr.html

http://cloudconclave.blogspot.com/2013/04/on-premise-application-replication-and.html

On premise application replication and snap shots to AWS for DR

When devising an disaster recovery approach that used AWS for DR of an on premise environment, there are literally hundreds of options for keeping the databases in sync. Each relational database vendor will have five of their own options and their partner ecosystems will offer many more.  For the application, it is different situation.  Their are not many features built into business application  and application servers.  Depending on what DR scenario you are using http://cloudconclave.blogspot.com/2012/11/aws-four-dr-scenarios.html you will be using either replication or snapshots to keep your AWS application in sync with your on premise environment.  
For warm standby and active-active you will need replication:

• RSync : Rsync is cheap (free) and easy.  Rsync can be chatty, does not have compression built in, and you have to code parallelism. 
• BitTorrent : BitTorrent is most often associated with moving large media files over the Internet in a fast matter. BitTorrent now has file syncing capabilities so can be used to sync application server files.  
• Amazon Storage Gateway " attach these volumes as iSCSI devices to your on-premises application servers.  These files will be stored in S3 where they can be instantiate as EBS volumes.

Riverbed Whitewater - http://www.riverbed.com/products-solutions/products/cloud-storage-whitewater/ https://aws.amazon.com/marketplace/pp/B007O0FXW4/ref=srh_res_product_title?ie=UTF8&sr=0-2&qid=1366938137611#product-detail

Attunity CloudBeam - http://www.attunitycloudbeam.com/solutions/disaster-recovery  https://aws.amazon.com/marketplace/pp/B00B5PB8IM/ref=srh_res_product_title?ie=UTF8&sr=0-3&qid=1366938015695

For backup and restore and pilot light you can use snapshots. 

• FTP or SFTP : FTP and SFTP are the two most common methods to transfer files over the internet.
• HTTP or HTTPs : HTTP and HTTPS can be used but they are slower than S/FTP.  However, if you don't want to require or can not have an FTP client in use than HTTP(s) can be used.  Some companies may not want to open up another port to the outside world have an FTP server running.
• AWS import/export : If files don't need to be synced that often, FedEx, UPS, or Post Office can be the least expensive method with the least amount of hassle (limited coding, no restarting needed)
• Attunity CloudBeam to move files into S3 and than instantiate as EBS volumes.

Oracle EBusiness Suite does offer rapid clone http://docs.oracle.com/cd/E18727_01/doc.121/e12841/T120505T120517.htm but this is not for moving production system data files but for setting test, dev, or moving a system to another machine. Weblogic also offers a cloning feature :http://docs.oracle.com/cd/E12839_01/core.1111/e10105/clone.htm

Oracle Exadata DR to the cloud

Nice case study on using AWS to provide a cloud based DR solution for Oracle Exadata:
http://aws.amazon.com/solutions/case-studies/Sogeti/

Oracle on AWS - EBS mirroring

Question RAID and EBS Raid 1 - Does AWS EBS provide recovery from an EBS volume since the data is automatically mirrored by AWS?

Response:  It depends on whether  you want control over the recovery for mirroring.   Using the built in mirroring means you do not control the mirroring and therefore when recovery happens.  Other options include using Oracle Standby DB/DataGuard, GoldenGate or even EBS snapshots.

AWS Four DR scenarios

There are four DR scenarios that highlight usage of AWS in a DR and a 'HA-lite' situation:

•  Backup and Restore - For systems running on AWS, customers also back up into Amazon S3. Snapshots of Elastic Block Store (EBS) volumes and backups of Amazon RDS are stored in Amazon S3. Alternatively, you can copy files directly into Amazon S3, or you can choose to create backup files and copy them to Amazon S3.
• Pilot Light for Simple Recovery into AWS - This scenario is similar to a Backup and Restore scenario, however, you must ensure that you have the most critical core elements of your system already configured and running in AWS (the pilot light). When the time comes for recovery, you would then rapidly provision a full scale production environment around the critical core. The database data would be replicated to S3. You would typically have some pre-configured servers bundled as Amazon Machine Images (AMIs), which are ready to be started up at a moment’s notice.  These servers could be EC2 instances that have been stopped.
• Warm Standby Solution - A warm standby solution extends the pilot light elements and preparation. It further decreases the recovery time because in this case, some services are always running. By identifying your business-critical systems, you would fully duplicate these systems on in another AWS zone or region and have them always on.  This would insure that the EC2 capacity is available in a disaster.
•  Active-Active Solution - A multi-site solution runs in another AZ or zone in an active-active configuration. The data replication method that you employ will be determined by the recovery point (RPO) you choose.