{"id":8149,"date":"2019-07-17T16:34:27","date_gmt":"2019-07-17T16:34:27","guid":{"rendered":"https:\/\/rax-stg-wp-aws.com\/blogs\/apache-cassandra-backup-and-recovery\/"},"modified":"2026-11-03T19:29:27","modified_gmt":"2026-11-03T19:29:27","slug":"apache-cassandra-backup-and-recovery","status":"publish","type":"blogs","link":"https:\/\/www.rackspace.com\/en-gb\/blogs\/apache-cassandra-backup-and-recovery\/","title":{"rendered":"Apache Cassandra backup and recovery"},"content":{"rendered":"

Introduction<\/strong><\/p>\n

Database backup and recovery is one of the crucial day-to-day activities that a database administrator (DBA) performs. A database backup is a copy of your data that can be used to recover the data in the event of data loss.This blog shows you how to backup Apache\u00a9 Cassandra\u00a9 databases and restore them after a failure.<\/p>\n

Though Apache Cassandra is decentralized, it can endure single and multi-node failures without losing any business data, as long as one of the nodes in the cluster contains data. However, as a best practice, you should configure a backup for the databases.<\/p>\n

In case of any failure, such as an entire cluster rebuild, data corruption, accidental data deletion, and so on, you can recover the data from the backup and continue business operations with minimal or no impact.<\/p>\n

More and more companies are using NoSQL databases, such as Cassandra, to successfully manage the large volume of business data, more popularly known as Big Data. Cassandra, widely used by many major organizations, ensures scalability, fault-tolerance, and consistency to support Big Data.<\/p>\n

Cassandra database backup and restore<\/strong><\/p>\n

You can use the following utilities to take a snapshot of a Cassandra database
\nand restore it when required:<\/p>\n

– nodetool<\/em> (To take the snapshot)
\n– sstableloader<\/em> (To restore the snapshot backup)<\/p>\n

The following image illustrates moving from a cloud cluster to a Cassandra
\ncluster by using `sstableloader<\/em>`:<\/p>\n

\"cassandra<\/p>\n

Image source<\/em><\/a><\/p>\n

Backup<\/strong><\/p>\n

The following example uses `nodetool` to take a snapshot of Cassandra database
\nkeyspace(users)<\/strong> with a table called employee<\/strong>.<\/p>\n

Source Cassandra cluster details:<\/strong><\/p>\n

    $ nodetool -u cassandra -pw ******** -h localhost status<\/em><\/p>\n

    Datacenter: us-central1
\n    =======================
\n    Status=Up\/Down
\n    |\/ State=Normal\/Leaving\/Joining\/Moving
\n    —  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
\n    UN  10.128.0.2  121.52 KiB  256         63.3%             5957997f-7471-4c21-bead-37a6604812e2  f
\n    UN  10.128.0.3  92.22 KiB  256          68.0%             87c2a663-a965-4675-b5ed-c4a46d77c796  f
\n    UN  10.128.0.4  225.3 KiB  256          68.8%             8e12557f-be00-4387-bff3-ef51f431b9a0  f<\/p>\n

Use the following command to backup keyspace<\/strong>:<\/p>\n

    $ nodetool -h localhost -u cassandra -pw ****** snapshot users -t “users-201904201800”<\/em><\/p>\n

    Requested creating snapshot(s) for [users] with snapshot name [users-201904201800] and options {skipFlush=false}
\n    Snapshot directory: users-201904201800<\/em><\/p>\n

This creates a backup snapshot as shown in the following example:<\/p>\n

    \/bitnami\/cassandra\/data\/data\/users\/employee-c1319df0636211e9a0e3570eb7f8fd5f\/snapshots\/users-201904201800
\n    $ ls -ltr<\/em>
\n    total 44
\n    -rw-r–r– 2 cassandra cassandra   16 Apr 20 12:05 md-1-big-Filter.db
\n    -rw-r–r– 2 cassandra cassandra   56 Apr 20 12:05 md-1-big-Summary.db
\n    -rw-r–r– 2 cassandra cassandra   32 Apr 20 12:05 md-1-big-Index.db
\n    -rw-r–r– 2 cassandra cassandra  134 Apr 20 12:05 md-1-big-Data.db
\n    -rw-r–r– 2 cassandra cassandra   10 Apr 20 12:05 md-1-big-Digest.crc32
\n    -rw-r–r– 2 cassandra cassandra   43 Apr 20 12:05 md-1-big-CompressionInfo.db
\n    -rw-r–r– 2 cassandra cassandra 4683 Apr 20 12:05 md-1-big-Statistics.db
\n    -rw-r–r– 2 cassandra cassandra   92 Apr 20 12:05 md-1-big-TOC.txt
\n    -rw-r–r– 1 cassandra cassandra   31 Apr 20 12:05 manifest.json
\n    -rw-r–r– 1 cassandra cassandra  865 Apr 20 12:05 schema.cql<\/p>\n

    $ date
\n    Sat Apr 20 12:08:21 UTC 2019<\/p>\n

Now, archive the \/snapshot<\/strong> backup directory files and move the tar file to the \/bitnami\/Cassandra\/data\/data\/backup<\/strong> directory.<\/p>\n

    $ tar -cvf users-201904201800.tar
\n    manifest.json
\n    md-1-big-CompressionInfo.db
\n    md-1-big-Data.db
\n    md-1-big-Digest.crc32
\n    md-1-big-Filter.db
\n    md-1-big-Index.db
\n    md-1-big-Statistics.db
\n    md-1-big-Summary.db
\n    md-1-big-TOC.txt
\n    schema.cql<\/em><\/p>\n

    $ ls -ltr<\/em>
\n    total 64
\n    -rw-r–r– 2 cassandra cassandra    16 Apr 20 12:05 md-1-big-Filter.db
\n    -rw-r–r– 2 cassandra cassandra    56 Apr 20 12:05 md-1-big-Summary.db
\n    -rw-r–r– 2 cassandra cassandra    32 Apr 20 12:05 md-1-big-Index.db
\n    -rw-r–r– 2 cassandra cassandra   134 Apr 20 12:05 md-1-big-Data.db
\n    -rw-r–r– 2 cassandra cassandra    10 Apr 20 12:05 md-1-big-Digest.crc32
\n    -rw-r–r– 2 cassandra cassandra    43 Apr 20 12:05 md-1-big-CompressionInfo.db
\n    -rw-r–r– 2 cassandra cassandra  4683 Apr 20 12:05 md-1-big-Statistics.db
\n    -rw-r–r– 2 cassandra cassandra    92 Apr 20 12:05 md-1-big-TOC.txt
\n    -rw-r–r– 1 cassandra cassandra    31 Apr 20 12:05 manifest.json
\n    -rw-r–r– 1 cassandra cassandra   865 Apr 20 12:05 schema.cql
\n    -rw-r–r– 1 cassandra cassandra 20480 Apr 20 12:22 users-201904201800.tar<\/p>\n

    cp *.tar \/bitnami\/cassandra\/data\/data\/backup.
\n    \/bitnami\/cassandra\/data\/data\/backup<\/em><\/p>\n

    $ ls -ltr
\n    -rw-r–r–  1 cassandra cassandra 20480 Apr 20 12:23 users-201904201800.tar<\/em><\/p>\n

After copying the backup tar file to a non-default location, drop the employee<\/strong>
\ntable.<\/p>\n

NOTE<\/strong>: Cassandra distributes data based on the defined partition keys and replication actors across the cluster, so you must run this backup command from all your nodes. This example uses the Linux\u00a9 shell script in crontab, which backs up all nodes at once.<\/p>\n

    $ cqlsh -u cassandra -p *******<\/em><\/p>\n

    Connected to Test_Cassandra at 127.0.0.1:9042.
\n    [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
\n    Use HELP for help.<\/em><\/p>\n

    cassandra@cqlsh> use users;
\n    cassandra@cqlsh:users> select * from employee;<\/em><\/p>\n

     emp_id | employee_address | employee_name
\n    ——–+——————+—————
\n       8796 |        Singapore |           Joy
\n       5647 |           London |          Mike
\n       3452 |           Canada |         Nancy
\n       6453 |            China |          John<\/p>\n

    (4 rows)<\/p>\n

    cassandra@cqlsh:users> drop table employee;
\n    cassandra@cqlsh:users> select * from employee;
\n    InvalidRequest: Error from server: code=2200 [Invalid query] message=”unconfigured table employee”<\/em><\/p>\n

Restore<\/strong><\/p>\n

To restore the employee<\/strong> table from the keyspace (users)<\/strong> snapshot backup,, you must use the sstableloader<\/em> utility. The sstableloader<\/em> utility not only copies the set of sstables to each node but also transfers the appropriate part of the data to every node based on the replication strategy defined for a cluster. Note that it is not necessary to have an empty table to restore the
\ndata.<\/p>\n

Use the following steps to restore the tar file into backup\/users<\/strong>:<\/p>\n

    $ pwd
\n    \/bitnami\/cassandra\/data\/data\/backup\/users
\n    $ ls -ltr
\n    total 20
\n    -rw-r–r– 1 cassandra cassandra 20480 Apr 20 12:23 users-201904201800.tar
\n    $ tar -xvf *.tar
\n    manifest.json
\n    md-1-big-CompressionInfo.db
\n    md-1-big-Data.db
\n    md-1-big-Digest.crc32
\n    md-1-big-Filter.db
\n    md-1-big-Index.db
\n    md-1-big-Statistics.db
\n    md-1-big-Summary.db
\n    md-1-big-TOC.txt
\n    schema.cql<\/em><\/p>\n

Create a soft link for the user directory with the name of the table that you
\nare going to restore.<\/p>\n

    $ ln -s \/bitnami\/cassandra\/data\/data\/backup\/users employee
\n    $ ls -ltr
\n    total 64
\n    -rw-r–r– 1 cassandra cassandra   865 Apr 20 12:05 schema.cql
\n    -rw-r–r– 1 cassandra cassandra    92 Apr 20 12:05 md-1-big-TOC.txt
\n    -rw-r–r– 1 cassandra cassandra    56 Apr 20 12:05 md-1-big-Summary.db
\n    -rw-r–r– 1 cassandra cassandra  4683 Apr 20 12:05 md-1-big-Statistics.db
\n    -rw-r–r– 1 cassandra cassandra    32 Apr 20 12:05 md-1-big-Index.db
\n    -rw-r–r– 1 cassandra cassandra    16 Apr 20 12:05 md-1-big-Filter.db
\n    -rw-r–r– 1 cassandra cassandra    10 Apr 20 12:05 md-1-big-Digest.crc32
\n    -rw-r–r– 1 cassandra cassandra   134 Apr 20 12:05 md-1-big-Data.db
\n    -rw-r–r– 1 cassandra cassandra    43 Apr 20 12:05 md-1-big-CompressionInfo.db
\n    -rw-r–r– 1 cassandra cassandra    31 Apr 20 12:05 manifest.json
\n    -rw-r–r– 1 cassandra cassandra 20480 Apr 20 12:23 users-201904201800.tar
\n    lrwxrwxrwx 1 cassandra cassandra    41 Apr 20 15:56 employee -> \/bitnami\/cassandra\/data\/data\/backup\/users<\/em><\/p>\n

Create the table structure by using the .cql<\/strong> file that was generated by the snapshot backup.<\/p>\n

When you execute the backup for **keyspace**, it generates a file called schema.cql<\/strong> that contains the data definition language (DDL) of the objects that reside in keyspace<\/strong>.<\/p>\n

Use schema.cql<\/strong> to create an employee object, which got dropped by mistake.<\/p>\n

    $ cqlsh -u cassandra -p ******** -f schema.cql<\/em><\/p>\n

    Warnings:
\n    dclocal_read_repair_chance table option has been deprecated and will be removed in version 4.0<\/em><\/p>\n

    dclocal_read_repair_chance table option has been deprecated and will be removed in version 4.0<\/em>
\n    $ cqlsh -u cassandra -p ******* -f schema.cql<\/em><\/p>\n

Restore data from the snapshot by using sstableloader<\/em>, which reads every sstables<\/strong> from the backup and streams the data into the cluster. It then transfers the relevant part of data to each node based on the replication strategy defined in the cluster.<\/p>\n

    Syntax: sstableloader -u <username> -pw passwrod -d <hostname> <employee table softlink name with location><\/em><\/p>\n

Use the following command to restore the data:<\/strong><\/p>\n

  $  sstableloader -u cassandra -pw  ******** -d cassandra-cluster-1-node-0 \/bitnami\/cassandra\/data\/data\/backup\/users\/employee
\n    Established connection to initial hosts
\n    Opening sstables and calculating sections to stream
\n    Streaming relevant part of \/bitnami\/cassandra\/data\/data\/backup\/users\/md-1-big-Data.db  to [\/10.128.0.2, \/10.128.0.3, \/10.128.0.4]
\n    progress: [\/10.128.0.2]0:0\/1 0  % [\/10.128.0.3]0:0\/1 0  % [\/10.128.0.4]0:1\/1 100% total: 33% 0.032KiB\/s (avg: 0.032KiB\/s)
\n    progress: [\/10.128.0.2]0:0\/1 0  % [\/10.128.0.3]0:0\/1 0  % [\/10.128.0.4]0:1\/1 100% total: 33% 0.000KiB\/s (avg: 0.031KiB\/s)
\n    progress: [\/10.128.0.2]0:0\/1 0  % [\/10.128.0.3]0:1\/1 100% [\/10.128.0.4]0:1\/1 100% total: 66% 0.113KiB\/s (avg: 0.050KiB\/s)
\n    progress: [\/10.128.0.2]0:1\/1 100% [\/10.128.0.3]0:1\/1 100% [\/10.128.0.4]0:1\/1 100% total: 100% 85.129KiB\/s (avg: 0.074KiB\/s)
\n    progress: [\/10.128.0.2]0:1\/1 100% [\/10.128.0.3]0:1\/1 100% [\/10.128.0.4]0:1\/1 100% total: 100% 0.000KiB\/s (avg: 0.073KiB\/s)
\n    progress: [\/10.128.0.2]0:1\/1 100% [\/10.128.0.3]0:1\/1 100% [\/10.128.0.4]0:1\/1 100% total: 100% 0.000KiB\/s (avg: 0.073KiB\/s)<\/em><\/p>\n

    Summary statistics:
\n       Connections per host    : 1
\n       Total files transferred : 3
\n       Total bytes transferred : 0.393KiB
\n       Total duration          : 5346 ms
\n       Average transfer rate   : 0.073KiB\/s
\n       Peak transfer rate      : 0.074KiB\/s<\/p>\n

Repeat these steps for every node to retrieve the data from their sstables.<\/em><\/p>\n

Repair the data by using `nodetool repair<\/em>`, which compares all replicas of the data stored on the node on which the command runs and updates each replica to the newest version.<\/p>\n

    $ nodetool repair -u Cassandra -pw ********<\/em><\/p>\n

    [2019-04-21 07:59:14,701] Starting repair command #1 (5b123ad0-640b-11e9-a0e3-570eb7f8fd5f), repairing keyspace users with repair options (parallelism: parallel, primary range: false, incremental: true, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts: [], # of ranges: 768, pull repair: false)
\n    [2019-04-21 07:59:16,450] Repair completed successfully
\n    [2019-04-21 07:59:16,451] Repair command #1 finished in 1 second
\n    [2019-04-21 07:59:16,460] Replication factor is 1. No repair is needed for keyspace ‘system_auth’
\n    [2019-04-21 07:59:16,474] Starting repair command #2 (5c22e780-640b-11e9-a0e3-570eb7f8fd5f), repairing keyspace system_traces with repair options (parallelism: parallel, primary range: false, incremental: true, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts: [], # of ranges: 513, pull repair: false)
\n    finished (progress: 1%)
\n    [2019-04-21 07:59:17,653] Repair completed successfully
\n    [2019-04-21 07:59:17,653] Repair command #2 finished in 1 second<\/em><\/p>\n

Validate data into the employee<\/strong> table, which we dropped. The previous command restored the data from the backup you took previously. Now you need to validate the data to see if it was restored properly.<\/p>\n

    $ cqlsh -u cassandra -p ********<\/em><\/p>\n

 Connected to Test_Cassandra at 127.0.0.1:9042.
\n    [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
\n    Use HELP for help.<\/em><\/p>\n

    cassandra@cqlsh> use users;<\/em><\/p>\n

    cassandra@cqlsh:users> select * from employee;<\/em><\/p>\n

     emp_id | employee_address | employee_name
\n    ——–+——————+—————
\n       8796 |        Singapore |           Joy
\n       5647 |           London |          Mike
\n       3452 |           Canada |         Nancy
\n       6453 |            China |          John<\/em><\/p>\n

    (4 rows)<\/em>
\n <\/p>\n

Conclusion<\/strong><\/p>\n

In this post, you learned how to backup and restore a table into a Cassandra database. However, if you need to restore a full keyspace\/database, use the preceding steps without the table restore part. You must recreate the keyspace<\/strong> and load data by using `sstableloader<\/em>`.<\/p>\n

The number of nodes in the source and target databases cluster doesn\u2019t matter with `sstableloader<\/em>` because it reads each sstables<\/strong> from the backup. Then, it streams the data into the cluster while placing the data according to the defined replication strategy in the cluster.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

Apache Cassandra backup and recovery<\/p>\n","protected":false},"author":2,"featured_media":8151,"menu_order":0,"comment_status":"open","ping_status":"open","template":"","format":"standard","meta":{"content-type":"","nid":"26609","content_type":"blog","created_by":"10130","authored_on":"2024-02-13T17:34:26+00:00","field_article_industries":"","tag_category":"Technical","field_blog_author_text":"by Rackspace Technology Staff","seo_description":"Backup and recover Apache Cassandra databases. Mitigate data loss risks and ensure smooth business operations.\r\n","field_featured_image":"","insights_image":"\/wp-content\/uploads\/2026\/blog_technical_images\/26609-insights_image-database-technical-blog-2-insights.jpg","field_partners":"","rxt_platforms":"Big Data, Relational Databases","product":"","publisheddate":"2019-07-17T16:34:27","rxt_solutions":"Cloud, Data, Databases, Next-Gen Data Platforms","opengraph_tag":"","x_tag":"","teaser_flag":"Technical Blog","seo_titile":"Apache Cassandra: Backup and Recovery Strategies | Rackspace Technology","field_topics":"","field_slug":"apache-casandra-backup-and-recovery","footnotes":""},"categories":[178],"tags":[204],"class_list":["post-8149","blogs","type-blogs","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-technical"],"_links":{"self":[{"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/blogs\/8149","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/blogs"}],"about":[{"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/types\/blogs"}],"author":[{"embeddable":true,"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/comments?post=8149"}],"version-history":[{"count":3,"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/blogs\/8149\/revisions"}],"predecessor-version":[{"id":9914,"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/blogs\/8149\/revisions\/9914"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/media\/8151"}],"wp:attachment":[{"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/media?parent=8149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/categories?post=8149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/tags?post=8149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}