Apache Cassandra Backup and Restore Guide
Apache Cassandra backup is essential for recovering data after accidental deletion, database corruption, infrastructure failure, or cluster migration. Although Cassandra distributes data across multiple nodes, replication alone cannot replace a reliable backup and restore strategy.
Cassandra provides native snapshot and incremental backup mechanisms based on SSTable files. For larger distributed environments, administrators can also use tools such as Medusa to automate cluster-wide backups, manage backup storage, and coordinate recovery operations.
How Apache Cassandra Backup Works
Apache Cassandra is a distributed NoSQL database that stores data across multiple nodes. Its architecture provides high availability through replication, but a complete backup strategy must account for data placement, table schemas, cluster topology, and recovery requirements.
Cassandra stores persistent table data in immutable files called SSTables (Sorted String Tables). Native backup operations preserve these files without requiring a conventional SQL database dump.
Unlike many relational databases, Cassandra does not rely on a single database file or one centralized backup location. A cluster-wide backup generally requires coordinated operations across the relevant nodes.
Why Replication Is Not a Backup
Replication maintains copies of data across Cassandra nodes, helping the cluster remain available when individual nodes fail. However, unwanted changes can also propagate between replicas.
- Accidental data deletion may affect multiple replicas.
- Incorrect application updates can overwrite valid records.
- Replication does not provide historical recovery points.
- A cluster-wide incident may affect all available replicas.
Separate backups provide recovery options that replication alone cannot offer.
Cassandra Backup Methods Compared
Apache Cassandra provides native snapshots and incremental backups. These mechanisms work differently and are commonly combined in a broader database backup strategy.
| Method | How It Works | Typical Use |
|---|---|---|
| Snapshots | Creates hard links to existing SSTable files at a particular point in time. | Periodic recovery points, table recovery, and migration. |
| Incremental Backups | Creates hard links to SSTables when they are flushed or streamed locally. | Preserving SSTables created between snapshots. |
| Commit Log Archiving | Preserves commit log segments that can be used in specialized recovery workflows. | More granular recovery procedures when correctly configured. |
| Cluster Backup Tools | Coordinates snapshots, metadata, external storage, and restore operations. | Automated backup of distributed Cassandra environments. |
Important: A native Cassandra incremental backup is not the same as a conventional incremental file backup. Cassandra preserves SSTables created after data flushes rather than comparing ordinary files against a previous backup set.
Cassandra Snapshot Backup Using nodetool
The nodetool snapshot command creates a point-in-time snapshot of selected tables or keyspaces. Cassandra normally flushes in-memory data before creating the snapshot, unless the skip-flush option is explicitly selected.
Snapshots use hard links to existing SSTable files, so creating one does not immediately duplicate the entire database on disk. However, retained snapshots can prevent obsolete SSTable data from being reclaimed after compaction.
Because snapshots are stored within Cassandra data directories, they should be transferred to separate storage for long-term retention and disaster recovery.
Example: Create a Snapshot
Create a snapshot of a keyspace named sales:
nodetool snapshot -t sales_daily salesCreate a snapshot of one table:
nodetool snapshot -t orders_daily -cf orders salesList existing snapshots:
nodetool listsnapshotsThese commands operate on the node contacted by nodetool. For a cluster-wide backup, the required nodes must be included in the backup procedure.
See the official nodetool snapshot reference for command options and version-specific behavior.
How to Enable Cassandra Incremental Backup
Incremental backups preserve SSTable files created after memtables are flushed to disk. They are disabled by default in standard Cassandra configurations and must be enabled explicitly.
Enable Incremental Backups
In the Cassandra configuration file cassandra.yaml, set:
incremental_backups: trueAlternatively, enable incremental backups on a running node:
nodetool enablebackupCheck the current status:
nodetool statusbackupDisable incremental backups when necessary:
nodetool disablebackupHow Incremental Backups Are Stored
Once enabled, Cassandra creates hard links to SSTable files in a backups subdirectory associated with each table.
These files can be combined with a suitable snapshot to recover changes represented by subsequent SSTables. Unlike a snapshot, an incremental backup does not automatically provide a complete independent recovery point.
Incremental backup files also require retention management. Cassandra does not automatically remove all files from incremental backup directories after they have been transferred to external storage.
For more information on general backup chains, see Incremental Backup Methods and Recovery.
How to Back Up a Cassandra Cluster
A Cassandra cluster contains distributed data, so backing up a single node does not necessarily preserve every partition. Cluster recovery planning must take replication, token ownership, schema information, and the intended restoration method into account.
Step 1. Identify the Cluster Scope
Document Cassandra versions, data centers, keyspaces, replication settings, node topology, and critical tables. Determine whether the goal is table recovery, full-cluster recovery, or migration to another environment.
Step 2. Coordinate Node Snapshots
Run snapshot operations on the relevant nodes. Use a consistent backup identifier and record completion times and results.
Individual node snapshots are not automatically a globally synchronized transaction-consistent snapshot of the entire cluster.
Step 3. Preserve Schema and Configuration
Keep the CQL schema definitions and important configuration details alongside the backup. Recovery may require keyspace definitions, table structures, replication settings, and other metadata.
Step 4. Transfer the Backup Offsite
Transfer the required snapshot files and metadata to storage independent of the Cassandra nodes. Preserve the association between backup files, source nodes, keyspaces, and tables.
Step 5. Establish Backup Retention
Define how long full snapshots and incremental SSTables must be retained. Ensure that files needed for a particular recovery point remain available until that backup is no longer required.
Step 6. Verify Recovery
Perform a trial restoration in an isolated environment. Verify the schema, sample records, application queries, and the completeness of restored data.
Note: Coordinated cluster backup tools can simplify these procedures. For production environments, a tested recovery workflow is more important than merely confirming that snapshot commands completed successfully.
Cassandra Backup to S3 and Cloud Storage
Offsite backup storage is particularly important for Cassandra clusters deployed across cloud infrastructure, virtual machines, or dedicated servers. Keeping copies outside the active cluster reduces dependence on the availability of its local disks.
Common destinations include Amazon S3, S3-compatible object storage, Google Cloud Storage, and dedicated backup servers.
A typical workflow creates Cassandra snapshots, collects the required files and metadata, and transfers them to remote storage. The process should account for network bandwidth, storage costs, backup retention, and the time required to retrieve large datasets.
Common Cloud Backup Challenges
- Limited disk space: Creating temporary archives may require substantial additional storage.
- Large SSTable files: Transfers can consume significant bandwidth and I/O resources.
- Duplicate data: Repeated snapshots may contain many unchanged SSTables.
- Recovery time: Downloading large archives can delay database restoration.
- Retention: Storage lifecycle rules must not remove files required by retained backup sets.
Because Cassandra SSTables may already be compressed, placing every snapshot into a separate compressed archive does not necessarily produce significant storage savings. Incremental transfers and file reuse can be more efficient for large datasets.
Apache Cassandra Backup with Medusa
Medusa is an open-source backup and restore tool developed for Apache Cassandra. It builds on Cassandra snapshots and adds mechanisms for backup coordination, remote storage, and restoration.
Medusa is especially useful when administrators want to manage backups across multiple Cassandra nodes without manually collecting individual snapshot directories.
Its functionality includes:
- Coordinated Cassandra cluster backups.
- Remote backup storage using compatible storage backends.
- Reuse of unchanged SSTable data between backups.
- Restoration to an existing or replacement cluster.
- Backup metadata management and verification options.
When to Consider Medusa
Medusa can be useful for production Cassandra environments with multiple nodes, substantial datasets, or requirements for repeatable disaster recovery procedures.
Before deployment, verify compatibility with your Cassandra version, cluster topology, storage environment, and restoration requirements.
Official project repository:
How to Restore an Apache Cassandra Backup
Cassandra recovery depends on the type of backup and the target environment. Restoring one table to an existing cluster is different from rebuilding an entire cluster or migrating data to a cluster with a different topology.
Restore from SSTable Snapshots
Snapshot recovery uses the SSTable files captured during the backup. Depending on the scenario, administrators can use native Cassandra tools such as sstableloader or nodetool import.
A typical table recovery procedure includes:
- Identify the required snapshot and associated schema.
- Prepare the target keyspace and table definitions.
- Make the correct SSTable files available for recovery.
- Load or import the SSTables using the appropriate procedure.
- Verify restored records and application access.
Restore to a Different Cluster
Cluster migration introduces additional considerations, including node counts, partition ownership, replication configuration, and Cassandra version compatibility.
The sstableloader utility can stream SSTable data to a target cluster without requiring the same token allocation as the source cluster.
However, the destination schema and cluster configuration must be prepared correctly. A direct file copy between clusters with different layouts is not a universal recovery method.
Cassandra Backup Best Practices
Maintain External Copies
Store backup data separately from Cassandra production nodes. Use independent storage and appropriate access controls to reduce the impact of infrastructure failures.
Control Backup Overhead
Monitor disk utilization, snapshot accumulation, network throughput, and I/O load. Schedule large transfers to avoid unnecessary competition with production workloads.
Test Restore Procedures
Restore selected tables and complete datasets in a test environment. Validate application queries, data completeness, and the actual time needed for recovery.
A reliable database backup and recovery strategy should define recovery point objectives (RPO), recovery time objectives (RTO), archive retention, monitoring, and responsibilities for executing recovery procedures.
For additional context, learn about hot database backups and how online backup methods differ from copying database files while the system is stopped.
FAQ About Cassandra Backup and Restore
Does Cassandra automatically back up data?
Cassandra can automatically create snapshots before certain operations, such as truncating or dropping tables, depending on its configuration. However, routine full backup scheduling, remote storage, retention, and recovery verification require additional planning or automation. Incremental backups are disabled by default in standard configurations.
Are Cassandra snapshots incremental backups?
No. Cassandra snapshots preserve a point-in-time set of SSTable files, while incremental backups preserve SSTables created when data is flushed or streamed locally. These mechanisms can be combined, but an incremental backup does not replace the need for a complete baseline and associated recovery metadata.
Do I need to back up every Cassandra node?
For a comprehensive cluster backup, administrators generally coordinate snapshots across the relevant nodes. A single node may contain only part of the cluster's data. The exact backup scope depends on replication, token distribution, and the intended recovery procedure. Cluster-wide tools such as Medusa help automate the process.
Can Cassandra backups be restored to a different cluster?
Yes. Cassandra SSTable backups can be used for recovery or migration to another compatible cluster. Tools such as sstableloader can stream data to the destination cluster. However, administrators must consider schema compatibility, Cassandra versions, replication settings, and differences in cluster topology.
Can Cassandra backups provide point-in-time recovery?
Snapshots provide recovery points corresponding to the captured SSTable state. More granular recovery may require correctly configured commit log archiving and specialized restoration procedures. Cassandra snapshots and incremental SSTable backups alone do not provide arbitrary point-in-time recovery equivalent to database transaction log replay.
What is the best way to verify a Cassandra backup?
The most reliable verification method is a test restoration. Restore the backup to an isolated Cassandra environment, verify the table schemas, compare expected records, and run representative application queries. File-level integrity checks can help detect transfer errors, but they cannot replace database recovery testing.
Related Database Backup Guides
Explore additional information about database backup planning, storage methods, and recovery procedures: