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