Backup of system image files

inmation stores all information relating to the models, namespaces and object configuration in the image files. If you encounter problems with hardware failure or file corruption, or if you wish to migrate your system to new hardware, it is possible to restore your full system using the image files themselves or a back-up of the image files.

Each inmation service (Core, Connector, Server etc.) has image files that are created in the img folder under the inmation.root directory. Three files are created for each running service with different functions and file suffixes:

Table 1. Image file types
Image File Type	File suffix	Description
Image file	*.inimg	The image file contains all the data regarding your system configuration including model trees and object configurations. A back-up of the image file should be created regularly to provide data security in the event of any hardware failure or system corruption. Note: the image file does not contain historical data for objects, only configuration data.
Fingerprint file	*.infp	The fingerprint file contains other contextual data needed by the image. When restoring the system from the image file, it is necessary to also have a copy of the fingerprint file.
Image (last known good image)	*.inlkg	The “last known good” image file is a snapshot of the system image in its last known good state. This file can be used to restore the system if the main image file is corrupted or doesn’t work properly. This will be explained in the next section

Service image files

The most important image files are the Core image files. The Core image is able to store all the system data for all services from the last time they were connected and create the appropriate Connector or Server image file in the appropriate locations on restart of the services. The Connector and Server image files are important if there is disruption between the Core and Connector/Server communication as configuration changes for disconnected remote services will not recorded in the Core image. If disruption is expected, it is prudent to maintain image back ups for remote components as well as the Core image.

Persistency database files

Dynamic property values of objects under components are persisted to database files in the “inmation.root\work” directory. This allows for the last dynamic value to be read back after service restart after unexpected shutdown. The persistency database files should also be regularly backed up if you do not wish to lose any dynamic property values. Each component has its own persistency database file called “dynprop.db” stored in the “db” folder of the appropriate component folder in the “work” directory. For example the persistency database file for the Core component can be found at “inmation.root\work\core\db\". The frequency that dynamic values are persisted to the database file is configured under Archive Options using the Persistency Mode property.

Restoring system from image file

The exact steps to restore your system from image files will depend on the exact situation and reasons for the restore. These are general guidelines for restoring the system and may require more or fewer steps depending on the situation.

Stop any inmation services (if any are running) in Task Manager or Services
Locate the inmation.root directory on the hard drive
Copy the image back-up files to the “img” folder (include *.inimg, *infp and *inlkg files)
Restart inmation services and check to see that they remain running
Attempt to connect to the Core with DataStudio and check the communication status of Connector, Server and Relay objects
Check the log for information or errors

If the services fail to restart (or fail to keep running after restart), there might be corruption of the image file so the “last known good” image file should be used. To do this:

Stop any inmation services (if any are running) in Task Manager or Services
Remove the image file (*.inimg) that is not working form the “img” directory or rename it to something else
Locate the “last known good” image file (*.inlkg) and change the suffix to *.inimg. For example, change “core.inlkg” to “core.inimg”
Restart the applicable services
Attempt to connect to the Core with DataStudio and check the communication status of Connector, Server and Relay objects

If you stop the inmation services and delete the existing image files, upon service restart, new image files will be created but your system configuration will be lost.

Image files contain the system configuration but does contain any historical data for the objects. All historical data is stored in the MongoDB repository.

Restoring Persistency Database files

To restore the backup of the persistency database file:

Stop the inmation services (if any are running) in Task Manager or Serves
Locate the inmation.root directory on the hard drive
Copy the backup of the database persistency file to the db folder in the appropriate component folder of the work directory (e.g. “inmation.root\work\core\db\" for the Core)
Rename the file to dynprop.db necessary
Restart inmation services

Creating Image Backups

Backups of image files can be created manually by simply making copies of the image files to a new location. Image back-ups can also be made using the Lua interface by using the internal syslib.backup library (library is called at the beginning of the script using the "require" command) The IMAGE() backup function will create backups of the image file, the fingerprint file and the persistency database file (containing persisted dynamic property values for the component). The function requires a valid path, including a name for the image dump file, to create backup files. The IMAGE function is called using the Lua “:” notation. For example:

local backup = require('syslib.Backup')
local ok, err = backup:IMAGE("C:\backups\core_backup_img")
return ("ok: %s, err: %s"):format(ok, err)

This will create an image, fingerprint file in the “D:/backups” directory. These will be named:

core_backup_img.inimgdump core_backup_img.infpdump core_backup_img.dbdump

The directory specified in the file path must exist before execution for the script to work.

These commands are designed to create back-ups of the Core’s image and fingerprint files, therefore the scripts should be run in a Core context i.e. by objects directly beneath the Core. If the script is run at the Connector level (or context), then the Connector image, fingerprint and persistency database backups will be created. If the filename already exists, it will be overwritten by the Lua command with the image files. If no filename is provided then an error message will be displayed alerting you to enter a filename as well as a directory path. If the directory path is not valid, an error message will also be returned. To restore these image dump files, follow the steps detailed earlier, remembering to rename the image and fingerprint files appropriately (e.g. to “core.inimg” and “core.infp”).