Restore
Introduction
Restoring from an Infinite Scale backup can be a task bringing the instance back to production after a major incident occurs.
Though no restore strategies are covered, reading this document can add valuable information when creating a backup and restore strategy.
General Considerations
Infinite Scale can run in two different setups when it comes to storing data:
-
All data, meaning configuration, blobs and metadata, is stored on POSIX-compliant filesystems.
-
Blobs are stored on an S3-compliant storage while configuration and metadata are stored on POSIX.
See the backup documentation for more details.
When it comes to restoring data, keep in mind that you always have to restore all data sets consistently:
-
config data
-
system data 1
-
metadata 2
-
blobs 2
(1) … System data has, if not otherwise defined, a common root path which is the same root path as for metadata. Individual paths can be defined for particular services though. See the Base Data Directory for more details. Also see the search configuration example. If the search index does not get restored, it needs to be recreated.
(2) … For POSIX-only environments, the location for blobs and metadata is the same. When using S3, the location differs. The restore process must include the metadata, for details see Filesystems and Shared Storage.
Valid for all restore procedures:
-
first check the basic configuration of Infinite Scale on the backup to prepare the necessary volumes, mount points and directories if they are not present on your Infinite Scale instance,
-
Infinite Scale must be in stopped state.
As a rule of thumb, consider also to restore the Infinite Scale binary or the backed-up container. This avoids difficulties after restoring the instance and possibly using an updated Infinite Scale version compared to the version used when backing up. Restoring and updating should always be different tasks.