Backup Oracle E-Business Suite Running on AWS EC2

I’ve written this article to share my thoughts and ideas regarding backup solutions for Oracle E-Business Suite running on AWS EC2 instances.

Case study: I have used two Oracle E-Business Suite installations running in the AWS cloud. Details below:

• Oracle E-Business Suite 11.5.10.2 running on Oracle Linux 5.9
• Oracle E-Business Suite 12.1 vanilla running on Oracle Linux 7.9

When thinking about some potential backup solutions, there are a few:

1. Attach the S3 bucket to the EC2 instance and transfer file system files along with RMAN database backups to the S3 bucket.
2. Store RMAN database backups on EBS (Elastic Block Store) volume and create a volume snapshot to back up the entire EBS volume.
3. Create EC2 instance backups as AMIs (Amazon Machine Images).

We’re going to dive into Option 3 in this particular article.

Why option 3?

This is a reasonable question if we are considering Oracle E-Business Suite installation. Installation complexity is the reason. We would like a backup that we restore without actually re-installing Oracle E-Business Suite infrastructure.

To remind complexity of the Oracle E-Business Suite installation or migration process sharing a link to one of my previous posts: HOW TO MIGRATE ORACLE APPLICATIONS 11.5.10.2 FROM ON-PREMISES SUNOS FLEET TO LINUX ON AWS.

If we look at the configuration of E-Business Suite 11.5.10.2 running on Oracle Linux 5.9, there is an additional concern. When the installation on AWS was performed, Oracle Linux 5.9 was available as per the following link: Launch an Oracle Linux Instance in AWS.

Reviewing available public images of the same owner after a while revealed that Oracle Linux 5.9 is not available anymore. It is important to preserve all installation layers to avoid the time-consuming work of obtaining or finding the necessary operating system image.

The above statement is even more important for legacy archive systems with older operating system versions. Oracle Linux 5.9 is the latest certified combination for Oracle E-Business Suite 11.5.10.2 therefore chosen.

How do we make it happen?

There are a few ways Amazon Machine Image (AMI) can be created for EC2 instances. Remember that a set of permissions are needed to perform AMI creation. If a backup activity is not performed by a user with administrator right, some roadblocks are possible.

I will not discuss roles and policies in this article as this is a good topic for separate posts addressing permission-related questions.

Let’s review a few of them.

• Programmatic way. I will not walk through every detail of the below posts as the details are very well explained.

1. 1. AWS Automatic AMI creation
   2. Automate AMI Creation and Deletion with Amazon Lambda (AWS EC2 Backup)

• AMI creation can be automated using AWS CLI. If shell scripting is your favourite You will like it for sure. Here are a few example commands below.

------- Obtains AWS CLI version 
aws --version

------- Configure AWS CLI (key file will be needed here)
aws configure

------- Create AMI from EC2 instance
aws ec2 create-image --instance-id i-xxxxxxxxxxxxxxxxx --name "eBS_Lab_Backup-`date +"%d.%m.%Y-%H.%M.%S"`" --description "Daily backup of eBS Lab" --no-reboot

------- Describe snapshots of EBS (Elastic Block Store) volumes
aws ec2 describe-snapshots --owner-ids self 

aws ec2 describe-snapshots --owner-ids self | grep -ie SnapshotId -ie Progress -ie VolumeSize

------- Describe/list created AMIs
aws ec2 describe-images --image-ids ami-xxxxxxxxxxxxxxxxx

aws ec2 describe-images --owners self

------- Restore EC2 instance from previously created AMIs
aws ec2 run-instances --image-id ami-xxxxxxxxxxxxxxxxx --count 1 --instance-type t2.large --key-name XXX-XXX-Key --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=eBS_Lab_Backup-13.03.2023-18.14.19-RESTORE}]'

------- Describe/list restored EC2 instances and corresponding volumes
aws ec2 describe-instances --region eu-west-1

aws ec2 describe-volumes

You can find a complete AWS CLI command line interface reference here: AWS CLI Command Reference.

