Demystifying AWS Backup for Amazon RDS for Oracle

Customers prefer to host their relational database workloads in a managed service such as Amazon Relational Database Service (Amazon RDS) because of the benefits offered by managed services. Although Amazon RDS offers automatic backups as a native feature, your data retention policies may require longer retention periods than the retention policy supported by Amazon RDS. That’s where AWS Backup comes to the rescue. AWS Backup provides a centralized and simplified approach to backup management, allowing you to streamline your RDS database backups and gain greater control and flexibility over your data protection strategy.

In this post, we explore the benefits and features of AWS Backup specifically tailored for RDS instances. We explore how it simplifies backup operations, enhances data protection, and enables you to meet your recovery objectives efficiently. Additionally, we provide comprehensive instructions on the configuration, customization, and compliance of your backups.

Solution overview

With Amazon RDS automatic backups, you can specify a retention period of 0–35 days, and enable or disable automatic backups for your RDS instances. The backups are taken daily during a configurable backup window if the retention period is set to greater than or equal to 1, and you cannot adjust the backup frequency or retention settings beyond the available options. AWS Backup provides more flexibility in backup configuration. You can define custom backup schedules, retention periods, and backup lifecycle policies based on your specific requirements. It allows you to create granular backup policies and adjust settings according to your business needs.

In the following sections, we demonstrate how to back up an RDS database using AWS Backup. We move our RDS database from automated Amazon RDS backups to AWS Backup with a daily backup retained for 35 days and a monthly backup retained for 1 year.

Create a backup vault

To create a backup vault, complete the following steps:

On the AWS Backup console, choose Create backup vault.
For Backup vault name, enter a unique name for the vault.
For Encryption key, choose an AWS Key Management Service (AWS KMS) key for your backup encryption. For this post, we use the default key.
Choose Create backup vault.

You can also create the backup vault programmatically. The following AWS Command Line Interface (AWS CLI) command creates the backup vault in the same way:

aws backup create-backup-vault --backup-vault-name aws-backup-blog-value

Configure a backup plan

To configure your backup plan, complete the following steps:

On the AWS Backup console, choose Backup plans in the navigation pane.
Choose Create backup plan.
Select your backup plan option (you can start with a template, build a new plan, or define a plan using JSON). For this post, we select Start with a template.
Choose your template. For this post, we choose Daily-Monthly-1yr-retention.
You can amend the entries after the template is loaded.
For Backup plan name, enter a unique name. For this post, we use aws-backup-blog-plan.
We now amend the backup rules to change the backup vault to the one we created in the previous step.
Choose Add backup rule.
For Backup vault, choose the vault you created.
Select Enable continuous backups for point-in-time recovery (PITR).
This setting means that the Amazon RDS automated backup feature is managed by the AWS Backup service itself.
Make any additional adjustments to your rule and choose Create Plan.
After you have updated the daily rule, choose Save.
Amend the monthly backup to start on day 20 of every month, then choose Save.

Now we must assign resources to the plan. You have the flexibility to add all resources, only specific resources, or even select or exclude resources using tags.
For this post, select Include specific resource types.
For Resource type¸ choose RDS.
For Database names¸ choose your database (blog-aws-backup).
Choose Assign resources.

After you have configured your backup rules and assigned resources, you can view the plan details on the AWS Backup console.

You can set up the same configuration programmatically, using JSON documents and the AWS CLI. The following JSON document contains the specifics of aws-backup-blog-plan:

  {
    "BackupPlan":{
      "BackupPlanName":"aws-backup-blog-plan",
      "Rules":[
        {
          "RuleName":"DailyBackups",
          "TargetBackupVaultName":"aws-backup-blog-value",
          "ScheduleExpression":"cron(0 5 ? * * *)",
          "StartWindowMinutes":400,
          "CompletionWindowMinutes":10080,
          "Lifecycle":{
            "DeleteAfterDays":35
          },
          "EnableContinuousBackup": true
        },
        {
            "RuleName":"Monthly",
            "TargetBackupVaultName":"aws-backup-blog-value",
            "ScheduleExpression":"cron(0 5 20 * ? *)",
            "StartWindowMinutes":60,
            "CompletionWindowMinutes":120,
            "Lifecycle":{
              "DeleteAfterDays":365
            }
          }        
      ]
    }
  }

Assuming you store the preceding JSON document as test-backup-plan.json, you can use the following command to create the backup plan in AWS Backup:

$ aws backup create-backup-plan --cli-input-json file:////home/test-backup-plan.json

