Apache Cassandra 1.1 Documentation

Backing Up and Restoring Data

This document corresponds to an earlier product version. Make sure you are using the version that corresponds to your version.

Latest Cassandra documentation | Earlier Cassandra documentation

Cassandra backs up data by taking a snapshot of all on-disk data files (SSTable files) stored in the data directory. You can take a snapshot on all keyspaces, a single keyspace, or a single column family while the system is online. However, to restore a snapshot, you must take the nodes offline.

Using a parallel ssh tool (such as pssh), you can snapshot an entire cluster. This provides an eventually consistent backup. Although no one node is guaranteed to be consistent with its replica nodes at the time a snapshot is taken, a restored snapshot resumes consistency using Cassandra's built-in consistency mechanisms.

After a system-wide snapshot is performed, you can enable incremental backups on each node to backup data that has changed since the last snapshot: each time an SSTable is flushed, a hard link is copied into a /backups subdirectory of the data directory (provided JNA is enabled).


If JNA is enabled, snapshots are performed by hard links. If not enabled, I/O activity increases as the files are copied from one location to another, which significantly reduces efficiency.

Taking a Snapshot

Snapshots are taken per node using the nodetool snapshot command. To take a global snapshot, run the nodetool snapshot command using a parallel ssh utility, such as pssh.

A snapshot first flushes all in-memory writes to disk, then makes a hard link of the SSTable files for each keyspace. By default the snapshot files are stored in the /var/lib/cassandra/data/<keyspace_name>/<column_family_name>/snapshots directory.

You must have enough free disk space on the node to accommodate making snapshots of your data files. A single snapshot requires little disk space. However, snapshots can cause your disk usage to grow more quickly over time because a snapshot prevents old obsolete data files from being deleted. After the snapshot is complete, you can move the backup files to another location if needed, or you can leave them in place.

To create a snapshot of a node

Run the nodetool snapshot command, specifying the hostname, JMX port, and keyspace. For example:

$ nodetool -h localhost -p 7199 snapshot demdb

The snapshot is created in <data_directory_location>/<keyspace_name>/<column_family_name>/snapshots/<snapshot_name>. Each snapshot folder contains numerous .db files that contain the data at the time of the snapshot.

Deleting Snapshot Files

When taking a snapshot, previous snapshot files are not automatically deleted. You should remove old snapshots that are no longer needed.

The nodetool clearsnapshot command removes all existing snapshot files from the snapshot directory of each keyspace. You should make it part of your back-up process to clear old snapshots before taking a new one.

  • To delete all snapshots for a node, run the nodetool clearsnapshot command. For example:

    $ nodetool -h localhost -p 7199 clearsnapshot
  • To delete snapshots on all nodes at once, run the nodetool clearsnapshot command using a parallel ssh utility.

Enabling Incremental Backups

When incremental backups are enabled (disabled by default), Cassandra hard-links each flushed SSTable to a backups directory under the keyspace data directory. This allows storing backups offsite without transferring entire snapshots. Also, incremental backups combine with snapshots to provide a dependable, up-to-date backup mechanism.

To enable incremental backups, edit the cassandra.yaml configuration file on each node in the cluster and change the value of incremental_backups to true.

As with snapshots, Cassandra does not automatically clear incremental backup files. DataStax recommends setting up a process to clear incremental backup hard-links each time a new snapshot is created.

Restoring from a Snapshot

Restoring a keyspace from a snapshot requires all snapshot files for the column family, and if using incremental backups, any incremental backup files created after the snapshot was taken. You can restore a snapshot in several ways:

  • Use the sstableloader tool.
  • Copy the snapshot SSTable directory (see Taking a Snapshot) to the data directory (/var/lib/cassandra/data/<keyspace>/<column_family>/), and then call the JMX method loadNewSSTables() in the column family MBean for each column family through JConsole. Instead of using the loadNewSSTables() call, you can also use nodetool refresh.
  • Use the Node Restart Method described below.

Node Restart Method

If restoring a single node, you must first shutdown the node. If restoring an entire cluster, you must shutdown all nodes, restore the snapshot data, and then start all nodes again.


Restoring from snapshots and incremental backups temporarily causes intensive CPU and I/O activity on the node being restored.

To restore a node from a snapshot and incremental backups:

  1. Shut down the node.

  2. Clear all files in /var/lib/cassandra/commitlog.

  3. Delete all *.db files in <data_directory_location>/<keyspace_name>/<column_family_name> directory, but DO NOT delete the /snapshots and /backups subdirectories.

  4. Locate the most recent snapshot folder in <data_directory_location>/<keyspace_name>/<column_family_name>/snapshots/<snapshot_name>, and copy its contents into the <data_directory_location>/<keyspace_name>/<column_family_name> directory.

  5. If using incremental backups, copy all contents of <data_directory_location>/<keyspace_name>/<column_family_name>/backups into <data_directory_location>/<keyspace_name>/<column_family_name>.

  6. Restart the node.

    Restarting causes a temporary burst of I/O activity and consumes a large amount of CPU resources.