Data Backup and Restore

This topic contains the following sections:

General Considerations on Data Backups

Data loss may not be the result of careless or erroneous actions of authorized users or defects in storage media alone, but may also be the consequence of malicious deletion or encryption of your data by unauthorized intruders. The consequences of data loss are usually manifold and very expensive, possibly even existential: from production downtime/standstill of your plant to the loss of proprietary data and essential know-how.

Backup Strategy

A common backup practice is "3:2:1". This means: create a triple backup to two different media, one of which you keep offline in a secure place (protected against theft and fire).
Perform backups regularly or event-triggered.
The required interval for regular (scheduled) backups depends on the change intensity of the data: Data which are modified often (such as application development) should be backed up daily. Configuration or system data that is changed/updated less frequently can be backed up either at reasonable longer intervals or on an event-driven basis.
Create full backups and incremental backups.
Depending on the requirement for the availability of backups for restoring systems, daily backups, for example, can be kept locally (e.g., on additionally installed hard disks or immediately available SD cards), while long-term backups can be stored externally.
The ongoing operation of a plant must not be impaired by the backup process. Depending on the situation in your plant, backups should possibly be created during a production shutdown (e.g. after commissioning and before the start of productive operation or during maintenance phases) so that ongoing production is not affected.
A backup should be able to recover a system/plant to a known (i.e. clearly documented) secure state (of operation).

What data should be included in the backup?

A backup should include data on user level as well as on system level.

Operating systems and firmware
Device configuration/parameterization/control data.
Security-related data such as keys and certificates.
Application programs running on, e.g., controllers.
Production data including e.g., recipe data bases.
Logging and monitoring data including e.g., data logger sessions of event log data bases.
Current security settings of the component/system.
After a recovery, the security-related state must be clearly determinable/readable.

Integrity and Verification of Backups

According to the IEC 62443 standard, backups are to be considered as "information at rest". As a consequence, their integrity and confidentiality should be protected in the same way as for your entire plant.
Encrypt backups, if possible.
Each Backup should contain characteristic data (such as checksums) which allow to verify the integrity of the stored data. You must be able to detect modifications that have been made to the data as well as defects of the backup storage media.
For each device, you should document when a backup was created and what type it is (full/incremental). In addition, backups should be informative and clearly documented. This includes that for each backup the time of creation, the contained data status and, if applicable, the backed up device can be identified.

Storage of backup media with regard to confidentiality and availability

Backup data must also be protected, i.e. its confidentiality, integrity and availability should be ensured at all times. Therefore, the storage location for backup media must meet some requirements:

Physical access to the backup media should be restricted and controlled accordingly. For example, a fireproof safe can be used, to which access is only permitted after appropriate authentication.
Clear authorizations must be defined for accessing and restoring backups and enforced by means of organizational and technical measures.
In case of emergency, access to the backups must be fast and guaranteed.
Backup media must be permanently protected from external influences (moisture, heat, fire, etc.). Climatic conditions must also be suitable for long periods of storage.

Restoring Backups

Prior to initiating a restore process of backed up data, ...

the integrity of the backup data must be verified.
you have to make sure that the backup recover a known and secure state (of operation) of the system/plant.

After you have restored a backup, you should ...

determine the current security-related state of the component/system/plant.
thoroughly test and verify the correct function as well as the safety-related and secure operation of the entire application.