Mostafa Helmy

Full Backup Script for Hardware Appliances or Software-Bundles with RSA-provided Database

Blog Post created by Mostafa Helmy Employee on Jun 3, 2019


This may or may not work on RSA IGL v7.2 depending on the installation options. For example, in 7.2 we allow installing the application under a different folder than the previously standard /home/oracle.

So I wouldn't recommend using it on 7.2 yet.

Full backups are a crucial measure for RSA Identity Governance & Lifecycle or generally any other enterprise application. Your organization probably has a strict backup policy which would mention aspects such as:

  • Backup frequency
  • Backup contents
  • Backup storage location
  • Backup retention


On the other hand, scheduling full backups for RSA Identity Governance & Lifecycle following our best practices could be challenging. You would need to take into consideration:

  • Backing up all important components (Database, Encryption Keys, Keystores?)
  • On highly active environments, it is recommended to schedule the database backup while the application is down to ensure a consistent backup.
  • Removing old backup files so as not to fill up the file system.
  • Notifying the system administrator of any backup failure.


RSA Professional Services created the attached bash script as an example of backup using our best practices and as a base for any further modifications required to meet your organization's backup policies. The script is split into separate functions to allow easily building extra functionalities on top of the existing ones. Currently the script will:

  1. Stop the Application (and AFX if exists).
  2. Perform a database backup.
  3. Start the Application (and AFX if exists).
  4. Compress the database backup + the database encryption keys + the application server keystores into a full backup file.
  5. Remove both database and full backup files older than a preset threshold.
  6. Perform checks on the database backup status and possibly notify the system administrator upon any failures.
  7. Possibly copy the full backup files to remote share.




The script must be run as oracle and is cronjob friendly. The usage is very simple, just make sure it has the correct execute permissions for the oracle user then run it as follows:

> ./


By default the script creates the full backup files under /home/oracle/fullbackups and is configured to keep only the last 3 backup files. You can easily overwrite either of those value by setting the environment variables FULLBACKUP_DIR and OLD_BACKUPS_TOKEEP first. For example, using the following syntax:

> env OLD_BACKUPS_TOKEEP=10 FULLBACKUP_DIR=/home/oracle/my_full_backup_dir ./


Restore Procedure


  1. Create a temporary restore directory anywhere. For example:
> mkdir /home/oracle/fullbackups_restore


  1. Extract the compressed file in that directory. For example:


> cd /home/oracle/fullbackups_restore
> tar -xvf /home/oracle/fullbackups/DailyBackup_20190602_120243.tar.gz


  1. List all files to make sure they were extracted correctly. Ideally there should be three file extensions:
    1. *.dmp -> Database backups.
    2. *.key -> Encryption keys.
    3. *.keystore -> Keystore files.


For example:


> cd /home/oracle/fullbackups_restore
> ls -l
   total 1059580
   -rw-r----- 1 oracle oinstall 1084977152 Jun  2  2019 Export_AVDB_avuser_DailyBackup_20190602_120243.dmp
   -rw------- 1 oracle oinstall         26 Mar 18  2019 9K9.key
   -rw------- 1 oracle oinstall         26 Mar 18  2019 Xmk.key
   -rw-r--r-- 1 oracle oinstall       4815 Apr  2  2018 aveksa.keystore
   -rw-r--r-- 1 oracle oinstall       5301 Mar 18  2019 server.keystore


  1. Stop AFX if exists, then the application. For example:


> afx stop
> acm stop


  1. Copy the database backup file to the default Export/Import directory, then restore the database backup.
    The backup file names are in the format Export_<DatabaseID>_<DatabaseUser><Tag>.dmp. You need use the -t <Tag> option to specify the backup file you want to import.

    For example, the tag value from Export_AVDB_avuser_DailyBackup_20190602_120243.dmp is _DailyBackup_20190602_120243 (including the leading _) as shown below:


> cp /home/oracle/fullbackups_restore/Export_AVDB_avuser_DailyBackup_20190602_120243.dmp /home/oracle/AveksaExportImportDir
> avdbimport -t _DailyBackup_20190602_120243


  1. Copy the .key files to the security directory and update their permissions to the expected value (rw- --- ---). For example:


> cp /home/oracle/fullbackups_restore/*.key /home/oracle/security
> chmod 600 /home/oracle/security/*


  1. Copy the .keystore files to the keystore directory. For example:
> cp /home/oracle/fullbackups_restore/*.keystore /home/oracle/keystore


  1. Start the application, then AFX if exists. For example:
> acm start
> afx start


  1. Once you confirm everything is fine, you can delete the temporary restore directory. For example:
> rm -rf /home/oracle/fullbackups_restore


We would really love to hear your feedback and you can always contact RSA Professional Services through your account manager if you are interested in adding more customizations to the backup script.