Disaster Recovery Process


The primary disaster recovery strategy is to use a backup/snapshot system. This is managed by client IT operations, who is responsible for the backups (and at a minimum, file recovery). If primary restore (an “image recovery”) fails, it may be necessary to recover the system from the individual file backups using the procedures in these sections.

To fully restore a system from a file-system backup/snapshot, the client IT team has to restore the relevant backup image. Typically, the restore will reinstate a known working image of the server at the time of the backup. This image will resume operation as it was at the time of the backup, and the user should then check to ensure it has resolved the issues that triggered the restore operation. Necessary checks to fidelity should be made as per “file based” restoration - it should not be assumed that an “image recovery” has been successful in isolation. These checks are highlighted in these sections.

When an “image recovery” is not possible or does not meet the recovery needs of the AspenTech Inmation administrators, normally a request for backup/restore will be made to the responsible IT team, using the necessary procedures, and at a minimum, the s:i admin requester must know:

  • Paths to files to be recovered

  • The date to be recovered (or nearest available to this date, usually nearest prior)

  • Location to store recovered files (file data area where the IT recovery team stores files for further recovery by the s:i administration team)

The required files will be determined by the backup to be restored (AspenTech Inmation configuration files or MongoDB /data folder) and will be highlighted in the relevant section.

Backup is not a responsibility of the s:i administration team, but of the appropriate client IT team.


  • Backup - processes and files for backup

  • Restore - processes for recovery of AspenTech Inmation and MongoDB

The sub-sections are intended for guidance for system disaster recovery in the event of hardware failure or file corruption. It covers the steps needed to create backup files (although this is informational, as backup is the responsibility of the appropriate IT team), and to restore system and archived data in the worst case disaster recovery scenarios.

Steps to recover from other scenarios can be implied from these worst case scenarios as a subset of actions. For example, recovery of MongoDB database on a server where the software is installed but the data is corrupt will not require a complete recovery of the server from “bare metal”, but only the relevant steps to restore the MongoDB data.


This diagram shows the disaster recovery plan for the s:i platform:

Recovey Plan