• AMI can be created manually from EC2 Console. Navigation: choose the EC2 instance you want to back up => Actions => Image and Template => Create Image. A dialog box will appear where the image name, description, reboot option, and tags can be specified, as well as additional volumes added to those already attached to the EC2 instance.
• AWS Backup Service is a great way to address EC2 instance backups. The creation of a backup plan is straightforward. Choose a resource to back up; in our case, this is one or more EC2 instances. Add a backup plan according to the retention needs you have. Frequency, Start within, Complete within, Lifecycle, and Backup vault configuration are available under the backup plan. You can create separate backup plans using different lifecycle settings, using default or custom-created backup vaults to separate resources you back up.

Notes for the backup process

• Remember, when you create an EC2 instance snapshot to AMI, the corresponding EC2 instance will be rebooted. To avoid that, use the no reboot option as a parameter in the case of AWS CLI, and check the box if running the snapshot manually.
• The time taken by backup depends on the size of the EBS volumes attached. The larger the volumes, the longer the backup will go. Only after a complete snapshot of the attached volumes completed AWS Backup Service will proceed with AMI creation. You can check the progress of ongoing volume snapshots from AWS Console or using AWS CLI from shell (example given above in example commands section).

How do you test backup validity with the restore process?

Last but not least, backups should be tested regularly. Regular restores ensure your data is safe and the applied backup solution is working.

Options are the same as creation regarding restoring EC2 instances from AMI (Amazon Machine Image).

• Programmatically, by using functions and triggers (links provided above). I have yet to test this way of automated restore.
• Manually from the AWS console. This would be appropriate if you need to test the restore on-demand.
• AWS CLI scripting. As mentioned earlier, if scripting is your favourite, you can proceed with restore shell scripts scheduled by cron. This approach is very useful if regular restores are needed for lower environment cloning.
• You can use the Restore activity directly from Backup Vault to restore your particular backup that is still present in the vault. I have tested a restore from AWS Console and AWS CLI through shell scripting, and no concerns so far.

Notes for the restore process

• • Remember that when you restore the EC2 instance AMI (Amazon Machine Image), the restore process does not overwrite your original instance. The original instance is kept intact. A new set of instances gets created with a fresh set of volumes.
  • The time taken by restore depends on the size of the EBS volumes attached. The larger the volumes, the longer restore will take. Same principle as for the backup part.
  • When you restore, consider resource utilization, the cost of EC2 instances, and the amount of storage consumed by volumes.

  Note additional post steps for restoring Oracle E-Business Suite. The restore process is tested for versions: 11.5.10.2 / 12.0 / 12.1. Work in progress on version 12.2 involves ADOP and a dual file system.

------- On target instance after restore

(1) update /etc/hosts file with new IP (NEW_IP host.domain host) - check NEW_IP using ifconfig

(2) hostnamectl set-hostname host.domain from source

(3) clean opmn persistence (for Oracle E-Business Suite 12.0 and 12.1)
set environment and run below
rm -rf $INST_TOP/ora/10.1.3/j2ee/oacore/persistence/*
rm -rf $INST_TOP/ora/10.1.3/j2ee/oafm/persistence/*
rm -rf $INST_TOP/ora/10.1.3/j2ee/forms/persistence/*
rm -rf $INST_TOP/ora/10.1.3/opmn/logs/states/.opmndat 

(4) clean log files from $INST_TOP
find $INST_TOP -name *.log | xargs ls -lptr
find $INST_TOP -name *.log | xargs rm

(5) update fnd_nodes with actual IP address
set pagesize 999 linesize 999
select SERVER_ADDRESS, HOST, DOMAIN from fnd_nodes;
update fnd_nodes set SERVER_ADDRESS = 'NEW_IP' where HOST='your_hostname';
commit;

Summary

I do hope you enjoyed this article, and I do hope you found the information helpful. Please let me know if you have any questions; I would be happy to help. I wish you all the best in your IT administering endeavours.