Data Snapshots and Recovery

GridGain provides the ability to create snapshots of data stored cluster-wide, that can later be used for cluster recovery purposes. Having snapshots at hand, they can be used to recover the cluster to a state recorded in a snapshot.

Limitations

There are currently the following limitations on creating snapshots:

Snapshots can only be created on Native persistent and rocksDB primary storages.

Snapshot Scope

Since snapshots store all data, it may be preferable to only create a snapshot of data you need. You can use the following parameters to configure snapshot scope:

--all - creates a snapshot of all tables and distributed maps and sequences. This is a standalone flag that does not accept arguments, and is not compatible with other scope parameters.
--tables - comma-separated list of tables that will be included in the snapshot. Any structures required for the specified tables will be included in the snapshot automatically. Incompatible with --all.
--structures - comma-separated list of distributed structures and sequences that will be included in the snapshot. Any system tables required for the specified structures will be included in the snapshot automatically. Incompatible with --all.

Creating Full Snapshots

To create a full snapshot, use the cluster snapshot create CLI command. For example:

cluster snapshot create --type=full --tables=PERSON

The command above creates a full snapshot of a table Person at a specified destination path (see [Defining Snapshot Paths] for the latter).

Creating Incremental Snapshots

When creating incremental snapshots, successive copies of the data contain only the changes since the last full or incremental snapshot. The base snapshot for incremental snapshots must be a full snapshot, but all subsequent ones can be incremental. The latest valid snapshot will be found for the tables you have specified, and an incremental snapshot based on it will be created.

Here is how you can create an incremental snapshot based on the full snapshot created above:

cluster snapshot create --type=incremental --tables=PERSON

You cannot add more tables to the snapshot when creating an incremental snapshot. You need to have the same tables in it as in the base snapshot created before.

Creating Snapshots in the Past

You can also make a snapshot for the specific cluster state in the past, for example:

cluster snapshot create --type=full --timestamp=2024-09-10T10:53:00+01:00 --all

The timestamp must be specified in ISO format.

Snapshot Encryption

By default, if data encryption is disabled on the cluster, snapshots are also not encrypted. If data encryption is enabled, snapshots will be encrypted by using the same encryption as your data.

You can also manually specify the pre-configured encryption provider in the encryption-provider configuration to use the specific encryption. For more information on configuring encryption, see data encryption.

cluster snapshot create --type=full --tables=PERSON --encryption-provider=keystore

Once the encrypted snapshot is created, it can only be restored by including the decryption-provider in the restore command.

Restoring Snapshots

To restore snapshots, you can use the cluster snapshot restore command.

To make sure your snapshot is restored correctly, follow these guidelines:

Make sure that the cluster topology is the same as the one snapshot was taken on.
Stop traffic to the cluster during restoration to avoid possible inconsistencies and failed operations.

When you are prepared to restore data to the cluster, run the restore command. For example:

cluster snapshot restore --id=8eb10b48-6885-4922-a1af-c28d8473ba28

The command above restores all tables in the snapshot with the specified ID, from the specified source path (see [Defining Snapshot Paths] for the latter). You can also choose to only restore specific tables stored in the snapshot, instead of all of them. In this case, specify the fully qualified table names of the tables to restore, for example:

cluster snapshot restore --id=8eb10b48-6885-4922-a1af-c28d8473ba28 --tables=PERSON

When restoring encrypted snapshots, specify the same encryption provider you used earlier to decrypt the snapshot in the decryption-provider parameter:

cluster snapshot restore --id=8eb10b48-6885-4922-a1af-c28d8473ba28 --decryption-provider=keystore

Heterogeneous Recovery

A REMOTE snapshot created on a GG9 cluster can be restored on the same or on any other GridGain 9 cluster, granted it has enough disk space to accommodate the snapshot data.

Checking Snapshot Status

You can check the status of all snapshots by using the cluster snapshot status command. By default, this command provides information about all snapshots in the cluster.

cluster snapshot status

You can narrow information down by providing the snapshot ID. If you do, you can also use the --all-nodes option to see information about the snapshot on each specific node in the cluster. For example:

cluster snapshot status --id=8eb10b48-6885-4922-a1af-c28d8473ba28  --all-nodes

The command above returns information about all operations with the snapshots per node.

The following information is provided:

