Back up and restore a DSE tarball installation

You can back up and restore your entire DataStax Enterprise (DSE) installation, including configuration files, logs, and data (SSTable snapshots). This process is separate from data-only backup operations like nodetool snapshot or the Backup Service.

DataStax recommends that you create a backup before upgrading DSE. If you need to rollback the upgrade, you can restore the backup.

Back up a tarball installation

Make sure you have sufficient disk space to store a complete data snapshot (SSTables) and a compressed TAR archive of the snapshot.
Create a directory outside of your existing DSE installation to store the backup files.

The examples in this guide use the placeholder /backup_path.
Back up the schema to schema_filename.cql using cqlsh.
```
/INSTALL_DIRECTORY/resources/cassandra/bin/cqlsh host_ip_address:port -e 'DESC SCHEMA;' > /backup_path/schema_filename.cql
```
A schema backup ensures that, even if data is lost, you can rebuild the database structure.

Back up the token ranges to token_range_filename using nodetool:

/INSTALL_DIRECTORY/resources/cassandra/bin/nodetool ring > /backup_path/token_range_filename

Add the following DSE configuration file types to a plain text file listing, backup_file_listing:

*.yaml
*.sh
*.xml
*.properties
*.default
Any other file types that you use

You can use find or a similar command to automate this process. The following example gets DSE configuration files from the default directories. If you use non-default directories, modify your script accordingly.

find /INSTALL_DIRECTORY -type f -name ".yaml" -o -name ".sh" -o -name ".xml" \
-o -name ".properties" -o -name "*.default" -type f >> "/backup_path/backup_file_listing"

It is critical that you store your backup configuration files in a separate directory from your DSE installation or the directory where you typically run DSE commands like nodetool or dsetool. The new version overwrites configuration files that are present in the installation directory, replacing all existing values with new default values.

Create a full snapshot using nodetool, and then add the snapshot filenames to your plain text file listing (backup_file_listing).

In the following example, the snapshot is named snapshot_name.
```
/INSTALL_DIRECTORY/resources/cassandra/bin/nodetool snapshot -t snapshot_name
find /DATA_DIRECTORY/ -path /snapshots/snapshot_name/ -type f >> "/backup_path/backup_file_listing"
```
Make note of the snapshot name in case a restore is required.

Add the commit logs to your plain text file listing (backup_file_listing):

sudo find /DATA_DIRECTORY/commitlog -type f >> "/backup_path/backup_file_listing"

Using backup_file_listing, create one .tar archive containing all backup files.

In the following example the archive is named backup_archive_name.tar.
```
sudo /bin/tar -pzcvf /backup_path/backup_archive_name.tar --files-from=/backup_path/backup_file_listing
```
For large databases, consider using the nice command to reduce the load on the node:
```
sudo /usr/bin/nice -10 /bin/tar -pzcvf /backup_path/backup_archive_name.tar --files-from=/backup_path/backup_file_listing
```
Copy backup_archive_name.tar, token_range_filename, and schema_filename.cql to a secure location, separate from your current installation,in case you need to roll back the upgrade and restore your current installation.
Repeat for all nodes in all clusters that you plan to upgrade.

Restore a tarball installation

When restoring an installation from a backup, you must not change the installation structure. If your restore scenario requires changing the structure of the restored installation, you must make any necessary path and configuration adjustments to ensure the restored installation functions correctly.

Stop the DSE service if it is running.

/INSTALL_DIRECTORY/bin/dse cassandra-stop

Remove the existing DSE installation directory.
```
rm -rf /INSTALL_DIRECTORY/
```
Completely purge any existing data or configuration directories and files.

The following example uses the default directories. If you use custom directories, modify the commands accordingly.

The spark and dsefs commands are only necessary if you are using Spark or DSEFS.
```
sudo rm -rf /var/lib/cassandra
sudo rm -rf /var/log/cassandra
sudo rm -rf /var/log/spark
sudo rm -rf /var/lib/spark
sudo rm -rf /var/lib/dsefs
```
Reinstall the old version as described in the documentation for that release of DSE.

Do not start DSE after installation.
Extract your backup to the root of your drive.

The following example uses a backup directory named /backup_path and a backup archived named backup_archive_name.tar.
```
sudo tar -xvf /backup_path/backup_archive_name.tar -C /
```
Move the snapshot files up two levels to their keyspace directories.

In the following example, replace snapshot_name with the name of the snapshot from your backup archive. If you use non-default directories, modify the command accordingly.
```
sudo find /var/lib/cassandra/data -mindepth 2 -path '*/snapshots/snapshot_name/*' -type f \
-exec bash -c 'dir={} && cd ${dir%/*} && mv {} ../..' \;
```
If you don’t know the snapshot name, you can find it by browsing your tar archive.
Restore permissions.

If you use non-default directories, modify the following command accordingly.
```
sudo chown dse_username:dse_group /var/lib/cassandra
```
Start DSE:
```
/INSTALL_DIRECTORY/bin/dse cassandra
```
If you use DSE Search, rebuild the index with dsetool reload_core.

Back up and restore a DSE tarball installation

Back up a tarball installation

Restore a tarball installation

See also

Was this helpful?

Give Feedback