Restoring a cluster
Restore the data in a cluster from the stored backups.
Restore data to a cluster from local keyspace backups and backups stored to cloud storage providers like Amazon S3. These restores can be from a particular point-in-time if commit log backups are enabled.
When performing a restore operation, you can restore all the keyspaces from a backup or select specific keyspaces and tables.
Note: Consider the following caveats when creating and restoring backups:
- Restoring a snapshot that contains only the system keyspace is not allowed. There must be both system and non-system keyspaces, or only non-system keyspaces in the snapshot you want to restore.
- Restoring a snapshot that does not contain a table definition is not allowed.
- Restoring from a backup while Kerberos is enabled is not currently supported by OpsCenter.
- Restoring a snapshot to a location with insufficient disk space fails. The Restore Report indicates which nodes do not have sufficient space and how much space is necessary for a successful restore. For more information and tips for preventative measures, see Monitoring sufficient disk space for restoring backups.
When restoring from backups stored on Amazon S3, OpsCenter chooses an agent to determine which
nodes in the cluster have data that needs to be restored. The SSTables stored in the S3 bucket
are sorted into directories with the node ID of the original node. If the cluster topology is
unchanged from when the backup was taken, OpsCenter instructs each node to restore the set of
SSTables that were stored on that node before. If the cluster topology has changed since the
backup was completed, OpsCenter attempts to match the SSTables to the node that originally stored
the SSTable, and distributes the remaining SSTables to the remaining nodes to balance the load
evenly.
Note: The Restore feature of the Backup Service leverages the sstableloader utility,
which currently requires enabling the thrift server on all nodes before restoring.