Restoring from a backup

Restore data from a previously completed backup run from OpsCenter.

1. Click cluster name > Services.
2. Click the Details link for the Backup Service.
3. In the Activity tab, click Restore Backup.

   The Restore from Backup dialog appears.

   
4. Select the backup to restore in the list of backups and click Next.
   1. The Backups tab lists the available keyspace backups, including both scheduled and manual backups.
   2. If you are restoring from a location that is not listed in the Backups tab, select Other Location.

      Selecting a backup from Other Location is most commonly used when cloning a cluster, but can be used when this OpsCenter instance is not aware of the backup location.

5. Select the tables included in the backup you want to restore. Click the keyspace name to include all the tables in the keyspace. Click All Keyspaces to restore all the keyspaces.
   
   

   

   
   

   To select only specific tables, expand the keyspace name and select the 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 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.
6. Under Location, select the target cluster for the restored data.
   • The Location list is only available when there are multiple clusters and both clusters are managed by the same instance of OpsCenter.
   • If you select a different cluster than the one that was backed up, the data is cloned to the selected cluster. See cloning cluster data.

   Note: Restoring encrypted tables to a different cluster does not work unless the encryption keys are identical, which is typically not the case.
7. Optional: To remove the existing keyspace data before the data is restored, select Truncate/delete existing data before restore. This completely removes any updated data in the cluster for the keyspaces you are restoring.
8. To prevent overloading the network, set a maximum transfer rate for the restore. Select Throttle stream throughput at ____ MB and set the maximum MB per second.
9. Change the staging directory if necessary by setting the backup_staging_directory configuration option in address.yaml.
10. Click Restore Backup.
    The Confirm Restore dialog appears.

    

    Warning: If a value was not set for throttling stream output in 8, a warning message indicates the consequences of unthrottled restores. The throttle warning only appears for versions of DSE from 4.8.7 and later. Either click Cancel and set the throttle value in the Restore from Backup dialog, set the values in cassandra.yaml (stream_throughput_outbound_megabits_per_sec and inter_dc_stream_throughput_outbound_megabits_per_sec), or proceed anyway at risk of network bottlenecks.

    Tip: If you are using LCM to manage DSE cluster configuration, update Cluster Communication settings in cassandra.yaml in the config profile for the cluster and run a configuration job. Stream throughput (not inter-dc) is already set to 200 in LCM defaults.

    

11. Click Start Restore to confirm the restore.
    If the pre-restore checks detected schema differences that could not automatically be validated, the Restore Schema Validation dialog appears. Possible issues are listed and a comparison of the backup and current schema are presented side-by-side.

    

12. Review the information to determine what adjustments if any need to be made to the current schema:
    • To rectify the schema issues and try the restore again afterward, click Cancel.
    • To proceed despite the schema mismatch, click Continue Restore.
      Warning: Attempting to restore a backup with an incompatible schema might result in corrupt or inaccessible data. Before forcing the restore, you might want to back up your current data.