Cassandra Backup and Restore

Cassandra backups are per node. Because SSTables are immutable, a snapshot is a set of hard links — instantaneous and initially free of extra disk usage.

Snapshots

nodetool snapshot -t nightly-20260731 shop
nodetool listsnapshots
nodetool clearsnapshot -t nightly-20260731 shop

Snapshots are created under <data_dir>/<keyspace>/<table>/snapshots/<tag>/. Copy them to durable storage outside the node, then clear them.

Incremental backups

incremental_backups: true

Every flushed SSTable is hard-linked into a backups/ directory. Combined with periodic full snapshots this reduces the volume copied each time — and Cassandra never cleans that directory, so the copy-and-remove job is your responsibility.

Schema

Restoring a single node

If a node is replaced and the cluster is otherwise healthy, the usual answer is not a backup at all: start a replacement node with -Dcassandra.replace_address_first_boot=<old-ip> and let it stream its ranges from the other replicas. Follow with a full repair.

Use a backup when the data itself must be recovered — for example after a logical error that replication has already copied everywhere.

Restoring a keyspace from snapshots

# On every node, with Cassandra stopped:
# 1. Recreate the schema on the cluster from the exported CQL.
# 2. Place the snapshot SSTables into the table directories.
# 3. Start the node and refresh.
nodetool refresh shop events_by_user

Alternatively, sstableloader streams SSTables into a running cluster and handles a changed topology, which makes it the safer option when node count or tokens have changed:

sstableloader -d 10.20.1.10,10.20.1.11 /backups/shop/events_by_user

Verification

After restoring into a separate cluster:

SELECT count(*) FROM shop.events_by_user WHERE user_id = ? AND bucket = ?;

Full-table counts are expensive in Cassandra; verify with targeted partition reads for known keys and with nodetool tablestats row estimates rather than cluster-wide counts. Then run a full repair and confirm it completes.