Cloning cluster data from clusters managed by the same OpsCenter instance

Clone cluster data from one DSE cluster to another using the Restore Backup feature in OpsCenter. This workflow requires the source and target clusters to both be managed by the same OpsCenter instance.

Clone cluster data from one DSE cluster to another using the Restore Backup feature in OpsCenter. This workflow requires the source and target clusters to both be managed by the same OpsCenter instance.


To clone the cluster data, there must be an existing backup of the cluster to a Local FS or an Amazon S3 location. See adding a backup location.

Note: Cloning encrypted tables to a different cluster does not work unless the encryption keys are identical, which is typically not the case.
Important: The Backup Service requires control over the data and structure of its destination locations. The backup destinations must be dedicated for use only by OpsCenter. Any additional directories or files in those destinations can prevent the Backup Service from properly conducting a Backup or Restore operation.


  1. Click the source 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.

    Step 1 of 2: Select Backup, Restore from Backup dialog
  4. In the Backups tab, select the backup that contains the data you want to clone and click Next.
    Note: On Server backups are not eligible for cloning.
    The Restore from Backup: Step 2 of 2 dialog appears.

    Step 2 of 2: Configure and Restore (Clone), Restore from Backup dialog, Location available

  5. In Keyspaces and Graphs, select the tables or graphs included in the backup you want to restore.
    1. 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.
    2. Click the graph name to include all the graphs in the keyspace. Click All Graphs to restore all the keyspaces. To select only specific graphs, expand All Graphs and select the graph keyspaces.
  6. Under Location, select the target cluster for the restored data. Select a different cluster than the one that was backed up to clone the data to the cluster.
    The Location list is only available when there are multiple clusters and both clusters are managed by the same instance of OpsCenter.
  7. When cloning data, it is not necessary to select the Truncate/delete existing data before restore option because it is a no-op for a cloning workflow. The truncate option purges data on a target before a restore runs. When using the restore feature to clone, the truncate option does not do anything because there is no data to purge before the restore runs.
  8. To prevent overloading the network, set a maximum transfer rate for the restore. Select Throttle DSE stream throughput at ____ MB and set the maximum MB per second.
  9. Optional: Change the staging directory if necessary by setting the backup_staging_directory configuration option in address.yaml.
  10. Required: Click Restore Backup.
    The Confirm Restore dialog appears.
    Confirm restore operation dialog
    Warning: If a value was not set for throttling stream output in 8, a warning message indicates the consequences of unthrottled restores. 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.

    Update throttle options in LCM

  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.


The details and progress of the restore operation are displayed in a progress dialog, and also appear in the Backup Activity of the target cluster. If you close the progress dialog, track the progress and status of the restore in the target cluster's Backup Activity section.

The progress and details of the restore operation are displayed in the Restore Report.