Cassandra Backup and Restore

Backing up a Cassandra cluster protects against accidental data deletion, application bugs that corrupt data, and catastrophic hardware failures. Cassandra provides two primary backup mechanisms: snapshots (point-in-time full backups) and incremental backups (changes since the last snapshot). Both work at the SSTable level with zero impact on cluster availability.

Snapshot Backups

A snapshot is a point-in-time copy of all SSTables. Cassandra creates snapshots by hard-linking the current SSTable files into a snapshot directory. Hard links are instant — no data is copied. The snapshot directory then holds an immutable copy of the data at that moment.

Before snapshot:
  /var/lib/cassandra/data/ecommerce/orders-xxx/
    mb-1-big-Data.db
    mb-2-big-Data.db

After snapshot (tag: backup_2024_06_15):
  /var/lib/cassandra/data/ecommerce/orders-xxx/
    mb-1-big-Data.db
    mb-2-big-Data.db
    snapshots/
      backup_2024_06_15/
        mb-1-big-Data.db  (hard link to original)
        mb-2-big-Data.db  (hard link to original)

Taking a Snapshot

# Snapshot all keyspaces with a tag:
nodetool snapshot -t backup_2024_06_15

# Snapshot a specific keyspace:
nodetool snapshot -t backup_ecommerce ecommerce

# Snapshot a specific table:
nodetool snapshot -t backup_orders ecommerce orders_by_customer

List Existing Snapshots

nodetool listsnapshots

Snapshot name   Keyspace    Table                  Created at       True size
backup_2024_06  ecommerce   orders_by_customer     2024-06-15       1.2 GB
backup_2024_06  ecommerce   products               2024-06-15       400 MB

Clear Snapshots

Snapshots keep hard links alive, preventing Cassandra from reclaiming disk space from old SSTables. Clear snapshots regularly to free space.

# Remove a specific snapshot:
nodetool clearsnapshot -t backup_2024_06_15

# Remove all snapshots:
nodetool clearsnapshot

Incremental Backups

Incremental backups capture only the SSTables written since the last snapshot. When a new SSTable is flushed from the MemTable, Cassandra hard-links it into a backups/ subdirectory if incremental backups are enabled.

# cassandra.yaml — enable incremental backups:
incremental_backups: true

Incremental backup directory:
  /var/lib/cassandra/data/ecommerce/orders-xxx/backups/
    mb-3-big-Data.db    (flushed after last snapshot)
    mb-4-big-Data.db    (flushed after last snapshot)

To restore from incrementals, start with the last snapshot and then apply all subsequent incremental files.

Copying Snapshots to Remote Storage

Snapshots on the same disk are not true offsite backups. Copy them to object storage (S3, GCS, Azure Blob) or a network backup system.

# Copy to Amazon S3 using AWS CLI:
aws s3 sync \
  /var/lib/cassandra/data/ \
  s3://my-cassandra-backups/node-10-0-0-1/2024-06-15/ \
  --exclude "*" \
  --include "*/snapshots/backup_2024_06_15/*"

# Copy to a remote server using rsync:
rsync -avz \
  /var/lib/cassandra/data/ecommerce/ \
  backup-server:/cassandra-backups/ecommerce/2024-06-15/

Backup Schema Separately

SSTables contain data but not schema. Always backup the keyspace and table definitions separately so you can recreate the schema before restoring data.

# Export schema from cqlsh:
cqlsh -e "DESCRIBE FULL SCHEMA" > /backup/schema_2024_06_15.cql

# Or describe a single keyspace:
cqlsh -e "DESCRIBE KEYSPACE ecommerce" > /backup/ecommerce_schema.cql

Restoring from a Snapshot

Full Restore Process

Step 1: Stop Cassandra:
  sudo systemctl stop cassandra

Step 2: Clear existing data:
  sudo rm -rf /var/lib/cassandra/data/ecommerce/orders-xxx/*
  sudo rm -rf /var/lib/cassandra/commitlog/*

Step 3: Restore schema (if needed):
  cqlsh -f /backup/schema_2024_06_15.cql

Step 4: Copy snapshot files back:
  cp /backup/snapshots/backup_2024_06_15/* \
     /var/lib/cassandra/data/ecommerce/orders-xxx/

Step 5: Fix ownership:
  sudo chown -R cassandra:cassandra /var/lib/cassandra/data/

Step 6: Start Cassandra:
  sudo systemctl start cassandra

Step 7: Run nodetool repair to sync with other replicas:
  nodetool repair ecommerce

Restoring a Specific Table Without Downtime

You can restore a single table to a specific snapshot without stopping the cluster using the sstableloader tool. This streams the SSTable data into the live cluster.

# Copy snapshot to a temp directory matching the keyspace/table layout:
mkdir -p /tmp/restore/ecommerce/orders_by_customer/
cp /backup/snapshots/backup_2024_06_15/* \
   /tmp/restore/ecommerce/orders_by_customer/

# Stream data into the cluster:
sstableloader -d 10.0.0.1 /tmp/restore/ecommerce/orders_by_customer/

Backup Strategy for Production

Frequency          Action
──────────────────────────────────────────────────────────────
Daily              Full snapshot → offsite storage
Continuous         Incremental backups enabled
Weekly             Verify restore works from backup
Monthly            Test full cluster restore in staging
Quarterly          Review and update backup runbook

Summary

Cassandra snapshots create instant, non-blocking, point-in-time copies of SSTables using hard links. Incremental backups capture new SSTables since the last snapshot. Always copy backups to offsite or object storage — on-disk snapshots do not protect against disk failure. Back up the schema separately with DESCRIBE FULL SCHEMA. Restore data using sstableloader for live restores without cluster downtime, or use the file-copy method for a full node restore. Test your restore process regularly to ensure backups are actually usable when needed.

Previous lesson

Back to course

Next lesson