Oracle RMAN 11g Backup and Recovery (62 page)

Chapter 6: Backing Up to Amazon Web Services Using the Oracle Secure Backup Cloud Module
149

RMAN must specify the location of the S3 SBT library and OSB Cloud Module parameter file (both created during install) when allocating the SBT channel to S3. You can specify this information persistently for the database by using the RMAN
configure
command, or each time you allocate a channel. If you also use other media management libraries such as NetWorker, NetBackup, or Oracle Secure Backup, you should not configure S3 persistently to be the default MML unless you really mean to do that.

To Persistently Store S3 as the Default SBT Channel

The following RMAN code snippet demonstrates how to persistently configure the default settings for RMAN’s SBT I/O channels to use Amazon S3 using the OSB Cloud Module. Using this method, the default destination for SBT I/O will be Amazon S3. If other RMAN backup jobs need to write to or read from local tape, for instance, they will have to specify their local tape MML libraries in the
allocate channel
command.

RMAN> configure channel device type sbt

2> parms 'ENV (OSB WS PFILE /u01/oracle/product/11.1/db 1/dbs/osbwst1.ora), 3> SBT LIBRARY /u01/oracle/product/11.1/db 1/lib/libosbws11.so';

To Specify the OSB Cloud Module Each Time You Allocate a Channel

The following RMAN code snippet demonstrates how to manually configure each channel to use the OSB Cloud Module at script runtime. The default SBT channel configuration will remain unchanged. If there is a local tape MML in place, jobs that use that service will continue to function normally without modification.

RMAN> allocate channel t1 type sbt

2> parms 'ENV (OSB WS PFILE /u01/oracle/product/11.1/db 1/dbs/osbwst1.ora), 3> SBT LIBRARY /u01/oracle/product/11.1/db 1/lib/libosbws11.so';

The following RMAN script demonstrates how to manually allocate an SBT I/O channel to S3

using the OSB Cloud Module, then perform a full backup of the database including the archived redologs.

RMAN> run {

2> allocate channel t1 type sbt

3> parms='ENV=(OSB WS PFILE=/u01/oracle/product/11.1/db 1/dbs/osbwst1.ora), 4> SBT LIBRARY=/u01/oracle/product/11.1/db 1/lib/libosbws11.so';

5> backup database plus archivelog;

6> }

allocated channel: t1

channel t1: SID=133 device type=SBT TAPE

channel t1: Oracle Secure Backup Web Services Library

Starting backup at 27 OCT 09

channel t1: starting full datafile backup set

channel t1: specifying datafile(s) in backup set

input datafile file number=00002 name=+DG1/t1/datafile/sysaux.257.700422031

input datafile file number=00001 name=+DG1/t1/datafile/system.256.700422031

input datafile file number=00003 name=+DG1/t1/datafile/undotbs1.258.700422031

input datafile file number=00004 name=+DG1/t1/datafile/users.259.700422031

channel t1: starting piece 1 at 27 OCT 09

channel t1: finished piece 1 at 27 OCT 09

piece handle=03ksrndv 1 1 tag=TAG20091027T133142 comment=API Version 2.0,MMS Version 2.0.0.0

channel t1: backup set complete, elapsed time: 00:02:35

...

Finished backup at 27 OCT 09

released channel: t1

150
Part II: Setup Principles and Practices

The exact syntax for allocating the SBT channel to S3 varies between Oracle versions. For instance, Oracle 11
g
R2 does not accept the ENV keyword. Instead you must use an alternate channel allocation syntax using the SBT_PARMS keyword. On some versions, you may also have to create a symbolic link in ORACLE_HOME/lib called libobk.so pointing to libosbws11.so: $ ln -s $ORACLE HOME/lib/libosbws11.so $ORACLE HOME/lib/libobk.so

Listing RMAN Backups and Backup Sets Stored on S3

As with all RMAN backups, all management of stored backups must be performed with RMAN. If you manually delete backup sets, future RMAN recoveries will continue to assume that they exist.

RMAN must be used to mark as obsolete and to purge all RMAN backups.

Similarly, listing and reporting existing backups is best performed via RMAN. For example, the following command lists all backups stored on an SBT device (such as S3 via the OSB Cloud Module) in the past 24 hours:

RMAN> list backup device type sbt completed after 'sysdate-1';

List of Backup Sets

BS Key Type LV Size Device Type Elapsed Time Completion Time

1 Full 1.17G SBT TAPE 00:02:34 27-OCT-09

BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG20091027T133142

Handle: 03ksrndv 1 1 Media:

List of Datafiles in backup set 2

File LV Type Ckp SCN Ckp Time Name

1 Full 1515937 27-OCT-09 +DG1/t1/datafile/system.256.700422031

