7.2、Cassandra快照备份
7.2.1、关于快照
Cassandra通过对存储在数据目录中的所有磁盘数据文件（SSTable文件）进行快照来备份数据。 您可以在系统处于联机状态时拍摄所有keyspace，单个keyapace或单个table的快照。
使用并行ssh工具（如pssh），可以快照整个群集。 这提供了最终一致的备份。 尽管在创建快照时没有一个节点与其副本节点保持一致，但恢复的快照使用Cassandra的内置一致性机制恢复一致性。
执行全系统快照后，可以在每个节点上启用增量备份来备份自上次快照后更改过的数据：每次将memtable刷新到磁盘并创建SSTable时，快照都将被复制到/data目录的备份子目录（JNA已启用）。压实的SSTables不会在/backups中创建快照，因为这些SSTables不包含任何尚未备份的数据。
7.2.2、拍摄快照
使用nodetool snapshot命令为每个节点创建快照 。 要获取全局快照，请使用并行ssh实用程序（如pssh）运行nodetool snapshot命令。
快照首先将所有内存中的写入操作（memtables）刷新到磁盘，然后为每个keyspace创建一个SSTable文件的映射。 节点上必须有足够的可用磁盘空间来容纳数据文件的快照。 一个快照只需要很少的磁盘空间。 但是，由于快照不能删除旧的过时数据文件，因此快照可能会导致磁盘使用率随着时间的推移而增长得更快。 快照完成后，您可以根据需要将快照文件移动到其他位置，也可以将其保留在原位。
注意： Cassandra只能在表system_schema存在时从快照中恢复数据。 建议您也备份表system_schema。
运行nodetool snapshot命令，指定主机名，JMX端口和密钥空间。 例如：
$ nodetool -h localhost -p 7199 snapshot mykeyspace快照是在 data/keyspace/table_name-UUID/snapshots/snapshot_name 目录中创建的。 每个快照目录都包含许多快照时数据的.db文件。
例如：
Cassandra软件包安装： /var/lib/cassandra/data/mykeyspace/users-081a1500136111e482d09318a3b15cc2/snapshots/1406227071618/mykeyspace-users-ka-1-Data.db
Cassandra tarball安装： install_location /data/data/mykeyspace/users-081a1500136111e482d09318a3b15cc2/snapshots/1406227071618/mykeyspace-users-ka-1-Data.db
7.2.3、删除快照文件
拍摄快照时，以前的快照文件不会自动删除。 您应该删除不再需要的旧快照。
nodetool clearsnapshot命令将从每个keyspace的快照目录中删除所有存在的快照文件。 您应该在快照备份之前执行此命令，以便在更新快照之前清除旧快照。
- 要删除节点的所有快照，请运行nodetool clearsnapshot命令。 例如：
$ nodetool -h localhost -p 7199 clearsnapshot - 要一次删除所有节点上的快照，请使用并行ssh实用程序运行nodetool clearsnapshot命令。
要删除单个快照，请使用快照名称运行clearsnapshot命令：
$ nodetool clearsnapshot -t 文件名和路径根据快照的类型而有所不同。 有关快照名称和路径的详细信息，请参阅nodetools快照 。
7.2.4、启用增量备份
启用增量备份（默认情况下禁用）时，Cassandra会将每个可刷新表的SSTable映射到keyspace数据目录下的备份目录。 这允许在不传输整个快照的情况下将备份存储在异地。 而且，增量备份与快照相结合，可以提供可靠的最新备份机制。 压实的SSTables不会在/backups中创建映射文件，因为这些SSTables不包含任何尚未备份的数据。 一个时间点的快照，加上所有的增量备份和提交日志，形成一个完整的备份。
与快照一样，Cassandra不会自动清除增量备份文件。建议在每次创建新快照时设置一个进程来清除增量备份文件。
编辑集群中每个节点上的cassandra.yaml配置文件，并将incremental_backups的值更改为true。
7.2.5、快照恢复数据
从快照恢复keyapce需要表的所有快照文件，如果使用增量备份，则包括在创建快照之后创建的任何增量备份文件、SSTables（从 repair、decommission等）在内。
注意：从快照和增量备份还原临时会导致正在恢复的节点上的CPU和I / O活动密集。
7.2.6、从本地节点恢复
此方法将快照目录中的SSTables复制到正确的数据目录中。
1.确保表system_schema存在。当表system_schema存在时，Cassandra只能从快照中恢复数据。 如果schema不存在并且尚未备份，则必须重新创建schema。
2.如有必要， 截断表格。
3.找到最近的快照文件夹。 例如：
data_directory/keyspace_name/table_name-UUID/snapshots/snapshot_name4.将最新的快照SSTable文件目录复制到data_directory / keyspace / table_name - UUID目录 。
5.运行nodetool refresh.。
注意：您可能不需要在某些条件下截断。 例如，如果某个节点丢失了一个磁盘，则在恢复之前可能需要重新启动，以便节点在开始还原过程之前继续接收新的写入。
截断通常是必要的。 例如，如果意外删除了数据，那么该删除的逻辑删除后面的写入时间戳将比快照中的数据晚。 如果恢复时没有截断（移除墓碑），Cassandra将继续遮盖恢复的数据。 其他类型的重写也会发生此行为并导致相同的问题。
如果节点位于5.0.10之前的DataStax Enterprise版本上，请重新启动节点 。 此重新启动是必需的，因为nodetool刷新不尊重磁盘上现有的LCS级别，这会导致压缩积压。
7.2.7、从集群中备份恢复
此方法使用sstableloader来恢复快照。
1.确保表system_schema存在。当表system_schema存在时，Cassandra只能从快照中恢复数据。 如果schema不存在并且尚未备份，则必须重新创建schema。
2.如有必要， 截断表格。
3.使用备份的SSTables上的sstableloader工具还原最近的快照。
sstableloader将SSTables流式传输到正确的节点。 不需要删除提交日志或者删除重启节点。
注意：您可能不需要在某些条件下截断。 例如，如果某个节点丢失了一个磁盘，则在恢复之前可能需要重新启动，以便节点在开始还原过程之前继续接收新的写入。
截断通常是必要的。 例如，如果意外删除了数据，那么该删除的逻辑删除后面的写入时间戳将比快照中的数据晚。 如果恢复时没有截断（移除墓碑），Cassandra将继续遮盖恢复的数据。 其他类型的重写也会发生此行为并导致相同的问题。