On this page
Scripts
The following are the script files used in this installation:
backup.sh
This script creates snapshots of Cassandra database. The script must run on the host running Cassandra and Cassandra must be running. The Cassandra bin directory or nodetool must be added to $PATH (on Linux, nodetool is available when the Cassandra package is installed without further modifications). The backup script preserves the database file permissions and owner. On Linux, you should be running on a shell with root permissions.
The command format for backing up is:
./backup.sh -dir CASSANDRA_DB_PATH -rf BACKUP_DIR
where CASSANDRA_DB_PATH is the directory below where the Cassandra data is located, and BACKUP_DIR is the location in which the snapshot archives are to be saved.
The archive is named using a pattern cassandra_backup_yyyy.mm.dd-hh.mm.ss.tar
If any of the parameters are omitted then the script will prompt you for the locations, and perform sanity checks to make sure the values are correct.
Path names
When calling the backup/restore scripts passing parameters, if your path names contain spaces, they must be quoted.
For example:
./backup/sh -dir "/path to data containing spaces/data" -rf "/path to backups containing spaces/"
Windows snapshots
Due to the manner in which hard links (used by the snapshot process) are handled by Windows, existing snapshots do not get cleared until the Cassandra service is restarted. Therefore, on Windows, it is recommended to schedule a task to be performed during maintenance to restart Cassandra to complete the clearing process. After restarting Cassandra, the Teamwork Cloud and Authserver services should also be restarted.
restore-single_node_311.sh
This script should be run as root on Linux and Cygwin console must be launched with the administrator privileges. This script restores data from the backup file. While restoring Cassandra, Teamwork Cloud server must be turned off. The script stops and starts Cassandra if needed. The backup script preserves the database file permissions and owner, and then restores backup on another machine with another user. Therefore, the file permissions must be changed manually otherwise Cassandra may not start. The following variables may be passed onto the script:
Usage: ./restore-single_node_311.sh [--dir <arg>] [--commitlog <arg>] [--rf <arg>] [--cassandra <arg>] [-h|--help] --dir: cassandra database path (default:cassandra_database) --commitlog: commitlog path (default: commitlog_path) --rf: full path to snapshot archive (default: rf) --cassandra: cassandra installation path when cassandra is not executed as a service (default: cassandra) -h,--help: Prints help
Even though parameters can be passed to the restore script, restores are typically carried out in an interactive manner.
Variable | Description |
---|---|
commitlog_path | The path of commitlog files. They are removed when restoring database to prevent recovery of commits made earlier. DataStax recommends to store the commitlog files in a separate hard-disk for performance sake. |
cassandra_database | The Cassandra database path. It is used to clean existing database and restoring database from the recovery file. |
cassandra | The Cassandra installation path. It is the required parameter when Cassandra is launched not as service. |
service | The Boolean parameter indicating that Cassandra is started as a service. The default value is true so you need to set this variable to false when Cassandra is launched by the other script or manually. |
rf | The recovery file with the full path to it. |
On Linux
Type:
$ su ./restore-single_node_311.sh
or
$ sudo su $ ./restore-single_node_311.sh
If you are logged in as root, the command is:
$ ./restore-single_node_311.sh
On Windows
Use the Cygwin tool and type:
$ ./restore-single_node_311.sh
The following are some other examples for Linux (just remove 'su' parameter on Cygwin):
Parameters passed as environment variables $ cassandra_database=<cassandra_database_path> commitlog_path=<cassandra_commitlog_path> rf=<backup_file_to_restore> su ./restore-single_node.sh Example $ cassandra_database=/var/lib/cassandra commitlog_path=/var/lib/cassandra/commitlog rf=/home/<user>/backups/cassandra_backup_2016.07.29.12.23.24.tar su ./restore-single_node.sh Parameters passed on the command line $ su ./restore-single_node.sh -dir <cassandra_database_path> -commitlog <cassandra_commitlog_path> -rf <backup_file_to_restore> Example $ su ./restore-single_node.sh -dir /var/lib/cassandra -commitlog /var/lib/cassandra/commitlog -rf /home/<user>/backups/cassandra_backup_2016.07.29.12.23.24.tar
Cassandra should be running as a service, but if for some reason you are running it as an application then you must set the variable service to false. See the following example:
$ service=false su ./restore-single_node.sh
You will be then asked to enter the following information:
Please enter Cassandra database directory. i.e. /var/lib/cassandra: Please enter Cassandra commitlog directory. i.e. /var/lib/cassandra/commitlog: Please enter Cassandra home directory. i.e. /opt/cassandra-2.2.5: Please enter backup file location. i.e. /home/<user>/backups/: or parameters can be set(please note that order maters). i.e. : $ su service=false ./restore-single_node.sh -dir <cassandra_database_path> -commitlog <cassandra_commitlog_path> -rf <backup_file_to_restore> -cassandra=<cassandra_home> $ su service=false ./restore-single_node.sh -dir /var/lib/cassandra -commitlog /var/lib/cassandra/commitlog -rf /home/<user>/backups/cassandra_backup_2016.07.29.12.23.24.tar -cassandra=/opt/apache-cassandra-2.2.5
To learn how to delete resources, restore projects, and other administrative processes, see Data Manager.
Related pages