Performing a point-in-time restore

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:

Location Package Installer (GUI or text mode) Tarball
Service No-service
/etc/dse/dse-env.sh X X    
install_location/dse/dse-env.sh     X X

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.
  • Known limitations:
    • Point-in-time restore cannot restore commitlogs for keyspaces or tables that would have to be recreated in Cassandra 2.1+ and DSE 4.7+.
    • Point-in-time restore fails if any tables were recreated during the time period of the actual point-in-time restore.

Procedure

  1. Click the name of the cluster you want to manage from the left pane.
  2. Click Services.
  3. Click View Details for the Backup Service.
  4. Click Restore Backup.
  5. Click the Point In Time tab.
  6. Set the date and time to which you want to restore your data.
  7. Select the location of the commitlogs under Commitlogs Location and the location of the snapshot under Backup Location, then click Next.
  8. 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.

  9. Under 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.
    • Restoring to a different cluster is only supported when the backup resides in S3; restoring from a local backup is not currently supported.
    • 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.

  10. To remove the existing keyspace data before the data is restored, select Truncate/delete existing data before restore. This will completely remove any updated data in the cluster for the keyspaces you are restoring.
  11. 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.


  12. Click Restore Backup.
  13. Click Start Restore.

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 dse-env.sh and remove the last line that specifies JVM_OPTS. For example:

export JVM_OPTS="$JVM_OPTS -Dcassandra.replayList=Keyspace1.Standard1"