The following JSON document contains the resource assignment specifications to the backup plan BACKUP-PLAN-ID; this is the plan ID returned by the previous command:

 {
    "BackupPlanId":"BACKUP-PLAN-ID",
    "BackupSelection":{
      "SelectionName":"aws-backup-blog-resources", 
      "IamRoleArn":"arn:aws:iam::<aws-account-id>:role/service-role/AWSBackupDefaultServiceRole",
      "Resources":[
        "arn:aws:rds:<aws-region>:<aws-account-id>:db:blog-aws-backup"
      ]
    }
  }

Assuming this JSON is stored as backup-selection.json, you can assign these resources to your backup plan using the following command:

$ aws backup create-backup-selection --cli-input-json file:////home/backup-selection.json

Monitor backup jobs

To monitor your backup job, complete the following steps:

On the AWS Backup console, choose Jobs in the navigation pane.
You can filter by your specific resource name (in our case, blog-aws-backup) to view the successful runs of your job.
To view your recovery points, choose Backup vaults in the navigation pane and choose the vault you created.
Note that the Recovery point ID value with the prefix awsbackup: and Backup type as Snapshot is related to the manual snapshot managed by the AWS Backup Monthly backup rule. The ID with the prefix continuous: and Backup type as Continuous is related to the DailyBackups backup rule, which we activated for continuous backups for PITR. As previously mentioned, when you activate this option, AWS Backup takes control of the Amazon RDS automated backup feature.
To verify this, on the Amazon RDS console, navigate to the Maintenance & backups tab for the specific RDS instance.You will see a message similar to the following screenshot.

From a recovery perspective, creating a restore of the instance is straightforward. You have the option to select a continuous restore point ID to perform a PITR or select a snapshot restore point ID to run a snapshot restore.
For this post, select the snapshot restore point ID and on the Actions menu, choose Restore.

After making your selections, you are presented with options to choose the characteristics of the restored instance.
After you finalize your choices, initiate the restore process by choosing Restore backup.

You can observe the restore job being initiated.

You will also see a database created on the Amazon RDS console, which confirms that you restored the recovery point to blog-aws-backup-restore.

When the restore is complete, the job status changes to Completed.

(Optional) Configure a vault lock

Configuring the vault lock is an optional feature that can give you additional security and control over your backup vaults. Each vault can have one vault lock in place.

On the AWS Backup console, choose Create vault lock.
For Backup vault, choose the vault you created earlier.
Set your vault lock mode:
1. Governance mode – This mode gives access to specific users to manage backup retention. For this post, we select this option.
2. Compliance mode – When a lock is active in compliance mode and the retention time is over, the vault configuration cannot be altered or deleted by a customer, account or data owner, or AWS.
You can optionally configure addition retention periods on top of what you set in the backup plan.
Choose Create vault lock.
Enter confirm, select the acknowledgement check box, and choose Create.

You will now see that the vault is locked.

To configure a vault lock programmatically, use the API PutBackupVaultLockConfiguration. The parameters to include will depend on which vault lock mode you want to use. If you create a vault lock in governance mode, do not include ChangeableForDays. If this parameter is included, the vault lock will be created in compliance mode.

For this post, we create a vault lock in governance mode with the following code:

$ aws backup put-backup-vault-lock-configuration \
        --backup-vault-name aws-backup-blog-value \
        --min-retention-days 7 \
        --max-retention-days 30

Copy backups across AWS Regions

With AWS Backup, you can copy backups to multiple Regions either on demand or automatically as part of a scheduled backup plan. This cross-Region replication proves particularly advantageous when adhering to business continuity or compliance requirements necessitating backups to be stored at a minimum distance from production data.

When you copy a backup to a new Region for the first time, AWS Backup performs a full backup replication. Subsequent copies of the same backup within the same target Region become incremental. Furthermore, AWS Backup verifies the re-encryption of your copied data using the customer-managed key of the destination vault.

AWS Backup also allows you to perform backups to multiple AWS accounts, either on demand or through automated scheduling in a backup plan. In a later post, we’ll provide a more comprehensive explanation of this feature.

Currently, Amazon RDS does not support a single copy action that enables both cross-Region and cross-account backup simultaneously. You must choose one option or the other. However, you can use a workaround, described in Protecting encrypted Amazon RDS instances with cross-account and cross-Region backups, using an AWS Lambda script. The script can listen for the completion of the initial copy, perform the second copy to the desired AWS account or Region, and then delete the first copy.

To schedule a cross-Region backup copy, complete the following steps:

