Making a backup of the Infinite Scale instance is an important task that should be done on a regular basis. This ensures that in case of issues, data can be restored from a backup.

Though no backup 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.

For details on supported filesystems, see: Filesystems and Shared Storage.

Depending on how this data is stored, backup strategies and tasks will differ (see the sections below).

You have to fully stop the Infinite Scale instance to create a consistent state necessary for performing the backup. In the following scenarios, this state of consistency is a prerequisite for all upcoming tasks. To avoid redundancy this step will not be repeated every time. When the backup is finished, Infinite Scale can be started again.

Note that creating a backup may only take a few seconds if the underlying filesystem of your storage provides snapshot capabilities. After taking the necessary snapshots, the Infinite Scale instance can be started again. To prevent data loss in case of hardware failure, we recommend copying the snapshots to a secondary storage.

See the Default Paths for more information on where data is saved and how different locations can be defined.

Keep in mind that you always have to back up all three data sets consistently:

  • config data

  • metadata 1

  • blobs 1

(1) …​ For POSIX-only setups, the location for blobs and metadata is currently the same. When using S3, the location differs.

As a rule of thumb, consider also to backup the Infinite Scale binary or the container used. This avoids difficulties when 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.

Pure POSIX Setup

If all data - configuration, blobs and metadata - are stored on POSIX-compliant filesystems, create a consistent state and back up the data sets. This is easiest if you have only one filesystem for all of them. If you have different filesystems for the config and blobs/metadata, you need to do this task for each of them.

Distributed Setup

If data is distributed with configuration and metadata stored on POSIX-compliant filesystems and blobs are stored on S3, create a consistent state and back up:

  • the configuration and metadata,

  • the S3 bucket according to the rules and possibilities of the S3 provider.