Restoring from a Snapshot

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

Generally, before restoring a snapshot, you should truncate the table. If the backup occurs before the delete and you restore the backup after the delete without first truncating, you do not get back the original data (row). Until compaction, the tombstone is in a different SSTable than the original row, so restoring the SSTable containing the original row does not remove the tombstone and the data still appears to be deleted.

Cassandra can only restore data from a snapshot when the table schema exists. If you have not backed up the schema, you can do the either of the following:

  • Method 1
    1. Restore the snapshot, as described below.
    2. Recreate the schema.
  • Method 2
    1. Recreate the schema.
    2. Restore the snapshot, as described below.
    3. Run nodetool refresh.

Procedure

You can restore a snapshot in several ways:

  • Use the sstableloader tool.
  • Copy the snapshot SSTable directory (see Taking a snapshot) to the data/keyspace/table_name directory and then call the JMX method loadNewSSTables() in the column family MBean for each column family through JConsole. You can use nodetool refresh instead of the loadNewSSTables() call.
    The location of the data directory depends on the type of installation:
    • Packaged installs: /var/lib/cassandra/data
    • Tarball installs: install_location/data/data

    The tokens for the cluster you are restoring must match exactly the tokens of the backed-up cluster at the time of the snapshot. Furthermore, the snapshot must be copied to the correct node with matching tokens matching. If the tokens do not match, or the number of nodes do not match, use the sstableloader procedure.

  • Use the Node Restart Method.