Best practices: Backing up ALM Octane data
This topic provides best practices and recommendations for backing up ALM Octane and all its components.
ALM Octane stores its information in the following components:
Your relational database (either Oracle or SQL Server). This is where the most important system data are located. The relational database is the most important component of the backup.
Database systems support hot backup procedures and provide the ability to restore operations to the last second before the system crash.
Elasticsearch. Elasticsearch stores trend data, run history, search information, and additional miscellaneous items.
You can take periodic snapshots of Elasticsearch data.
The repository folder on your file system. ALM Octane includes its own file system repository where attachments, manual scripts and other artifacts are kept. The default location for this folder is:
You can take periodic snapshots of repository data.
To fully back up ALM Octane, back up all its components: the relational database, Elasticsearch, and the repository folder. Store each backup in a separate location to allow for (disaster) recovery.
Time may elapse as you back up each of these components. In terms of time difference tolerance, the time as specified in the relational database is used as the determining factor. When you restore ALM Octane, it is the data and timestamps stored in the relational database that users see. Keep this in mind when restoring.
If you backed up your relational database, added files, and only then backed up the repository, the files exist after restore, but ALM Octane does not see any associations to them, and eventually deletes them.
Conversely, if you backed up the repository, added files, and only then backed up the relational database, ALM Octane might report that you have some broken associations, as the files do not exist in the repository while ALM Octane tries to find them.
Frequency of backups
While database systems, such as Oracle and SQL Server, support hot backup procedures and provide the ability to restore operations to the last second before the system crash, it is only possible to take a periodic snapshot of the Elasticsearch and ALM Octane repository.
Therefore, how often you should back up is determined by the amount of down time your site can tolerate. If the amount of tolerated time is one day (meaning, the company is fine with the ability to restore the operation to the state of 24 hours ago), the suggested backup frequency could be defined as one day. If the amount of tolerated time is 12 hours, backups should run every 12 hours.
Example: ALM Octane operations on SaaS are backed up every 4 hours. In most cases, hot backups and dumps/snapshots should then be either moved to a separate location or put on removable media for storage.
Backing up the relational database
Use the database's backup mechanism and save the resulting files and folders.
Open files do not pose a problem during the backup, as most files are not locked by ALM Octane.
The relational database is the most important component in the backup.
Back up each component as closely as possible, one after the other.
Back up ALM Octane during quiet times to minimize missing files, broken file associations, and time inconsistencies between the three components.
Recommended order for backing up components
Here are suggested guidelines and the sequence of backup actions to take.
Always back up the database first. Use the database vendor's, or commercially-available, tools to perform a hot backup (such as Oracle RMAN). We recommend that you take a snapshot (dump) before performing any major operations on the database, such as an upgrade, data migration (such as from Agile Manager to ALM Octane), massive import, and so on.
See https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html on the Elasticsearch site.
To back up properly in a clustered Elasticsearch environment, attach shared storage to which snapshots from each node can be saved.
Lastly, back up the ALM Octane repository. Make a complete backup using operating system capabilities (tar, zip) or commercially-available tools.