AWS Database Blog

Clone Amazon RDS Custom for Oracle to Amazon EC2 using multi-volume EBS snapshots

Amazon Relational Database Service (Amazon RDS) Custom is a managed database service that combines the automation benefits of Amazon RDS with the flexibility to customize the database environment and underlying operating system. It serves as a middle ground between fully managed Amazon RDS and self-managed databases on Amazon Elastic Compute Cloud (Amazon EC2). Amazon RDS Custom supports Oracle and SQL Server database engines.

When choosing a database solution on Amazon Web Services (AWS), consider the level of control and management you require:

  • Amazon RDS – The best option if you want AWS to fully manage both the database and the underlying operating system
  • Amazon RDS Custom – Ideal if you need administrative access to the OS and database to support application dependencies
  • Amazon EC2 – The right choice if you prefer full control over database management and only need a compute environment

Unlike standard Amazon RDS, which restricts access to the underlying host and certain privileged operations, Amazon RDS Custom allows elevated permissions while still providing automation for administrative tasks. This makes it an excellent choice for businesses that need both flexibility and operational efficiency. Consequently, customers are responsible for performing regular OS patching on Amazon RDS Custom EC2 instances to maintain security.

As of this writing, Amazon RDS Custom for Oracle does not support cross-account snapshot sharing. In this post, we walk you through the process of cloning an Amazon RDS Custom for Oracle database to an EC2 instance using multi-volume Amazon Elastic Block Store (Amazon EBS) snapshots for storage replication. This approach is useful for setting up a disaster recovery (DR) environment in a Region where RDS Custom is not yet available.

Amazon RDS Custom to EC2 cloning

This section outlines the challenges of cloning an Oracle database from Amazon RDS Custom to Amazon EC2 and introduces multi-volume storage snapshots as a viable alternative.

  • Oracle Recovery Manager (RMAN) backup and restore – Reliable, however it requires manual storage management, extensive scripting, and careful planning with multiple steps.
  • Oracle Data Pump (expdp/impdp) – Suitable for logical migrations but error-prone and complex for full database migration, requiring schema remapping, index rebuilding, and handling unsupported objects.
  • RDS Custom snapshots – Although RDS Custom allows taking snapshots for backups, these snapshots can’t be restored directly to Amazon EC2, making them unsuitable for cloning an Oracle database on Amazon EC2.
  • Multi-volume storage snapshot – Multi-volume Amazon EBS snapshots provide a viable alternative for migrating an Oracle database from Amazon RDS Custom to an EC2 instance. Using multi-volume crash-consistent snapshots of an EC2 instance running RDS Custom greatly simplifies the database cloning process.

Solution overview

Consider a large Oracle database (typically 1 TB or more) running on Amazon RDS Custom in the Canada (Central) ca-central-1 AWS Region. To set up a disaster recovery instance in Canada West (Calgary) ca-west-1, you need to migrate the database to an EC2 instance because Amazon RDS Custom for Oracle isn’t available in Canada West (Calgary) ca-west-1 as of this writing.

In May 2019, AWS introduced a feature users can use to create crash-consistent snapshots across EBS volumes attached to an EC2 instance with a single API call and minimal I/O disruption. When combined with Oracle Database 19c’s Storage Snapshot Optimization, this alleviates the need to place the database in backup mode during snapshot operations. This results in performance benefits such as reduced redo log generation, lower I/O load, and faster recovery times. The feature enables Oracle users to replicate enterprise-grade backup and recovery practices in the cloud, supporting efficient point-in-time recovery and database cloning.

It is important to note that Oracle Database 19c’s Storage Snapshot Optimization is available only with Enterprise Edition and with the Advanced Compression option, which has an additional licensing requirement. For databases running Standard Edition 2 or Enterprise Edition without Advanced Compression, users should enable backup mode on the database before taking storage snapshots and disable it afterward to ensure crash-consistent snapshots.

The solution uses crash-consistent multi-volume snapshots from the RDS Custom instance. By using EBS snapshots, we can avoid the need for a full database software reinstall or complex recovery procedures, providing a quick and efficient disaster recovery (DR) setup. The mechanism also works in the same Region if you need to clone a database on Amazon EC2.The workflow consists of the following components:

  1. RDS Custom for Oracle system – This represents an RDS Custom for Oracle deployment in the source Region. The database runs on an EC2 host, which provides underlying compute resources, while EBS storage is used to store Oracle database binaries and database files including datafiles, redo log files, control files and Oracle Net configuration files such as sqlnet.ora and listener.ora.
  2. Storage snapshot and replication – A multi-volume snapshot is created from the EBS storage attached to the source EC2 instance. These snapshots are then copied to the target Region, enabling cross-Region disaster recovery.
    It’s recommended to perform multi-volume snapshot creation when the RDS Custom for Oracle instance is in the AVAILABLE state and no backups are running for that specific instance.

    Multi-volume snapshot

    Create a multi-volume snapshot from the underlying EC2 instance.

    Copy the snapshots to the target region.

    Create EBS volumes from the copied snapshots.

    Attach the newly created volumes to the target EC2 instance.
  3. Target self-managed Oracle database system – In the target Region, an EC2 instance is provisioned to host the self-managed Oracle database. The copied snapshots are used to create new EBS volumes, which are then attached to the EC2 instance, completing the cloning process.

The following diagram illustrates the implementation of the solution.

Prerequisites

Before starting the procedure, make sure you have the following prerequisites:

  • An active Amazon RDS Custom for Oracle instance.
  • An EC2 instance in the target Region with a compatible OS. Make sure that your EC2 instance is running a supported OS type and version and that all required OS packages (RPMs) are installed. Refer to the Oracle Database Installation Guide for Linux for the specific RPMs and instructions to configure OS users and groups.
  • AWS Identity and Access Management (IAM) permissions to create, copy, and attach EBS snapshots.
  • A virtual private cloud (VPC) set up with security groups allowing Oracle database connections.
  • Network connectivity between the source and target Regions.

Storage snapshot procedure

To perform the cloning using storage snapshots, follow the steps in the next sections.To identify the RDS Custom EC2 host, follow these steps:

  1. Open the Amazon RDS console and select your RDS Custom instance
  2. Under the Configuration tab, take note of the Resource ID
  3. On the Amazon EC2 console, search for the Instance ID that matches the Resource ID from the RDS console, as shown in the following screenshot

To analyze storage configuration on the RDS Custom EC2 instance, follow these steps:

  1. Connect to the EC2 instance the same way you connect to other EC2 servers
  2. Enter df -kh to list file systems and identify the mount points for the Oracle binaries and datafiles, as shown in the following sample output: 
    [root@ip-10-1-1-52 ~]# df -kh
Filesystem                       Size  Used Avail Use% Mounted on
devtmpfs                         7.7G     0  7.7G   0% /dev
tmpfs                             16G  7.0G  8.5G  45% /dev/shm
tmpfs                            7.7G  472K  7.7G   1% /run
tmpfs                            7.7G     0  7.7G   0% /sys/fs/cgroup
/dev/nvme0n1p1                    50G   11G   39G  22% /
/dev/nvme3n1                      25G   11G   13G  46% /home/oracle
/dev/mapper/dbdata01-lvdbdata01   40G  6.6G  33.4G 16% /rdsdbdata
tmpfs                            1.6G     0  1.6G   0% /run/user/71001
tmpfs                            1.6G     0  1.6G   0% /run/user/0

In this example, the /home/oracle directory serves as the Oracle base, housing the Oracle software and configuration files. Oracle base is customizable, and you can change the location when you create the custom engine version (CEV).

You can query the config file to get the exact Oracle base that you used while creating the CEV, as shown in the following output:

[root@ip-10-1-5-108 ~]# egrep -i 'oraclebase|oraclehome' /opt/aws/rdscustomagent/config/database\_metadata.json
  "oracleBase" : "/home/oracle",
  "oracleHome" : "/home/oracle/oracle.19.0.0.0.ru-2024-10.rur-2024-10.r1.EE.1"
[root@ip-10-1-5-108 ~]#

The /rdsdbdata directory is a mount point designated for storing the actual application data, such as database files and related information. This separation provides a clear distinction between the Oracle software environment and the database data, facilitating efficient management and maintenance.

The process replicates both file systems to the EC2 instance running in the target Region including the third-party software installed in /rdsdbdata on the source because it’s a storage snapshot.To take and copy the EBS snapshots, follow these steps:

  1. Create crash-consistent Amazon EBS multi-volume snapshots for the EC2 instance.

    You choose Instance as a resource type and select your source RDS Custom EC2 Instance ID from the dropdown.

    The following screenshot shows how to create multi-volume snapshots using the EC2 instance ID.

    You can select which volumes to include in the snapshot creation. Each chosen volume will have a separate snapshot. In this process, we excluded the root volume, as shown in the following screenshot. Thus by default, included a 25 GB volume for Oracle binaries and four 10 GB volumes for database files.

  2. On the Amazon EC2 console, choose Snapshots.

    Five snapshots were created because we included five volumes in the previous step, as shown in the following screenshot.

    You can search snapshots using the description provided while taking snapshots and make sure the snapshot status says Completed before moving on to the next step.

  3. Select the snapshot, go to Actions and then select Copy snapshot.

    You can’t select all snapshots in a single copy operation; each must be copied individually.

  4. Specify the Destination Region. In this example, we are copying to ca-west-1, as shown in the following screenshot.

    Alternatively, you can use the AWS Command Line Interface AWS CLI to copy the EBS snapshot:

    aws ec2 copy-snapshot \
  --source-region ca-central-1 \
  --source-snapshot-id snap-083f1975caf150fa8 \
  --description "Copy of snapshot snap-083f1975caf150fa8 to ca-west-1" \
  --region ca-west-1
  5. Repeat steps 3 and 4 for each snapshot.
  6. Wait for the snapshots to be available in the target Region, as shown in the following screenshot.

    The time required to copy the snapshots depends on their sizes.

