Using AWS Backup and Oracle Fast Recovery Area on Amazon FSx for NetApp ONTAP for backup/restore of Oracle databases on Amazon EC2

As data grows exponentially, organizations running Oracle databases prioritize minimizing backup time and quicker recovery times in the event of disasters. Oracle databases on Amazon Elastic Compute Cloud (Amazon EC2) often configure an Oracle Fast Recovery Area (FRA) to fulfil data protection, disaster recovery, and compliance requirements.

The FRA is a centralized, Oracle-managed storage location that streamlines backup and recovery management by automatically storing, organizing, and managing all database recovery-related files in a single, unified area, reducing administrative overhead and enhancing recovery speed. To further strengthen this backup strategy, AWS Backup provides an ideal complementary solution, particularly for EC2 instances hosting Oracle databases. This fully managed service automates the backup process, integrates with other AWS services, and allows for flexible backup scheduling and retention policies, making sure of data durability and compliance.

In this post, we detail a two-pronged backup strategy for Oracle databases running on EC2 instances as shown in figure 1. The approach combines: (1) FRA configured on Amazon FSx for NetApp ONTAP for short-term recovery needs (<30 days), enabling rapid point-in-time restoration using Oracle native tools, and (2) AWS Backup for long-term retention (>30 days) of full database backups. This dual solution empowers Oracle Database Administrators with both immediate recovery capabilities and comprehensive long-term backup protection.

Figure 1: Dual backup strategy timeline and coverage model.

Solution overview

Figure 2 demonstrates the workflow:

1. Oracle database on Amazon EC2 configured with Amazon Elastic Block Store (Amazon EBS) for Oracle Data and Log files.
2. AWS Backup service to backup EC2 instances at regular intervals.
3. FRA directory mounted to an FSx for ONTAP volume for storing Oracle archives and FRA backups.

Figure 2: Oracle database in Amazon EC2 using AWS Backup and FSx for ONTAP for backup and restore

Prerequisites

The following prerequisites are needed to continue with this post:

• This post assumes that the reader understands Oracle databases, Linux configuration and mounting of NFS shares, and has familiarity with FSx for ONTAP.
• To create a similar deployment in your environment, you must have an AWS account with access to Amazon EC2, AWS Backup, and FSx for ONTAP, and meet the ONTAP prerequisites for attaching a Linux client.
• Oracle database configured and AWS Command Line Interface (AWS CLI) in an EC2 instance.
• An FSx for ONTAP file system with a volume configured and NFS share mounted to the Oracle Server, which is the FRA storage location.

Configure FSx for ONTAP for FRA best practices

When creating the FSx ONTAP filesystem, it should be configured with the following:

– Automatic disk IOPS mode.

– Multi-Availability Zone (AZ) deployment for high availability.

– Appropriate throughput capacity (recommended 512 MBps).

– The storage virtual machine (SVM) should be created on the FSx for ONTAP filesystem with proper administrative credentials and security configurations.

– The FRA volume configured with Capacity pool tiering policy of Auto, with the cooling period set to two days (assuming RMAN backup compression is being used). This policy and setting moves all cold data to the capacity pool tier after two days (if RMAN compression is not being used, then set the cooling period to 14 days).

Walkthrough

The following steps walk you through this solution.

1. Configure AWS Backup (longer term retention >30 days)

You can choose AWS Backup to schedule daily backups of the EC2 instance (this only backs up the local attached EBS volumes). AWS Backup efficiently stores your periodic backups using backup plans. Only the first EBS snapshot performs a full copy, and all subsequent snapshots are incremental snapshots, copying just the changed blocks from Amazon EBS, thus reducing backup duration and storage costs. Oracle supports Storage Snapshot Optimization, which takes third-party snapshots of the database without placing the database in backup mode. By default, AWS Backup now creates crash-consistent backups of EBS volumes that are attached to an EC2 instance. Users no longer need to stop their instance or coordinate between multiple EBS volumes attached to the same EC2 instance to make sure of crash-consistency of their application state.

Create daily scheduled backup of EC2 instances hosting your Oracle servers as shown in Figure 3.

Figure 3. Configure the AWS Backup plan (and associated rules if not using defaults)

Figure 4 shows sample screenshots of the backup plan, and associating an EC2 instance with the backup plan.

Figure 4. Assign resources to the plan (Oracle EC2 server/s)

Figure 5, shows the AWS Backup plan configured to perform daily backups of the Oracle EC2 servers as per your specification with the retention period set, as per the requirement (in this example, 12 months).

Figure 5. Validate Backup plan configuration

Although AWS Backup is now creating a daily backup of the EC2 instance, we also want to make sure we configure FRA to make sure of granular Oracle backup and recovery capabilities of a short period, such as 30 days. This enables point-in-time recovery.

2. Configure FRA (short-term retention <30 days)

FSx for ONTAP provides fully managed, shared storage in the AWS Cloud with the popular data access and management capabilities of ONTAP. FSx for ONTAP provides several advantages for database storage needs, both core database files and FRA. It offers high-performance SSD storage with sub millisecond latencies, making it suitable for demanding workloads. The service provides feature-rich, fast, and flexible shared file storage that’s broadly accessible from within AWS or on-premises.

Particularly for FRA, some key benefits of using FSx for ONTAP include:

– Storage efficiency features such as compression, deduplication, and compaction that can help reduce overall storage costs.

– Automatic tiering of data to lower-cost storage, which helps optimize costs while maintaining performance (see volume data tiering to understand the various tiering options and configure your FRA volume to suit).

– Built-in data protection features such as snapshots, cloning, and replication capabilities.

– Highly available and durable storage with fully managed backups and support for cross-Region disaster recovery.

– Support for data security and antivirus applications to protect sensitive database files.

a) Create the necessary directory structure in the mounted FSx for ONTAP volume (prerequisite, with the following example assuming it is mounted as /fsx).

```bash

# replace <ORACLE_SID> with your database name/SID

mkdir -p /fsx/ontap/FRA/<ORACLE_SID>
chown oracle:oinstall /fsx/ontap/FRA/<ORACLE_SID>
chmod 755 /fsx/ontap/FRA/<ORACLE_SID>

b) Enable archive log mode (if not already enabled).

```bash

# Connect to Oracle as SYSDBA
SQL> sqlplus / as sysdba

# Enable archivelog mode if not already enabled:
-- Check current archive mode
SQL> ARCHIVE LOG LIST;

-- If needed, enable archivelog mode
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;

c) Set the FRA initialization parameters.

```bash

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=100G SCOPE=BOTH;
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/fsx/ontap/FRA/<ORACLE_SID>' SCOPE=BOTH;
SQL> ALTER DATABASE OPEN;

# Verify FRA configuration
SQL> SHOW PARAMETER DB_RECOVERY_FILE_DEST;
SQL> SHOW PARAMETER DB_RECOVERY_FILE_DEST_SIZE;
SQL> SELECT * FROM V$RECOVERY_FILE_DEST;

# Optional: Move existing archive logs to new FRA
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST' SCOPE=BOTH;

SQL> ALTER SYSTEM SWITCH LOGFILE;

d) Configure Oracle RMAN backups.

First, configure RMAN repository to take control file backup to FSx for ONTAP automatically:

```bash

RMAN TARGET /

RMAN> CONFIGURE COMPRESSION ALGORITHM ‘BASIC’;
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+FRA';
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
```

e) Create a bash script for RMAN archive logs and schedule with crontab:

```bash

dt=`date +%Y%m%d_%H%M%S`

rman target / log=/fsx/ontap/FRA/<ORACLE_SID>/rman_arch_bkup_oratst_${dt}.log <<EOF

RUN
{
    allocate channel c1_efs device type disk format '/fsx/ontap/FRA/<ORACLE_SID>/arch-D-%d_%T_s%s_p%p' MAXPIECESIZE 10G;
    RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG ALL DELETE ALL INPUT;
    release channel c1_efs;
}

EOF
```

To schedule archive log backups every five minutes, add to crontab:

```bash 

*/5 * * * * /path/to/rman_archive.sh

The preceding tasks configured and executed created the backup protection plan from AWS Backup and within Oracle (backing up to the FRA). The following steps are tasks to perform for recovery of the database as per your requirement (either beyond 30 days through AWS Backup or within 30 days using Oracle).

3. Recover through FRA to point-in-time within the specified retention (in this case, 30 days)

Step-by-step instructions to recover an Oracle database using RMAN backups stored in the FRA.

a) Pre-recovery preparation.

-- Check FRA location
SQL> SHOW PARAMETER DB_RECOVERY_FILE_DEST;
-- List RMAN backups
RMAN> LIST BACKUP;
RMAN> CROSSCHECK BACKUP; -- Validate backup integrity
SQL> SELECT CURRENT_SCN FROM V$DATABASE;
SQL> SHUTDOWN IMMEDIATE;


b) Restore database. Skip if control file is intact.

# Start RMAN
rman target /
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP; -- Automatically checks FRA
RMAN> ALTER DATABASE MOUNT;

c) Restore database

RMAN> RUN {
  RESTORE DATABASE;
}

d) Recover database.

RMAN> RECOVER DATABASE; -- Applies archived logs and incremental backups from FRA

e) For point-in-time recovery.

RMAN> RECOVER DATABASE UNTIL TIME 'YYYY-MM-DD:HH24:MI:SS';

f) Open the database.

RMAN> ALTER DATABASE OPEN RESETLOGS; -- Required after incomplete recovery

4. Recover through AWS Backup to the scheduled backup times (in this case, > 30 days).

The AWS Backup service creates crash-consistent snapshots across all EBS volumes attached to an EC2 instance. Therefore, you can eliminate the need to put the database in backup mode by combining this feature and the Storage Snapshot Optimization feature introduced in Oracle database 12c.

For a more detailed demonstration of preceding EBS snapshot feature, refer to the following post: Improving Oracle backup and recovery performance with Amazon EBS multi-volume crash-consistent snapshots.

After EBS volumes are restored from snapshots, although crash-consistent, the database usually needs media recovery within Oracle to make it fully operational.

When performing Oracle database recovery from restored snapshots using AWS Backup, if point-in-time recovery is needed, then the timestamp of the snapshot(s) must be known.

SQL> startup mount;

SQL> recover database until time 'YYYY-MM-DD:HH24:MI:SS' snapshot time 'YYYY-MM-DD:HH24:MI:SS';

To be safe, some seconds (such as one minute) are added to the preceding snapshot time to account for possible clock variance between volumes.

Cleaning up

There are costs associated with running EC2 instances, FSx filesystems and AWS Backup. Remember to delete and terminate unused filesystems and EC2 instances , and delete backups if they are no longer needed.

Conclusion

In this post, we demonstrated the use of AWS Backup for Oracle on Amazon EC2 and Amazon FSx for NetApp ONTAP as the storage target for the Oracle FRA.

With this strategy for backup, Oracle database running on Amazon EC2 can be restored and recovered to a point-in-time within the set FRA retention (in this scenario, 30 days). Meanwhile, AWS Backup can be used for non-point in time data recovery beyond 30 days.

You can use this solution to facilitate restoring copies of your production database for development or testing purposes and to recover from a user error that removes data or corrupts existing data.

To learn more about AWS Backup, refer to the AWS Backup Documentation. To learn more about FSx for ONTAP, refer to the FSx for ONTAP documentation.