Restoring from a snapshot
Restoring a keyspace from a snapshot requires all snapshot files for the table, and if using incremental backups, any incremental backup files created after the snapshot was taken. Streamed SSTables (from repair, decommission, and so on) are also hard-linked and included.
|
Restoring from snapshots and incremental backups temporarily causes intensive CPU and I/O activity on the node being restored. |
Restoring from local nodes
This method copies the SSTables from the snapshots directory into the correct data directories.
-
Make sure the table schema exists and is the same as when the snapshot was created.
The
nodetool snapshotcommand creates a table schema in the output directory. If the table does not exist, re-create it using theschema.cqlfile. -
If necessary,
TRUNCATEthe target table.Don’t truncate if you are restoring the
dse_system.encrypted_keystable after upgrading DSE.Don’t truncate if you want to restore all data or continue replicating new writes. For example, if a node lost a disk, you might restart before restoring so that the node continues to receive new writes before starting the restore procedure.
Do truncate if the snapshot might contain data that you don’t want to restore. For example, if there was an accidental deletion of data, the tombstone from that delete has a later write timestamp than the data in the snapshot. If you restore without truncating (removing the tombstone), the database continues to shadow the restored data. This behavior also occurs for other types of overwrites and causes the same problem.
-
Locate the most recent snapshot folder.
The path follows the pattern
/var/lib/cassandra/data/<keyspace_name>/<table_name>-<UUID>/snapshots/<snapshot_name>. -
Copy the most recent snapshot SSTable directory to the
/var/lib/cassandra/data/<keyspace_name>/<table_name>-<UUID>directory.For all installations, the default location of the data directory is
/var/lib/cassandra/data. -
Run
nodetool refresh.
Restoring from centralized backups
This method uses sstableloader to restore snapshots.
-
Verify that the SSTable version is compatible with the current version of DataStax Enterprise (DSE):
-
Locate the version in the file names.
Use the version number in the SSTable file name to determine compatibility and upgrade requirements. The first two letters of the file name is the version, where the first letter indicates a major version and the second letter indicates a minor version. For example, the following SSTable version is mc:
data/cycling/cyclist_expenses-2d955621194c11e7a38d9504a063a84e/mc-6-big-Data.db -
Using the correct DSE version of
sstableupgrade, create a compatible version:For SSTable compatibility and upgrading, see Supported platforms and compatibility for DSE.
-
-
Make sure the table schema exists and is the same as when the snapshot was created.
The nodetool snapshot command creates a table schema in the output directory. If the table does not exist, re-create it using the
schema.cqlfile. -
If necessary,
TRUNCATEthe target table.Don’t truncate if you are restoring the
dse_system.encrypted_keystable after upgrading DSE.Don’t truncate if you want to restore all data or continue replicating new writes. For example, if a node lost a disk, you might restart before restoring so that the node continues to receive new writes before starting the restore procedure.
Do truncate if the snapshot might contain data that you don’t want to restore. For example, if there was an accidental deletion of data, the tombstone from that delete has a later write timestamp than the data in the snapshot. If you restore without truncating (removing the tombstone), the database continues to shadow the restored data. This behavior also occurs for other types of overwrites and causes the same problem.
-
Restore the most recent snapshot using the
sstableloadertool on the backed-up SSTables.The
sstableloaderstreams the SSTables to the correct nodes. You don’t need to remove the commit logs, drain nodes, or restart nodes.
