16.2.1. Backup Procedure

Engineering Knowledge Manager

Administration Guide | Chapter 16: Backing Up and Restoring EKM | 16.2. Backing Up EKM |

16.2. Backing Up EKM |  | 16.3. Restoring EKM
Prev |  | Next

### 16.2.1. Backup Procedure

In order to back up EKM, follow this procedure:

1. Back up the EKM Database.

2. Back up the EKM Data, Version Root, Job Data, and Repository Directories.

It is important to follow this procedure strictly in the sequence given below, as the order of operations is relevant. A brief discussion of the order of operations will illustrate the backup procedure and explain the relationships between the steps. Each step will also be discussed individually, in order to specify what is required at each step.

Sequence:

1. The EKM database is backed up at time T1, using a database dump procedure that ensures consistency of the dump at time T1. All application and user data in the EKM database are captured at time T1.

2. The EKM data directory is backed up at time T2_start where T2_start >= T1. This means that the backup of the EKM data directory starts at the same time or after the EKM database backup. This operation completes at time T2_end. All the data files stored in EKM are captured at time T2_start. Files added between T2_start and T2_end are not relevant as described below.

The EKM version root, job data and repository directories can be backed up at any time.

Important: It is ABSOLUTELY CRITICAL that if garbage collection runs while a backup is in progress that it does not delete any files that were still in use at time T1, as this can cause the backups to become inconsistent, and data loss/corruption could result if they are used to restore from. This can be ensured by setting the interval for dataStoreGC scheduled task to be greater than the time it takes for a complete backup of the datastore. See the description of the `dataStoreGC` setting in Scheduling Automatic Tasks (<scheduledTasks>) for more details.

When restoring, the restore of the EKM database will take place with data from time T1, and the restore of the EKM data directory will take place with data from time T2_start. This is not a problem because of how the EKM data directory and EKM database are related. The end result is that a consistent set of EKM data from time T1 will be restored to EKM. The internal workings of the EKM database and EKM data directory ensure that the data in the EKM database and EKM data directory will be synchronized to contain only data present at time T1. Any leftover, non-referenced data in the EKM data directory will be cleaned up the next time the garbage collection is run (see Cleaning Up Unused Files)*.

*When the EKM database from T1 and the EKM data directory from T2_start are restored, the following conditions apply:

1. Changes to the EKM database after time T1 are not captured because the backup captures the state of the EKM database at time T1.

2. Additions made to the EKM data directory after T1 are discarded the next time the garbage collection is run, as they are not referenced by the EKM database backup from time T1.

3. Deletions from the EKM data directory after T1 are not carried out, as data files deleted from the EKM data directory do not actually get deleted until the next time the garbage collection is run. Note that this cleanup must not run between times T1 and T2_end.

4. Updates/edits to existing files in the EKM data store are implemented internally as adds/deletes, so the previous rules governing additions and deletions apply to modifications of existing items.

#### 16.2.1.1. Garbage Collection

Garbage collection, also referred to as "cleaning" the EKM data directory, is an operation that can be run by the `dataStoreGc` task, which is configured in ekm.xml or can be started by a superuser from the EKM Server Administration interface (see Cleaning Up Unused Files). It is described here, because it affects backup operations.

#### 16.2.1.2. Backing up the EKM Database

The procedure for backing up the EKM database varies by database server type; follow the directions provided with your database server.

Note: For the MySQL database server, use the `mysqldump` command to back up the EKM database. EKM uses the ACID-compliant InnoDB storage engine under MySQL, as opposed to the default MyISAM storage engine, so certain options to the `mysqldump` command must be used. These options are demonstrated in the example below.

Here is the suggested command-line for dumping the `ekm` database using `mysqldump`:

    MYSQL_HOME/bin/mysqldump --databases ekm --single-transaction --hex-blob > ekm.sql

where ``MYSQL_HOME`` is the directory where the MySQL database server is installed.

#### 16.2.1.3. Backing up the EKM Data, Version Root, Job Data, and Repository Directories

Once you have backed up the EKM database you can back up the EKM data, version root, job data, and repository directories.

To back up these directories, take a full copy of each directory, including all files and subdirectories. It is recommended that an enterprise-quality commercial backup solution be used to perform the file backups of these directories.

- `\datastore`

- `\jobdata`

- `\repository`

- `\v182` (`EKM_ROOT182`)

Contains proprietary and confidential information of ANSYS, Inc. and its subsidiaries and affiliates.

Prev | Up / Contents | Next

Release 18.2 - © ANSYS, Inc. All rights reserved.