Your databases hold your company’s most critical assets, including customer information, corporate financials, human resources information, and other critical data sources. In today’s constantly connected global business environment, you need a cost-effective and reliable strategy for protecting your data from disasters. Good data protection practices require keeping usable business-critical backups offsite. This has traditionally been implemented by writing backups to tape and storing the tapes offsite.
A good alternative is to have the Oracle backups created at an onsite object storage with cross region replication to any offsite location such as a cloud provider or another datacenter in a different region based on ILM policies. This may potentially reduce the overall TCO by half with benefits that include easy provisioning of DEV/Test in the cloud or remote datacenter and protection against media failure and other forms of disaster.
The overall pricing and operational characteristics of cloud object storage like Amazon s3 and Azure Blob make it a compelling alternative to shipping tapes offsite. Good cloud infrastructure offers storage redundancy, security, availability, and scalability with a geographic distribution that allows it to absorb a broad range of adverse events with minimal to no loss of availability. However, the only objection to over-the-network cloud backup is that limited network bandwidth can slow the transfer of large volumes of data, such as a full backup of a large production Oracle database.
NetApp StorageGRID® is an industry-leading object storage software solution that can address both of these needs. This method offers a hybrid cloud solution that provides benefits like high reliability, continuous accessibility, unlimited scaling, and reduced offsite storage cost, while retaining the native capabilities of Oracle RMAN, like built-in encryption and compression.
Amazon Web Services (AWS) is the first cloud vendor that Oracle has partnered with to directly write database backups to Amazon S3 object storage. The Oracle Secure Backup Cloud Module has a jar file that helps to configure the library and wallet keys required for the RMAN SBT interface to write the backups to Amazon S3 or S3-compatible storage like NetApp StorageGRID.
Configure Cloud Module and Write Backups to StorageGRID in Five Steps
It is a simple five-step process to configure the overall Cloud Module and write backups to StorageGRID.
- Download the package from Oracle site and unzip. The download contains a jar file that should be executed by an Oracle user.
- Create the directory osbws_wallet in $ORACLE_HOME/dbs. This location is used for storing the wallet keys needed to access the StorageGRID tenant account’s bucket.
- Finally, execute the jar file with the following mandatory parameters:The AWSID and AWSKey parameters refer to the access ID and access key needed to access a specific tenant in StorageGRID. The location parameter must always be us-east-1 because this is the default location passed for the StorageGRID no matter what Geo is being used. This parameter might differ for other cloud object stores. The awsEndpoint parameter represents the load balancer endpoint URL (could be HTTP or HTTPS) needed to access the bucket. You can also host multiple URLs to access the objects in the bucket with an appropriate record in the DNS and a self-signed or commercial certificate. While creating a load balancer endpoint, StorageGRID allows you to either generate your own self-signed certificate or upload a commercial certificate. If you are using a self-signed certificate, then you must verify that it is trusted by the Oracle host; otherwise, the jar file execution fails. The following example demonstrates how to use keytool to import your self-signed certificates so that they are trusted. Use the -file parameter to pass the self-signed certificate that was generated by StorageGRID.xxx
- After jar execution is successful, you can see that four files were automatically created by Oracle: three files in the $ORACLE_HOME/dbs location, two of which are related to keys in the osbws_wallet directory, and one initialization file osbws.ora recording the host details and wallet location.The fourth file is a library used by RMAN that is generated in the $ORACLE_HOME/lib directory with the name libosbws.so.
- Finally, execute the RMAN command to test sending the Oracle backups directly to StorageGRID.The bucket is automatically created by RMAN. You can use the S3 browser or any third-party tools to check the objects in the StorageGRID tenant bucket.You can also list the backup for more details in RMAN because it has cataloged the metadata of the backup pieces or backupset. You can look for the Media parameter in the list backup to know whether the backup is in S3 or any other S3-compatible storage.
The following best practices can help you to drive better RMAN performance during backups and/or restore:
- Use multiple RMAN channels for higher parallelism resulting in full utilization of the network.
- Compression helps overcome the network bandwidth limitations and can improve performance.
- Use multi-section backups. Oracle Database allows multiple channels to back up a single file in parallel with the help of section size parameter: BACKUP DEVICE TYPE SBT DATABASE SECTION SIZE 1g;
- Use the RMAN Block Change Tracking feature to optimize the performance of your daily incremental backups.
- Backup of an on-premises database to StorageGRID can be much faster and more efficient than directly backing up to cloud object storage. Optionally, you can use a cloud mirror if you want to replicate cold objects to a cloud object store, based on your ILM policies.
- If you are using an active Oracle Data Guard instance for your production database, then you should leverage that instance to run incremental RMAN backups more quickly.
Benefits of Using NetApp StorageGRID for Database Backups
Multiregion cluster, single namespace.
StorageGRID can have clusters that span geographically dispersed data centers while maintaining a single namespace. Oracle data backups ingested in one region are automatically replicated and available in other regions. If one region becomes unavailable, then data is automatically served to clients and applications from the other region. Because this is a single namespace, clients and applications do not have to change the way they access data.
Enterprise database customers can use StorageGRID in both ways. They can store an offsite copy of their backup (DR site), or they can have workflows that span multiple regions so that data is widely available.
Deterministic placement of data.
You can specify how many replicas of data backups you want in each region. Enterprise customers can define ILM policies that allow customers to specify replicas in the primary and other data centers.
This is a method for data protection in which the data is broken up into fragments and then encoded with redundant (parity) fragments. Erasure coding is generally a more space-efficient method (relative to replication) for protecting data in object storage systems. You can also apply StorageGRID erasure coding policies to multi-region clusters. Therefore, if there is a loss of one or more nodes or multiple drives, you can still serve objects without retrieving fragments from other regions.