Restoring a cluster
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.
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.
OpsCenter does not back up indexes. Therefore, DSE must recompute the indexes after a restore.
When restoring from backups stored on Amazon S3, OpsCenter chooses a DataStax Agent to determine which nodes in the cluster have data that needs to be restored.
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.
When restoring backups on clusters running DataStax Enterprise (DSE) 6.0.0-6.0.2, materialized views might return no results when queried. To mitigate this issue, see Restoring materialized views.