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.
Prerequisites
To clone cluster data, a backup of the cluster to a supported location must exist.
See adding a backup location.
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.
Procedure
-
Click .
-
Click the Details link
for the Backup Service.
-
In the Activity tab, click Restore
Backup.
The Restore from Backup dialog
appears.

-
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.
-
In Keyspaces and Graphs, select the tables or graphs you
want to restore.
- Click All Keyspaces or All
Graphs to restore all keyspaces or all graphs.
- Click the keyspace name or graph name to include all tables or all
graphs in the keyspace.
- To select specific tables or graphs, expand the keyspace name or graph
name and select the specific tables or graphs to back up.
Note: For DSE 6.0.0-6.0.4, when restoring a DSE
Graph backup without selecting Use sstableloader, DSE
must be restarted to ensure all data is available.
-
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.
-
When cloning data, it is not necessary to select the Truncate/delete
existing data before restore option because it is a not
operational 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.
-
To prevent overloading the network, set a maximum
transfer rate for the restore using the Throttle DSE stream
throughput at ____ MB option.
Note: To enter a value for this option, you must select Use
sstableloader. Otherwise, the transfer rate value is
ignored.
- Optional:
To bulk load external data into a cluster, select Use
sstableloader.
Important: OpsCenter 6.7.5 and earlier cannot
execute a restore that bypasses sstableloader
for
DataStax Enterprise (DSE) 6.7.6 and later, DSE 6.0.11 and later, and DSE
5.1.17 and later. This issue is caused by an OpsCenter check that cannot
validate the SSTable format change in DSE 6.7.6. To restore data on a
cluster from a DSE backup with the new SSTable format, select
Use sstableloader when restoring data or
upgrade to OpsCenter 6.7.6 or
later.
(OPSC-16237)
Note: Using sstableloader restores data to a cluster regardless of its original
topology, at the expense of speed and performance. Restoring to a cluster
that uses tiered storage requires using sstableloader. See
sstableloader for details.
When restoring from a backup, OpsCenter might report that the
restore was successful, even if it failed. This behavior can occur when
copying SSTables into the new data directories and running
nodetool refresh
afterward. To determine whether
the restore failed, search the DataStax Agent logs for a string indicating "Error
copying sstables to data dir:"
. This issue is present only
in OpsCenter 6.7.0.
- Optional:
If necessary, change the staging directory by setting the
backup_staging_directory
configuration option in address.yaml.
-
Click Restore Backup.
The Confirm Restore dialog appears.

Warning: If a value was not set for
throttling stream output, a warning message indicates the consequences
of unthrottled restores. Take one of the following actions:
- Click Cancel and set the throttle value
in the Restore from Backup dialog.
- Set the
stream_throughput_outbound_megabits_per_sec
and
inter_dc_stream_throughput_outbound_megabits_per_sec
values in cassandra.yaml.
- Proceed anyway at the risk of creating network bottlenecks.
Tip: If using LCM to
manage DSE cluster configuration, update Cluster Communication settings
in
cassandra.yaml in the
configuration profile
for the cluster and
run a
configuration job. Stream throughput (not inter-dc) is set to
200 in LCM defaults.

-
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.

-
Review the information to determine if adjustments or corrections to the
current schema are required :
Results
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.