Select the backup rule within your backup plan for which you wish to enable the cross-Region backup copy feature, in this case the Monthly rule, then choose Edit.
For Copy to destination, choose the destination Region for your backup copy.
For this post, do not enable Copy to another account’s vault.
For Destination Backup vault¸ choose the backup vault located in the destination Region where AWS Backup will store the copied backup.
In this particular scenario, we create a new backup vault to facilitate cross-Region copy.
Choose Create new Backup vault.
For Backup vault name, enter a name (for this post, aws-backup-blog-xvault).
For Encryption key, enter your customer-managed key (aws-backup-blog-key).
Choose Create backup vault.
Choose Save.
Check the copy configuration on the Monthly backup rule detail page.

The following screenshot shows the backup vault detail page.

You can set up the same configuration programmatically using JSON documents and the AWS CLI. The following JSON document contains the specifics to update aws-backup-blog-plan:

{
    "BackupPlan":{
      "BackupPlanName":"aws-backup-blog-plan",
      "Rules":[
        {
          "RuleName":"DailyBackups",
          "TargetBackupVaultName":"aws-backup-blog-value",
          "ScheduleExpression":"cron(0 5 ? * * *)",
          "StartWindowMinutes":400,
          "CompletionWindowMinutes":10080,
          "Lifecycle":{
            "DeleteAfterDays":35
          },
          "EnableContinuousBackup": true
        },
        {
            "RuleName":"Monthly",
            "TargetBackupVaultName":"aws-backup-blog-value",
            "ScheduleExpression":"cron(0 5 20 * ? *)",
            "StartWindowMinutes":60,
            "CompletionWindowMinutes":120,
            "Lifecycle":{
              "DeleteAfterDays":365
            },
            "CopyActions": [
                {
                  "Lifecycle": {
                    "DeleteAfterDays": 35
                  },
                  "DestinationBackupVaultArn": "arn:aws:backup:<aws-region>:<aws-account-id>:backup-vault:aws-backup-blog-xvault"
                }
            ]
          } 
      ]
    }
  }

Assuming you store the preceding JSON document as test-backup-plan.json, you can run the following command to update the backup plan:

$ aws backup update-backup-plan --backup-plan-id "BACKUP-PLAN-ID" --cli-input-json file:////home/test-backup-plan.jso

Clean up

The retention period defined in the AWS Backup rules cleans up expired RDS instance backups. For a complete cleanup of the environment configured for this post, complete the following steps:

Delete the DB instance blog-aws-backup-restore, which you restored from a recovery point.
Remove the vault lock aws-backup-blog-value.
Delete the resource assignment aws-backup-blog-resources from aws-backup-blog-plan.
Delete the backup plan aws-backup-blog-plan.
Delete all the backups in the aws-backup-blog-value backup vault.
Delete the backup vault aws-backup-blog-value.
Delete the aws-backup-blog-xvault backup vault in the secondary Region that you configured for the cross-Region copy.

Amazon RDS backup and AWS Backup

Let’s run through the primary commonalities and distinctions between the backup options available inside Amazon RDS itself and the functionalities provided by AWS Backup. This post centers its attention primarily on Amazon RDS for Oracle. It’s worth noting that these principles can be seamlessly extended to the other available engines: Amazon RDS for MySQL, Amazon RDS for MariaDB, Amazon RDS for PostgreSQL, and Amazon RDS for SQL Server.

Data protection

Amazon RDS does encrypt your RDS DB instances. Data that is encrypted at rest includes the underlying storage for DB instances, its automated backups, read replicas, and snapshots. Amazon RDS uses a KMS key to encrypt these resources. You can use an AWS managed key, or you can create customer managed keys. To manage the customer managed keys used for encrypting and decrypting your Amazon RDS resources, you use AWS KMS.

Within AWS Backup, a backup vault is a container that stores and organizes your backups. When establishing a backup vault, it’s necessary to designate the KMS encryption key that encrypts some of the backups placed in this vault (independent AWS Backup encryption). For Amazon RDS, independent AWS Backup encryption is not supported. Instead, RDS snapshots are automatically encrypted with the same encryption key that was used to encrypt the source RDS database. Consequently, snapshots of unencrypted RDS databases remain unencrypted. This principle extends to Aurora cluster snapshots. Be aware that AWS managed keys are not supported for AWS Backup cross-account backup. For further insights into this particular subject, refer to How encryption works in AWS Backup.

AWS Backup introduces a feature, AWS Backup Vault Lock, which can be helpful in giving you additional security and control over your backup, bolstering data integrity by helping prevent accidental or unauthorized deletions of backups. When it comes to separation of duties, both services enable the allocation of roles and permissions, but the centralized nature of AWS Backup streamlines this process, promoting clearer access control. In essence, although both Amazon RDS and AWS Backup uphold high standards of data security, the latter introduces enhancements like vault locks and centralized role management, further strengthening data protection measures.

