Cassandra is a peer-to-peer, fault-tolerant system. Data is replicated among multiple nodes across multiple data centers. Single or even multi-node failures can be recovered from surviving nodes with the data.
Restores from backups are unnecessary in the event of disk or system hardware failure even if an entire site goes off-line. As long as there exists one node with the replicated data in one data center, Cassandra can recover the data without having to restore data from an external source.
However, Cassandra backups are still necessary to recover from any errors made in data edits by client applications. There is a need for a “point-in-time” recovery of Cassandra in the event of data corruption or some other catastrophic situation.
Cassandra provides backup utilities and a restore process. Constant Contact has extended these features with scripts to provide more flexibility with backups and to simplify recovery operations.
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 of all keyspaces, a single keyspace, or a single table while the system is online.
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).
Some administrators simply use Cassandra’s built-in replication and multi-data center capabilities for backup. Because the functionality is native to Cassandra, there is no need for add-on software (e.g. Oracle Dataguard). Since replication is so easy to use, some DBA’s just create one or more physical or virtual data centers for a cluster and utilize them for disaster recovery purposes.
While such a strategy can be satisfactory for some situations, it is important to note that it will not protect you in cases where large amounts of data are deleted, tables are dropped, and other similar unintended actions are carried out – such activities will be replicated and applied to the other data centers.
The Apache distribution of Cassandra does not automatically take backups of it’s data. However, it does include a tool to create backups. Backups in Cassandra are called “snapshots”. In the photography sense of the word, a snapshot is a picture of what the data looks like at a moment in time. Since data in Cassandra is immutable, taking a snapshot is quick, painless, and has very little impact on the system.
Cassandra allows you easily backup all keyspaces in a cluster, certain selected keyspaces, or only desired tables in a keyspace. A backup is called a snapshot in Cassandra.
You can take snapshots of your cluster via either a command line utility or visually through DataStax OpsCenter. While you can certainly script your own backups via command line utilities, OpsCenter provides an easy way to design and schedule your backups through its Web interface.
DataStax OpsCenter’s backup interface.
Note that you can also customize backups in OpsCenter by writing and including scripts that run both before and after a backup.
Lastly, incremental (only new or changed data versus full) backups are also supported for Cassandra.
If you’ve ever lost your production data or discovered that it had been corrupted, then you know the importance of being able to restore that data. Restoring your Cassandra data can be quick and painless. The following three methods will help you to gain a better understanding of what’s involved.
Before you begin to restore data then you have to have data to restore. Once you’re sure, your data is safely backed up, then you can focus on how to restore it.
Currently, Apache Cassandra provides three methods to restore data from a snapshot (Cassandra’s term for a backup):
Each of these methods will ultimately restore data to a node. However, each has a different set of circumstances for when to use. It’s important to know when to use each.
Database recovery operations can be carried out with either command line utilities or visually through DataStax OpsCenter. Restores can be full, utilize incremental backups, and also be object-level if needed (e.g. you can only restore one backed up table versus all tables).
Restoring a keyspace with OpsCenter.
OpsCenter makes restore operations especially easy and handles restore tasks on all affected nodes in a cluster with the push of a button.
Ravindra Savaram is a Content Lead at Mindmajix.com. His passion lies in writing articles on the most popular IT platforms including Machine learning, DevOps, Data Science, Artificial Intelligence, RPA, Deep Learning, and so on. You can stay up to date on all these technologies by following him on LinkedIn and Twitter.