Column Description

Column	Description
Operation ID	The ID of the operation. For create operations, this is the snapshot ID. For delete operations, this is the ID of the delete operation.
Start time	Time when the operation was started in UNIX time.
Operation	The operation performed. `CREATE` for creating snapshots, `DELETE` for deleting snapshots.
Status	Current operation status. Possible values: `STARTED`, `COMPLETED`, `FAILED`.
Target Snapshot ID	The snapshot the operation was performed against.
Base Snapshot ID	For incremental snapshots, the id of the snapshot this snapshot is based on.
Description	Operation description.
Timestamp	Point in time that corresponds to the system state the snapshot reflects.
URI	The base URI used by the snapshot operation.
URI Type	The path definition type: LOCAL or REMOTE.

Operation ID

The ID of the operation. For create operations, this is the snapshot ID. For delete operations, this is the ID of the delete operation.

Start time

Time when the operation was started in UNIX time.

Operation

The operation performed. CREATE for creating snapshots, DELETE for deleting snapshots.

Status

Current operation status. Possible values: STARTED, COMPLETED, FAILED.

Target Snapshot ID

The snapshot the operation was performed against.

Base Snapshot ID

For incremental snapshots, the id of the snapshot this snapshot is based on.

Description

Operation description.

Timestamp

Point in time that corresponds to the system state the snapshot reflects.

URI

The base URI used by the snapshot operation.

URI Type

The path definition type: LOCAL or REMOTE.

Deleting Snapshots

You can delete a snapshot using the delete command.

cluster snapshot delete --id [--url]

Where: id is the snapshot’s ID and url (optional) is the cluster’s URL.

For example:

cluster snapshot delete --id=8eb10b48-6885-4922-a1af-c28d8473ba28 --url=http://localhost:10300

Snapshot Location

To specify the snapshot location, you need to configure the snapshot "path" in the cluster configuration, and then use it in your snapshots. If not specified, snapshots use the default directory ({GRIDGAIN_HOME}/work/snapshots if no other default is configured). For a full configuration example, see the Example section below.

The same location must be used for subsequent snapshot operation, for example:

Incremental snapshot destination must have the same URI and type as all parent snapshots.
The snapshot restore operations must point to the same URI with the same type (LOCAL or REMOTE) that was used when creating that snapshot.

Local Snapshots

LOCAL snapshots are not shared between nodes. Every node saves the snapshot metadata and all partition files hosted by the node. Local snapshots can only be restored on the node they were created on.

Depending on how the path is specified, the exact path will be slightly different:

For absolute path, snapshot with ID 1 would be created in the /absolute-path/node-1/snapshot-1 directory.
For relative path, the same snapshot would be created in the {GRIDGAIN_HOME}/relative-path/snapshot-1 directory.

Remote Snapshots

REMOTE snapshots save only one copy of snapshot metadata and partition files. The location where this copy is saved must be accessible by all nodes with the use of the same base URI. The snapshot saves cluster information and data. Remote snapshots can be restored on any node in the cluster, or on a different cluster.

Depending on how the path is specified, the exact storage path will be slightly different:

For absolute path, the same snapshot would be created in the /absolute-path/snapshot-1 directory.
For relative path, the same snapshot would be created in the {GRIDGAIN_HOME}/relative-path/snapshot-1 directory.

Example

For this example, let’s assume that the cluster configuration defines the path in the following way:

{
  "ignite": {
    "snapshot": {
      "paths": [
        {
          "default": false,
          "name": "absolute-path-example",
          "type": "REMOTE",
          "uri": "file:/shared/folder/path"
        }
      ]
    }
  }
}

You can specify the snapshot location by adding the --destination parameter:

cluster snapshot create --type=full --tables=PERSON --destination=absolute-path-example

Snapshots can then be restored from the specified location by specifying the --source parameter.

cluster snapshot restore --id=8eb10b48-6885-4922-a1af-c28d8473ba28 --source=absolute-path-example

© 2025 GridGain Systems, Inc. All Rights Reserved. Privacy Policy | Legal Notices. GridGain® is a registered trademark of GridGain Systems, Inc.
Apache, Apache Ignite, the Apache feather and the Apache Ignite logo are either registered trademarks or trademarks of The Apache Software Foundation.

Last updated on Dec 23, 2025