How-To Backup Cassandra Hosted on the AWS Cloud – Part 2

n2wsIn part 1 of this series, we reviewed Cassandra node-based architecture and described how to perform backups and recoveries with Cassandra’s inherent mechanism. Given the importance of database backup, it’s good to know that hosting your database on AWS makes database backup much easier. In this post, we will set up a Cassandra 2.0 multi-node cluster on AWS EC2, then show you how to achieve consistent backup with CPM.

If you are planning on using a multi-node cluster, Cassandra provides an AMI for easy setup, but it only spans a single region. If you need to set up a multi-region cluster, you have to set up Cassandra manually.

For the sake of this article, we are using Cassandra on a multi-node cluster and have inserted data by creating a keyspace, schema and table. If you have a production database, it’s imperative to maintain consistent database backups for optimal high availability and data recovery.

Cassandra Backup with CPM

When a database is hosted on AWS EBS, it has the option of using EBS Snapshots to perform crash-consistent database backups. Amazon snapshots offer a one-click backup and restore option. Crash-consistent backup means that a backup will be performed on the data that is written on the EBS volume. However, if any data is in the memory/cache due to the application’s specific configuration, it will not be included in the EBS snapshot. The best possible solution for data backup and recovery is to take application consistent snapshots at regular intervals. Since AWS EBS snapshots provide incremental storage, it is best to run automated backups, both at frequent time intervals and on a regular basis. It is erroneous to take snapshots manually at regular intervals because they will always include more manual effort and may run the risk of missing critical backups.

It is important to note that Cassandra does not recommend using EBS volumes for its clusters due to low disk and IO performance as well as EBS size limitations. However, this recommendation was written before major improvements were made to EBS. The C4 Instance family now offers better network performance, and EBS optimized instances and Provisioned IOPS provide better IO performance. Additionally, high performing General Purpose volumes and EBS’ 16TB disk solve the sizing issue.

Cloud Protection Manager (CPM) comes in very handy for system administrators by offering a very simple and user-friendly web interface to manage automated EC2 and RDS backups. Additionally, CPM provides a quick disaster recovery solution as well as the option to achieve application consistent backup, helping to achieve better data backup management and recovery.
CPM offers flexible backup policies that you create based on your specific requirements and allows you to perform backups at regular intervals. CPM also provides you with the option to copy EBS snapshots to other regions. You can restore complete backups with a single click.

To achieve application consistent backup, it is recommended to run backup scripts first to inform the OS that an AWS EBS snapshot is being taken, then perform the backup. To achieve this, you should freeze your database temporarily by flushing all of your data to disks. As mentioned above, CPM offers application consistent backup both for Windows and Linux. In Windows, it allows you to perform a VSS backup that is the same as the Windows VSS feature, whereas with Linux instances, it offers the option to run scripts on database instances before snapshots are taken. An advantage of CPM is that it offers scripts that can run before, as well as on completion of an EBS snapshot.

We will now configure the Cassandra database that we set up on EC2 with CPM for application consistent backups. Refer to our earlier guides about setting up a backup and restore schedule and policy with CPM.

As mentioned in How-To Backup Your AWS Cloud Based PostgreSQL Database, CPM can execute three different scripts: “Before”, “After” and “Complete”. It is mandatory to create each script, and if no command needs to be executed, leave it blank.

For application consistent backups, it is recommended to flush all data from memory to disk and then freeze data writes during snapshots. It is important to note that Cassandra flushes nodes before taking a snapshot, then takes the snapshot and stores the data in the snapshot directory for each keyspace data directory. We will use Cassandra’s built-in snapshot mechanism as part of CPM’s ‘before’ script to take application consistent EBS snapshots using scripts. Since we have set up Cassandra with three nodes, Cassandra’s built-in snapshot (see part 1 of this post) should be executed simultaneously on all three nodes. We have configured a script in Node-1 that will run the push command and perform Cassandra’s inherent backup on all three nodes.

Cassandra Keyspace Backup Script(db_start_backup.sh)

#!/bin/bash

echo “Taking snapshot…” 1>&2

pssh -i -h /home/ec2-user/hosts -x “-oStrictHostKeyChecking=no -i /home/ec2-user/n2ws.pem” ‘hostname;nodetool snapshot;echo ——‘ 1>&2

echo “Snapshot completed”  1>&2

CPM Script

CPM runs a ‘before’ script before it starts performing backups.

CPM executes the following scripts:

 

“Before” script ->(before_<policyname>.sh)

#!/bin/bash
ssh -i <location of pem file to SSH>  <user-name>@<IP Address of PostgreSQL machine> “db_start_backup.sh”

“After” script ->(after_<policyname>.sh)

#!/bin/bash

“Complete” script ->(complete_<policyname>.sh)

#!/bin/bash

Since we don’t need to run any ‘after’ or ‘complete’ commands, we have kept them blank. You can always run commands (e.g., deleting Cassandra’s backup from a local machine or copying data from one volume to another) in the ‘after’ or ‘complete’ scripts.

If the backup is successful, it will show the output as follows:
n2ws When you open the success log, you should see:
n2ws
A file will be created in Cassandra’s backup folder: ‘/var/lib/cassandra/demo1/users/snapshot’
n2ws
If you have configured to capture the log output of your script, you can find the output that was sent to ‘std.err’ in the CPM recovery panel:
n2ws

Once you are sure that your snapshots are running successfully and your data is consistent with the application consistent snapshots, you can write scripts to remove the backup files and execute those scripts from CPM’s ‘complete’ scripts. If you refer to Cassandra documentation, it says that a Cassandra snapshot first flushes all in-memory writes to disk, then makes a hard link of the SSTable files for each keyspace. This helps in achieving application consistent snapshots but also requires that you have enough free disk space on the node to accommodate new Cassandra snapshots of your data files. A single snapshot requires little disk space. However, snapshots can cause your disk usage to grow quickly over time because a snapshot prevents old obsolete files from being deleted.

It’s important to note that like AWS snapshots, Cassandra snapshots are also incremental. Therefore, if you delete the backup files, a full backup may be performed again at the same time that the inherent Cassandra backup occupies space.

In this article, we have demonstrated how running scripts from our Cloud Protection Manager (CPM) can help you achieve application consistent backup with Cassandra. CPM is an enterprise-class backup solution for EC2 based on EBS and RDS snapshots. If you are hosting production class databases such as MS-SQL, MySQL, MongoDB, or Oracle, CPM can provide you with a best-in-class automated backup and recovery solution. CPM supports consistent application backups on Linux as well as Windows servers. CPM is sold in the AWS Marketplace. See pricing or try it for free.

Share this post →

You might also like: