How to Protect Amazon RDS Custom for Oracle Data with Druva
By Jesse Kachapis, Director, Product Architecture – Druva
By Andrey Ivanov and Nick Stachniak, Solution Architects – Druva
By Keith Joelner, Solutions Architect – AWS
By Fernando Armenta, Technical Account Manager – AWS
As more workloads move to Amazon Web Services (AWS), secure and robust solutions are needed for backing up AWS managed services such as Amazon RDS Custom for Oracle.
In this post, we will walk through how fast and easy it is to protect your data securely with Druva, an AWS Competency Partner and software-as-a-service (SaaS)-based platform to protect and manage enterprise data across endpoints, data centers, and native cloud workloads. We’ll also demonstrate how Druva can be configured to back up Amazon RDS Custom safely and securely.
The Druva solution can be used when migrating from on-premises and hybrid architectures to Amazon RDS Custom for Oracle, a managed database service for legacy, custom, and packaged applications. This AWS service can be used with any application that requires access to the underlying operating system (OS) and database environment.
Amazon RDS Custom for Oracle automates the setup, operation, and scaling of databases in the cloud while granting access to the database and underlying OS to configure settings, install patches, and enable native features to meet the dependent application’s requirements.
The following diagram shows an overview of Druva’s hybrid workload protection solution for Amazon RDS Custom for Oracle.
Figure 1 – Overview of protecting RDS Custom with Druva.
The Druva backup uses an agent for management and communication with Druva Cloud. The agent installation is often quick and has been completed in as little as five minutes.
An administrator will need to download a Druva RPM package to the operating system of the Amazon RDS Custom instance on Amazon Elastic Compute Cloud (Amazon EC2).
Before the RPM is installed, the database administrator must put the RDS Custom for Oracle database instance into a “paused” mode for a designated period.
The RPM is installed and activated with two command line arguments—the first loads and activates the agent into the OS, and the second registers the agent and its server in the Druva console.
Once the agent is deployed, the Oracle administrator may create an Oracle direct-to-cloud (DTC) backup policy which is a schedule of backups the agent will run. These backups will include the database, archive log, control, and server-side parameter files.
Figure 2 – Pause the default AWS backup automation.
The AWS Management Console puts the database in paused or maintenance mode as opposed to full automation, which is the standard in Amazon RDS Custom.
The following shows a sample deployment of the DTC software from the download RPM.
Install the RPM using the -ivh command line argument while connected to the Amazon RDS Custom instance root.
The deployment starts the agent installation of the RPM, and one additional command line argument is required to activate the agent in the Druva console.
Example: rpm -ivh druva-phoenix-oracle-client-6.0.0-179689.x86_64.rpm
Example: PhoenixOracleActivate eyJUb2tlbiI6IjAwOGI4MDVmNzdkOWRmMjkxM2FhYWFiZmI1YzNmMzgzMTlmODkzOGNjYjZhMDQyMGRhZDBmNGJjNzVhNGY2YTQiLCJUb2tlbklEIjo1ODU1MywiQ3VzdG9tZXJJRCI6MzAzNiwiUHJvZHVjdElEIjoxMjI4OSwiU2l0ZUlEIjo3Njk0LCJDb29raWUiOjB9
Figure 3 – Druva Console showing list of Oracle servers being protected.
The token used in this example was generated in the Druva console on the Oracle server page by clicking the Register Server button.
Figure 4 – Druva agent download and token creation.
The token registration takes you to the next page, where the token is generated by clicking the Generate new token button.
Figure 5 – Druva Console showing registered oracle databases list.
The server will then be displayed in the Oracle Servers list; this allows the administrator to register the agent with the database.
The administrator clicks on the All Databases menu on the left and chooses the assigned key symbol that the agent places on this page after discovery.
Figure 6 – Three modalities for authentication of OS, database, and wallet.
The administrator chooses the authentication method and clicks the Save button. If a recovery catalog is used, the Enable Recovery Catalog toggle button is selected the user ID and password are required for inputs.
Figure 7 – Configuring a new backup policy in the Druva console.
The final step is to create a backup policy in the Oracle DTC Druva console. When the administrator checks the box by the database name they just assigned credentials, the Configure for Backup button goes dark blue. Click this button to move to the next page.
Figure 8 – Backup policy settings.
The New Backup Policy button is selected, and the administrator inputs the values prompted.
If you examine an existing backup policy you’ll see values for the Policy Name, Backup Schedule, Retention, and RMAN settings for the database. The administrator can set up a custom policy for each database or generic policy assignable to many databases.
The following screenshots show all of the required inputs for configuration.
Figure 9 – Backup scheduling, top, and retention and RMAN settings.
All fields are editable by selecting the edit button for the fields. One benefit of this solution is that in the case of a database migration, all that’s required is to install and activate the agent on the new AWS instance.
This allows a database administrator (DBA) to use multiple backup/restore methods. The Oracle DTC can be redirected and restored to an alternate node host, a download of backup sets created by RMAN to a new destination, and then invoke RMAN to restore manually.
Because all Druva backups are stored in the Druva Cloud, the agent and its activation on a host on-premises or in the cloud makes them accessible anywhere in the world.
As a test, we will destroy and remove a test Oracle database named DEVDRVA3 on our Amazon RDS Custom instance. We’ll then restore the database using the Druva console with its proprietary point-and-click menus that walk administrators through the database restore process.
Figure 10 – Selecting the test (dev21c1) database for restore.
To start the restore process, on the Configured Databases menu select the database by clicking beneath the database name and then selecting the Restore button. You will then be taken to the restore page.
Figure 11 – Database restoration page with point-in-time recovery.
The database in our example allows a snapshot restore of all RMAN backups to a disk destination or a point in time. Snapshots are downloadable to the original node or an alternate node in a cloning situation, as shown in the screenshot above.
To proceed, click the Restore button to advance to the next page for additional prompts in the restore process.
Figure 12 – Database restoration options popup.
Selection of the first option in the screenshot above launches a restore of the database configured for backup via the Druva agent. The second option allows configuring an alternate host or destination to download the backup sets and perform a command line restoration using RMAN.
Once the Finish button is clicked, the restore operation starts on any host where the agent is registered and running.
The Amazon RDS Custom for Oracle database offering is easy to use and can configure a backup for an Oracle database quickly and simply. This affords a database administrator access to the host Amazon EC2 instance in a manner that does not exist in the standard RDS environment.
The robust nature of Amazon RDS Custom for Oracle provides multiple layers of protection from the native AWS backups as well as those provided by the Druva Cloud platform.
If you have highly customized or specific data protection needs such as long-term data retention, then a solution like the Oracle DTC data protection framework combined with Amazon RDS Custom is the best of both worlds.
Druva – AWS Partner Spotlight
Druva is an AWS Competency Partner and cloud-based data protection company that delivers cyber, data, and operational resilience via a single SaaS platform running on AWS.