2 Full 1515937 27-OCT-09 +DG1/t1/datafile/sysaux.257.700422031

3 Full 1515937 27-OCT-09 +DG1/t1/datafile/undotbs1.258.700422031

4 Full 1515937 27-OCT-09 +DG1/t1/datafile/users.259.700422031

Several third-party tools exist for browsing the contents of your S3 buckets, where the OSB

Cloud Module stores RMAN backups. One popular such tool is a Firefox browser add-on called S3fox. Using S3fox, you can browse the backup pieces RMAN stores in S3.

Optimizing Backups and Recoveries over the Internet

Using the OSB Cloud Module and Amazon S3

The effectiveness of backing up and restoring Oracle database backups over the Internet to Amazon S3 depends on a number of factors:

■ Size of database

■ Redo generation rate

■ Internet bandwidth between the Oracle server and Amazon S3

■ Backup strategy

■ RMAN options

■ Requirements for time-to-recovery

Chapter 6: Backing Up to Amazon Web Services Using the Oracle Secure Backup Cloud Module
151

Very large databases not hosted in the Amazon cloud may be poor candidates for backup to Amazon S3 over the Internet in Q1 2010 given typical observed network speeds and performance.

It could simply take too long to complete a backup and too long to restore in the event of a recovery. For the same reason, databases that generate very large amounts of redo per day may be poor candidates for this backup strategy. Amazon Web Services has reliable fast connectivity to S3, so databases hosted on Amazon EC2 can use the OSB Cloud Module without as much tuning and optimization.

For example, a level 0 backup of a database of 500GB that generates 50GB of redo per day might compress to 250GB. With a single T1, it might take over 50 hours to back up to S3, using most of the available network capacity. For this reason, you must carefully consider and test network throughput and compressed backup size when contemplating moving to an S3-based backup strategy over the Internet. The longest backup window in the backup cycle must be able to accommodate a level 0 backup, while using a percentage of the network resources that is acceptable to the enterprise.
Additionally, organizations must determine if the amount of time
to perform a complete restore from S3 is acceptable to the enterprise.

Because of the many caveats associated with deploying backups over the Internet to S3, any organization contemplating it should rigorously test both backup and recovery performance before embarking on a large-scale migration to this architecture.

Regardless of database size, customers using the OSB Cloud Module can optimize backup capacity and performance using a variety of means. By improving backup efficiency, larger databases can be backed up to S3 over the Internet than would otherwise have been possible.

The main approaches are

■ Using multiple SBT channels

■ Backing up during times of minimal Internet use

■ Using compressed backup sets

■ Using an incremental backup strategy

■ Backing up archive logs frequently

Sites contemplating an Oracle backup strategy over the Internet to Amazon S3 must have sufficient Internet bandwidth to back up the databases in question within an acceptable backup window. If sufficient bandwidth is available, the challenge becomes configuring RMAN to consume those resources. An effective way to maximize the use of network resources is opening multiple SBT channels. In testing, the goal should be to use sufficient network resources to complete the backup within the required timeframe, while leaving resources available for other services and purposes.

To minimize the impact to other users and services, Oracle backups to Amazon S3 should be scheduled for periods of minimal network use. The quantity of data transferred can be further reduced with compressed backup sets.

An incremental backup strategy can additionally reduce the daily backup size that must be written to Amazon S3. In most databases, only a small portion of the data changes on a daily, weekly, or even monthly basis. Therefore, full or level 0 backups can conceivably be taken very infrequently and can even be spread over the period of a whole night or a whole weekend.

On a nightly or weekly basis, differential and incremental backups can be used to maintain recoverability while keeping the backup size small.

152
Part II: Setup Principles and Practices

Example with Multiple Channels and Compressed Backup Sets

The following RMAN script demonstrates typical syntax for opening multiple channels to Amazon S3 using the OSB Cloud Module, then performing a full (level 0) compressed backup including archived redo logs over those channels.

RMAN> run {

2> allocate channel t1 type sbt

3> parms 'ENV (OSB WS PFILE /u01/oracle/product/11.1/db 1/dbs/osbwst1.ora), 4> SBT LIBRARY /u01/oracle/product/11.1/db 1/lib/libosbws11.so';

5> allocate channel t2 type sbt

6> parms 'ENV (OSB WS PFILE /u01/oracle/product/11.1/db 1/dbs/osbwst1.ora), 7> SBT LIBRARY /u01/oracle/product/11.1/db 1/lib/libosbws11.so';

8> allocate channel t3 type sbt

9> parms 'ENV (OSB WS PFILE /u01/oracle/product/11.1/db 1/dbs/osbwst1.ora), 10> SBT LIBRARY /u01/oracle/product/11.1/db 1/lib/libosbws11.so';

11> backup as compressed backupset incremental level 0 database plus archivelog;}