Cost

The cost distinction between the backup capabilities offered by Amazon RDS and those facilitated through AWS Backup revolves around their operational models. Amazon RDS provides automated backups as an integral part of its service, incurring no additional charges for the feature itself. The cost of a retained automated backup is the cost of the total storage of the system snapshots that are associated with it. The same applies to the manual snapshots that are always incremental. Conversely, AWS Backup offers a centralized management solution that covers multiple AWS services, including Amazon RDS. Regarding AWS Backup and Amazon RDS, the charges are the same as what you would incur if you were using automated backups for Amazon RDS.

Whether you’re using Amazon RDS or AWS Backup, you won’t incur backup storage costs as long as the cumulative backup storage remains below 100% of your total database storage size within a given Region. Moreover, there are no supplementary fees for transaction log backups. For further insights into the calculation of Amazon RDS backup costs, see Demystifying Amazon RDS backup storage costs.

When it comes to Amazon RDS cross-Region automated backups and DB snapshot copy, as well as AWS Backup cross-Region backups, data transfer costs only arise when moving data out of a Region, with no fees for transfers within the same Region. Additionally, charges are applied for the storage of backups copied in the destination Region.

Features

Let’s dig deeper into a comparison between the primary backup features offered by Amazon RDS and AWS Backup for Amazon RDS:

Continuous backups and PITR transaction log backups – Both AWS Backup and Amazon RDS use the same mechanism for running continuous database backups and point-in-time-recovery (PITR), with a shared maximum retention period of 35 days. If you use AWS Backup for both Amazon RDS snapshots and continuous backups, AWS Backup will intelligently schedule your backup windows, along with the Amazon RDS maintenance window, to help prevent conflicts. You no longer have to manually schedule one backup window hours before another. You can’t control the Amazon RDS automated backup window.
Database snapshots – Amazon RDS requires manual snapshots or custom automation for database snapshots taken outside the automated backup PITR. In contrast, AWS Backup rules enable you to schedule database snapshots with customizable frequencies, such as daily, weekly, or monthly.
Database snapshot retention – Amazon RDS necessitates manual deletion of outdated database snapshots, whereas AWS Backup offers a more agile approach by allowing you to configure a retention period in addition to the snapshot frequency.
Cross-Region backup copies – AWS Backup permits configuration of cross-Region backup copies for both continuous PITR backups and database snapshots. When a cross-Region copy of a continuous backup is made, the copied recovery point (backup) becomes a snapshot (periodic) backup. PITR is not available for these copies. For Amazon RDS, automated backup copies can be automated across Regions, whereas manual snapshot copies require extra configurations.
Cross-account backup copies – AWS Backup enables setup of cross-account backup copies for both continuous PITR backups and database snapshots. When a cross-account copy of a continuous backup is made, the copied recovery point (backup) becomes a snapshot (periodic) backup. Amazon RDS requires manual implementation to automate the cross-account backup copy.
Monitoring – Both Amazon RDS and AWS Backup send events to Amazon CloudWatch Events and Amazon EventBridge, which facilitate monitoring through Amazon Simple Notification Service (Amazon SNS) subscriptions. AWS Backup further offers cross-account monitoring capabilities for policies and associated jobs in the management account, enhancing monitoring efficiency.
Cost monitoring – With cost allocation tags, you can effectively track and optimize backup costs for both AWS Backup and Amazon RDS.

Conclusion

In this post, we provided a comprehensive comparison highlighting the capabilities of Amazon RDS and AWS Backup in terms of data protection, cost, and backup features. We showed how to switch your automated Amazon RDS backups to use AWS Backup with extended retention periods. We also showed how to stop those backups from being removed by using a vault lock and how to implement backup copies across Regions.

By using AWS Backup for your Amazon RDS backups, you can simplify your backup operations, achieve greater control over backup configurations, and enhance your data protection and disaster recovery capabilities. Join us in future posts as we explore the various features and benefits of AWS Backup, empowering you to safeguard your RDS databases effectively.

For more information about AWS resources and third-party applications supported by AWS Backup and the features available, see Feature available by resource.

About the authors

Tony Mullen is a Senior Database Specialist Solutions Architect based in Manchester. With a focus on relational database engines, he assists customers in migrating and modernizing their database workloads to AWS.

Giorgio Bonzi is a Senior Database Specialist Solution Architect based in Milan. With a focus on the Oracle database engine, he provides guidance and technical assistance to customers to help them design, deploy, and optimize relational database workloads on AWS.