Best practices for backing up ALM Octane data

This topic provides best practices and recommendations for backing up ALM Octane and all its components.

Overview

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, audit information, 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: 

    • Linux: /opt/octane/repo

    • Windows: C:\Program Files\octane\repo

    You can take periodic snapshots of repository data.

Back to top

The process

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.

Order matters

  • 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

Database systems such as Oracle and SQL Server usually support hot backup procedures and provide the ability to restore operations to the last second before the system crash. However, in ALM Octane, it is only possible to take a periodic snapshot of the Elasticsearch and ALM Octane repository, but not the relational database.

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.

Back to top

Best practices

The relational database is the most important component in the backup. 

General

  • 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.

  1. 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), or massive import.

  2. Back up Elasticsearch next. Elasticsearch is a NoSQL database geared toward fast textual indexing and search. You can take a snapshot of the Elasticsearch indexes periodically using REST API commands from any programming language (for example, JavaScript). Kibana is one tool recommended by Elasticsearch for issuing REST API commands.

    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.

  3. Lastly, back up the ALM Octane repository. Make a complete backup using operating system capabilities (tar, zip) or commercially-available tools.

Back to top

See also: