Restoring a cluster 

Restore the data in a cluster from the stored backups.

You can 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 you enabled commitlog backups.

When performing a restore operation, you can restore all the keyspaces from a backup or select specific keyspaces and tables.

Note: Keep the following caveats in mind 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 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.