What is the best practice for backing up a Release Automation environment for disaster recovery purposes?
There are two types of data that should always be backed up in order to restore a RA environment:
- The RA database.
- All RA configuration files (especially those that have been customized or otherwise altered from default values).
To preserve all data used by and created via Release Automation, full backups of the RA database should be performed regularly in case of any disasters such as data corruption or data accidentally overwritten or deleted by a user or administrator. Follow the procedures outlined for the specific database used by that database product's documentation. This should of course always be performed by and coordinated with the database administrator.
Aside from the database, RA configuration files should be regularly backed up as well in case of data corruption (such as from a crashed disk drive or if a user accidentally edits or deletes these files).
For example, if the Management Server (known as the Nolio Automation Server or NAC in older versions) suffers problems that require a full restore, then all configuration information will be found in the <RAinstalldirectory>\conf directory, thus it is important to ensure the CONF directory remains backed up. Similarly, database connection settings are configured in the <RAinstalldirectory>\webapps\datamanagement\WEB-INF folder, within two files: database.properties and distributed.properties; therefore, the WEB-INF directory is another critical directory to maintain backups of.
Lastly, any customized files or actions should likewise be backed up. Action packs can be found in the <RAinstalldirectory>\actionslib directory.
(This procedure applies to version 5.0 and forward, though similar procedures would apply to earlier versions as well.)
The following RA Communities posts provide details regarding configuration of a RA high availability (HA) environment, which is especially useful when considering a disaster recovery plan, as it allows for automatic fail-over: