A point-in-time restore uses commitlog archives to restore data from a particular
date and time using OpsCenter.
For a point-in-time restore, OpsCenter intelligently chooses which snapshots and
commitlogs to restore from based on the date and time you are restoring the cluster
to. If an acceptable combination of snapshots and commitlogs cannot be found, the
restore will fail and a detailed error message is visible in the
Activity section of the OpsCenter UI.
dse-env.sh
The location of the dse-env.sh file depends on the type of
installation:
- Package installations: /etc/dse/dse-env.sh
- Tarball installations:
install_location/dse/dse-env.sh
Prerequisites
- For point-in-time restores to work, you must have enabled commitlog backups and performed
at least one snapshot backup before the
time to which you are restoring.
- The Restore feature of the Backup Service leverages the sstableloader utility,
which currently requires enabling the thrift server on all nodes before
restoring. Before restoring, ensure the thrift server is enabled on all
nodes.
- When performing a point-in-time restore, the cluster topology must not have
changed since the backup. Attempting to perform a point-in-time restore on a
cluster whose topology has changed results in a failure. DataStax recommends
performing a snapshot backup before changing cluster topology. You can then
restore the cluster based on that backup.
- Known limitations:
- Point-in-time restore cannot restore commitlogs for keyspaces or tables
that would have to be recreated in Cassandra 2.1 and later, and DataStax Enterprise 4.7 and later.
- Point-in-time restore fails if any tables were recreated during the time
period of the actual point-in-time restore.
Important: The Backup Service requires control over the data and structure of its
destination locations. The AWS S3 bucket and the Local file system 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 Configure link for the Backup Service.
-
Click Restore Backup.
The Restore from Backup, Step 1 of 2: Select Backup dialog
appears.
-
Click the Point In Time tab.
-
Complete your selections in the step 1 dialog:
-
Point in Time: Set the date and time to which
you want to restore your data.
-
Commitlogs Location: Select the location of the
commitlogs, either On Server or another location on S3. The location of
commitlogs is configured when enabling commitlog backups.
-
Backup Location: Select the location of the
snapshot, either On Server or another location on S3. The backup
location was specified when creating the backup.
-
Click Next.
The Restore from Backup, Step 2 of 2: Configure and Restore
dialog appears.
-
Complete your selections in the step 2 dialog:
-
Keyspaces: 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 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.
-
Location: Select the target cluster for the
restored data.
- The Location list is only available when 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 will be cloned to the selected cluster.
Note:
Restoring encrypted tables to a different cluster will not work
unless the encryption keys are identical, which is typically not
the case.
-
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.
-
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.
-
Change the staging directory if necessary by setting
the
backup_staging_directory
configuration option in
address.yaml.
-
Click the Edit Restart
Settings link to adjust settings for the rolling restart.
-
Click Restore Backup.
-
Click Start Restore to confirm when prompted.
Results
OpsCenter retrieves the backup data and sends the data to the nodes in the cluster. A
snapshot restore is completed first, following the same process as a normal snapshot
restore. After the snapshot restore successfully completes, OpsCenter instructs all
agents in parallel to download the necessary commitlogs, followed by a rolling
commitlog replay across the cluster. Each node is configured for replay and
restarted after the previous one finishes successfully.
If an error occurs during a point-in-time restore for a subset of tables, you might
need to manually the revert changes made to some cluster nodes. To clean up a node,
edit and remove the last line that
specifies JVM_OPTS
. For example:
export JVM_OPTS="$JVM_OPTS -Dcassandra.replayList=Keyspace1.Standard1"