Restore

Restore from System Backup

This section describes how to restore from a system backup. For disaster recovery, the worst case scenario is complete corruption of the server (files on its disks), which requires recovery of data stored within the server backups. Other backup requirements, such as data loss on a server that continues to operate otherwise, will only need a subset of the recovery process to revert back to acceptable operation. This section provides an overview on the principles and actions required for AspenTech Inmation recovery.

General Principles

The overall process is to perform a system installation and then a data recovery for both Master and Local Cores, and MongoDB databases. In essence, this is creating a new server machine by using the IaC procedures in the program standards, and then populating these “nascent” servers with the recovered backup information as required.

Primary Recovery

The primary method of recovery is to recover the disk image (snapshot) from the hypervisor and revert to this snapshot, which restores the machine to the state when the snapshot was taken. This method should be attempted first, using the appropriate procedures (see Server Infrastructure Backup for details specific to this implementation), and further methods are required only if snapshot image recovery fails.

Even if snapshot recovery is successful, it is still necessary to follow the post-restore protocols within this guide to confirm successful recovery and ensure continued operation of the AspenTech Inmation solution as necessary.

system:inmation Recovery

See AspenTech Inmation Recovery for more details.

Master Core

To recover the Master/Central Core server, the following steps perform a “bare metal” recovery. If the existing software is installed and functional, but perhaps a configuration file is corrupted or missing, simply start at step #2.

  1. Install the Master Core using the IaC procedure on a server configured per IaC prerequisites.

  1. Stop all AspenTech Inmation services (AspenTech Inmation and MongoDB).

  2. Delete (temporarily archive into a ZIP file first if required) any existing IMG files and the MongoDB data folder

  3. Copy IMG, persistence and local MongoDB data from backup to the appropriate folders.

  4. Restart all services.

  1. Check the configuration of AspenTech Inmation to ensure correct operation.

Further details on restoration of the AspenTech Inmation files can be found in AspenTech Inmation Recovery.

Local Core

If the Master Core is connected and visible from the Local Core machine (if necessary, through a Relay), then it will be possible to recover the local Core configuration automatically from the Master Core, which will update the local Core on connection with configuration held in the Master Core. If the Local Core software is present but its configuration is corrupted, start at step #2.

  1. Install the Local Core using the IaC procedure.

  1. Stop all AspenTech Inmation services (AspenTech Inmation and MongoDB).

  2. Delete the IMG files.

  3. Restore the local MongoDB data from backup.

  4. Restore the persistence data only.

  1. Start all AspenTech Inmation services (AspenTech Inmation and MongoDB).

  2. Check the configuration of the Local Core has been updated from the Master Core (this may take some time to replicate across the network) and that operation is as expected.

The same process can be used to restore a connected component (Connector, Interface Server, Relay), ignoring steps 4 and 5, and adapting the other steps to the specific component instance (e.g. two AspenTech Inmation services may be present on an Interface Server).

Further details on restoration of the AspenTech Inmation files can be found in AspenTech Inmation Recovery.

MongoDB Recovery

See MongoDB Recovery for more details.

MongoDB - Single Server (Master or Local)

For the loss of a single MongoDB server instance on either the Central or Local systems, it will be sufficient to restore the server with base MongoDB (using the program standards for IaC) to ensure the MongoDB instance (and AspenTech Inmation Connector service) are present and operational. The MongoDB instance will be configured as part of the existing replica set, and the collective MongoDB operation will ensure data is replicated back to that instance accordingly.

  1. Install MongoDB on primary/secondary using the IaC procedure.

  2. Check the operation of the replica set for the restored server, and the set as a whole.

MongoDB will repair the replica set automatically. Check the operation of the Replica Set from the mongo shell or using the appropriate Data Studio Health Monitoring KPIs.

For a single MongoDB server, always restore the MongoDB IaC as if it were a Secondary Node, since MongoDB would have promoted another running server to Primary in operation.

MongoDB - Master (full recovery)

If the entire Central system MongoDB cluster has been lost, or is required to be reinstated for other reasons (such as server migration), and snapshot recovery is not possible for two or more of the associated node servers, the following steps are required:

  1. Reinstall MongoDB replica set (all three servers) using the IaC procedure.

  2. Restore database files from backup recovery files using the provided restoration function script (see MongoDB Recovery).

  3. Check the operation of the MongoDB replica set.

MongoDB - Local (full recovery)

If the entire local site MongoDB cluster has been lost, or is required to be reinstated for other reasons (such as server migration), and snapshot recovery is not possible for two or more of the associated node servers, it will be necessary for the MongoDB data to be recovered from the Central Core MongoDB server instances. This is because large backups of the MongoDB might not be possible on the site servers, because of disk size limitations or local backup policies. The AspenTech Inmation design allows for local site MongoDB data to be simultaneously replicated into the Central MongoDB data stores, and therefore it can be recovered from this repository to rebuild the local systems.

The following steps are required:

  1. Reinstall MongoDB replica set (all three servers) using the IaC procedure.

  2. Identify and extract the collections in the Central MongoDB instance to a file location that can be accessed from both Central and the relevant site. If this is not possible, the extracted files must be transferred to a local site file store for recovery.

  3. Import the copied collections from the Central repository to the local MongoDB instance, following the steps in the appropriate section of MongoDB Recovery.

  4. Check the operation of the MongoDB replica set.