Backup and Restore

Restoring Condition Monitoring or Rules Management from a backup:

Precondition:

The data in MACMA, MDM has been restored already (including dynamic resources) or is in a state which is not older than the backup to be restored for CM/RM.

Note: Be aware, that data of incoming RabbitMQ messages which are processed during the restore process might be lost.

Restore Condition Monitoring including Rule Management relational database.
Restore Condition Monitoring Influx database.
Restore Rules Management Kafka topics.
Restart Condition Monitoring services after data restore so that the local caches are built.
Run MDM sync for condition-monitoring-core each tenant which was restored (see Reload MDM for CM).
Run MDM sync for rule-service-app each tenant which was restored (see Reload MDM for RM).

Precondition:

The source IAS instance should not be actively used during the operation, to make sure no data get lost during the cloning.
There are no pending messages in RabbitMQ queues related to RM respectively CM.
The data in MACMA, MDM has been cloned already (including dynamic resources) and no data has been changed in MACMA and MDM (e.g. new device created, relink of device to another facility) in the target system since then.

Condition Monitoring does not hold environment specific information in the database tables.
If all environment variables are updated accordingly, a Condition Monitoring instance can be cloned to a new host by cloning all Condition Monitoring including Rule Management relational database tables (starting with "CM_" and "RM_").
Clone also Condition Monitoring Influx database to a new host (if required).
Clone Rules Management Kafka topics if you are switching to a new Kafka host and the same rule execution behavior is expected between source and target system.
Restart Condition Monitoring (including Rule Management) services after data cloning so that the local caches are built.