To configure the target EC2 instance, use the following steps:

  1. Connect to the target EC2 instance

    For this demonstration, we used a Red Hat EC2 server. However, Oracle Linux can also be used, similar to the source RDS Custom server.

  2. Install the Logical Volume Management (LVM) package: 
    sudo yum install -y lvm2

    Make sure you use the command based on your operating system.

Complete the prerequisites for Oracle database installation. Refer to the Oracle documentation for RHEL 9 to install the required OS packages and create the necessary Oracle OS users and groups. Copy the lvm.conf file from the RDS Custom instance to the new EC2 instance. The location of lvm.conf in RDS Custom is /etc/lvm/lvm.conf. Copy this file to the target EC2 server.

You need to restart the server before continuing with the next steps.

To create and attach EBS volumes to EC2, use the following steps. You’ll attach all five volumes to the EC2 server. This step should be carried out in the target Region. Make sure you create the volumes in the same Availability Zone where you’re running the target instance.

  1. Create new EBS volumes from the copied snapshots in the target Region.

    You select the individual EBS snapshot and choose Create volume from snapshot from the Actions.

    The following screenshot shows how to create a volume from EBS snapshot

    Optionally, you can use the AWS CLI to create EBS volume using a snapshot:

    aws ec2 create-volume \
  --region ca-west-1 \
  --availability-zone ca-west-1a \
  --snapshot-id snap-0c71c57cb85ec7fd9

    Repeat this step for each snapshot to create volumes.

  2. Attach EBS volumes to the target EC2 instance.
  3. Mount volumes for Oracle binaries and database files.

Binary volume configuration

To mount the Oracle binaries, use the following steps. Execute the following steps as the root user:

  1. Create the required mount point: 
    mkdir -p /oracle
  2. Mount the Oracle binaries: 
    mount /dev/nvme4n1 /oracle
  3. Adjust ownership and permissions: 
    chown -R oracle:dba /oracle 
chmod -R 755 /oracle

The default OS user for the Oracle Home is rdsdb. In this solution, we have customized the configuration to use oracle as the Oracle installation owner.

Execute the following steps as the oracle user:

sudo su - oracle
# Oracle Environment Variables
export ORACLE_HOME=/home/oracle/oracle.19.0.0.0.ru-2024-10.rur-2024-10.r1.EE.1
export ORACLE_SID=RDSCDB  
export PATH=$PATH:$ORACLE_HOME/bin
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
export CLASSPATH=$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib:$CLASSPATH
export TNS_ADMIN=$ORACLE_HOME/network/admin
[oracle@######### ~]$ sqlplus
SQL*Plus: Release 19.0.0.0.0 - Production on Tue Apr 1 13:32:59 2025
Version 19.26.0.0.0
Copyright (c) 1982, 2024, Oracle.  All rights reserved.
Enter user-name:

This step verifies that the Oracle binaries are configured correctly.

Data volume configuration

To mount the /rdsdbdata file system, use the following steps.

  1. Scan for Volume Groups: 
    [root@ip-172-31-37-112 ~]# vgscan
  Found volume group "dbn0" using metadata type lvm2
  Found volume group "dbdata01" using metadata type lvm2
[root@ip-172-31-37-112 ~]#
  2. Validate VG size and PV/LV counts: 
    [root@ip-172-31-37-112 ~]# vgs
  VG       #PV #LV #SN Attr   VSize  VFree
  dbdata01   1   1   0 wz--n- 39.98g    0
  dbn0       4   1   0 wz--n- 39.98g    0

[root@ip-172-31-37-112 ~]# lvs
  LV         VG       Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lvdbdata01 dbdata01 -wi------- 39.98g
  lvdbn0     dbn0     -wi-a----- 39.98g

[root@ip-172-31-37-112 ~]# lvscan
  ACTIVE            '/dev/dbn0/lvdbn0' [39.98 GiB] inherit
  inactive          '/dev/dbdata01/lvdbdata01' [39.98 GiB] inherit
[root@ip-172-31-37-112 ~]#
  3. Activate the nested VG dbdata01: 
    [root@ip-172-31-37-112 ~]# vgchange -ay dbdata01
  1 logical volume(s) in volume group "dbdata01" now active
[root@ip-172-31-37-112 ~]#
  4. Validate that lvdbdata01 is active: 
    [root@ip-172-31-37-112 ~]# lvscan
  ACTIVE            '/dev/dbn0/lvdbn0' [39.98 GiB] inherit
  ACTIVE            '/dev/dbdata01/lvdbdata01' [39.98 GiB] inherit
[root@ip-172-31-37-112 ~]#

[root@ip-172-31-37-112 ~]# lvs
  LV         VG       Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lvdbdata01 dbdata01 -wi-a----- 39.98g
  lvdbn0     dbn0     -wi-ao---- 39.98g
[root@ip-172-31-37-112 ~]#
  5. Set up /rdsdbdata mountpoint: 
    [root@ip-172-31-37-112 ~]# mkdir -p /rdsdbdata
[root@ip-172-31-37-112 ~]# chown oracle:dba /rdsdbdata
  6. Mount the filesystem: 
    [root@ip-172-31-37-112 ~]# mount /dev/dbdata01/lvdbdata01 /rdsdbdata
[root@ip-172-31-37-112 ~]#
  7. Validate mount /rdsdbdata: 
    [root@ip-172-31-37-112 ~]# df -h /rdsdbdata
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/dbdata01-lvdbdata01   40G  4.1G   35G  11% /rdsdbdata

To start the Oracle database on Amazon EC2, follow these steps:

  1. Switch to the Oracle user: 
    su – oracle
  2. Set Oracle environment variables and start the database:

Optionally, you can add environment variables in .bash_profile or create an environment .env file as well in /user/home.

[oracle@ip-172-31-37-112 ~]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Wed Dec 18 04:20:32 2024
Version 19.24.0.0.0
Copyright (c) 1982, 2024, Oracle.  All rights reserved.
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 1.2133E+11 bytes
Fixed Size                 37622096 bytes
Variable Size            8.2678E+10 bytes
Database Buffers         3.8118E+10 bytes
Redo Buffers              499245056 bytes
Database mounted.
Database opened.
SQL>

Cleanup

To avoid ongoing costs, it’s important to clean up all resources created as part of this exercise:

  1. EBS snapshots – Delete snapshots in the source Region. If cross-Region replication was used, remove them from both the primary and secondary Regions.
  2. EC2 instance – Terminate the EC2 instance used as the database replication target and make sure that all associated EBS volumes are deleted.
  3. Amazon RDS Custom for Oracle – If you provisioned an Amazon RDS Custom for Oracle instance specifically for this exercise, make sure to delete it and all associated VPC endpoints and IAM resources.

Conclusion

In this post, we demonstrated how to clone an Oracle database from Amazon RDS Custom to an Amazon EC2 instance using multi-volume EBS snapshots. We walked through the key steps: taking crash-consistent snapshots of the EC2 instance running RDS Custom, copying them to the target Region, creating and attaching EBS volumes, performing OS-level configurations, and successfully opening the Oracle database on the target EC2 instance. This approach provides a reliable way to clone Oracle databases when Amazon RDS Custom is unavailable in a target Region or when you need a database clone on Amazon EC2 for testing, development, or other use cases within the same Region. If you have any questions or experiences to share, leave a comment.

About the authors

Viranchi Ajmeri

Viranchi Ajmeri

Viranchi is Senior Partner Solutions Architect at Amazon Web Services (AWS) on the Global System Integrator (GSI) team. She has over 20 years of IT experience in strategic advisory, design and architecture domain. Outside the profession, Viranchi spends time painting, gardening, traveling, studying pyschology, and learning about new inventions in forensic science.

Girish Mukim

Girish Mukim

Girish is a Senior AWS Solutions Architect and AWS Ambassador with a strong background in Oracle database administration at IBM. He helps customers migrate to the AWS Cloud by designing scalable, cost-effective, and secure solutions tailored to their needs. Passionate about sharing his knowledge, he actively contributes to the AWS community through his YouTube channel, blogs, and as a participant in the AWS Community Builders program.

Jesse J. Bain

Jesse J. Bain

Jesse is a technologist and AWS Solution Architect at IBM with extensive experience in system administration and infrastructure design. He works with clients in Canada across the energy, finance, and communication industries to build resilient solutions for their big data workloads.

Jay Pandya

Jay Pandya

Jay is a Senior Partner Solutions Architect on the Global Systems Integrator (GSI) team at Amazon Web Services (AWS). He has over 30 years of IT experience and provides guidance to AWS GSI partners to build, design, and architect agile, scalable, highly available, and secure solutions on AWS. Outside the office, Jay enjoys spending time with his family and traveling, is an aviation enthusiast, and is an avid sports and Formula 1 fan.