Linux Cassandra备份与恢复：Snapshot、Incremental Backup 与 sstableloader

一、Cassandra 备份恢复原理概述

1.1 为什么 Cassandra 备份相对简单？

Cassandra 是分布式、无单点、Immutable SSTable 设计：

• 数据多副本（RF≥2推荐）
• SSTable 一旦写入不可改，只追加/合并
• 备份只需硬链接快照（零拷贝，几乎无开销）

核心机制：

• Snapshot：全量快照（硬链接现有SSTable）
• Incremental Backup：增量备份（新SSTable硬链接）
• CommitLog：可选备份（用于点对点恢复，但生产少用）

恢复方式：

• 清空目录 + 加载Snapshot（单节点）
• sstableloader 流式加载（集群、跨版本）

1.2 RPO/RTO 目标

• RPO（恢复点）：Snapshot间隔决定（小时级）
• RTO（恢复时间）：sstableloader并行加载（TB级小时内）

生产目标：RPO<4小时，RTO<24小时（视规模）

二、Snapshot（全量快照）实战

2.1 Snapshot 原理

• 使用硬链接（hard link）创建SSTable副本
• 零额外空间（直到Compaction删除原文件）
• 每个表独立目录：/data/cassandra/data/keyspace/table-uuid/snapshots/snapshot_name/

2.2 创建Snapshot

# 全集群指定keyspace
nodetool snapshot keyspace1 keyspace2 -t daily_backup_$(date +%Y%m%d)

# 单节点指定表
nodetool snapshot -t my_snapshot keyspace.table

# 全集群所有数据（慎用，大集群慢）
nodetool snapshot -t full_backup

• -t：快照标签（名称）
• 5.0优化：并行生成，支持--skip-flush（不flush Memtable，风险高）

验证：

nodetool listsnapshots
# 输出：Snapshot name、Keyspace、Table、Size、True size（硬链接实际0）

目录示例：

/data/cassandra/data/prod/users-uuid/snapshots/daily_backup_20251230/
├── la-1-big-Data.db -> ../../la-1-big-Data.db  # 硬链接
├── ...

2.3 清理Snapshot

# 删除指定
nodetool clearsnapshot -t old_snapshot keyspace

# 删除所有
nodetool clearsnapshot --all

生产：定期清理旧Snapshot，避免Compaction后硬链接失效（空间膨胀）

2.4 备份到远程存储

Snapshot后，rsync/scp到NFS/S3：

# 示例脚本
BACKUP_DIR=/backup/cassandra/$(date +%Y%m%d)
mkdir -p $BACKUP_DIR

for ks in prod logs; do
    nodetool snapshot $ks -t daily_$(date +%Y%m%d)
    rsync -av /data/cassandra/data/$ks/*/snapshots/daily_* $BACKUP_DIR/$ks/
    nodetool clearsnapshot -t daily_$(date +%Y%m%d) $ks
done

# 上传S3（aws cli）
aws s3 sync $BACKUP_DIR s3://cassandra-backup/

• 优势：清快照前备份，空间零开销

三、Incremental Backup（增量备份）

3.1 启用与原理

cassandra.yaml：

incremental_backups:true# 默认false，生产必开
snapshot_before_compaction:false# 可选，Compaction前快照
auto_snapshot:true# TTL删除前快照，默认true

• 启用后：每次flush/compaction后，硬链接新SSTable到 /data/cassandra/data/keyspace/table-uuid/backups/
• 增量：只备份新/修改SSTable

3.2 管理Incremental文件

目录：.../backups/ 下SSTable硬链接

备份策略：

• 定期rsync backups目录到远程
• 清空本地：手动删除旧文件（慎用）

脚本示例：

# 每日增量备份
INCR_BACKUP=/backup/incr/$(date +%Y%m%d)
mkdir -p $INCR_BACKUP

rsync -av /data/cassandra/data/*/backups/ $INCR_BACKUP/

# 可选：清理7天前本地backups（保留空间）
find /data/cassandra/data/*/backups/ -mtime +7 -delete

3.3 全+增量恢复策略

• 全备：每日Snapshot
• 增备：每小时rsync backups
• 恢复：先加载最近Snapshot，再加载后续增量SSTable

四、sstableloader：恢复与迁移神器

4.1 sstableloader 原理

• 流式加载SSTable到集群（streaming）
• 支持跨版本、跨集群、离线数据导入
• 自动计算Token、平衡数据

4.2 恢复单节点/小集群

1. 清空数据目录（或新节点）
2. 硬链接Snapshot文件到数据目录（去掉snapshots层）
3. 启动Cassandra（bootstrap恢复）

4.3 大集群恢复/迁移实战

# 在备份服务器准备SSTable目录（Snapshot + 所有增量backups）
# 结构必须保持：keyspace/table-uuid/*.db

sstableloader -d 10.0.0.10,10.0.0.20 /backup/restore_dir/

# 选项：
# -d：种子节点
# --throttle：限速MB/s
# --inter-dc-throttle：跨DC限速
# --ignore：忽略缺失节点

监控：

nodetool netstats  # 查看streaming进度

5.0优化：更快streaming，支持SAI索引加载

4.4 跨版本迁移

• 从4.x备份 → 5.0集群：先upgradesstables，再sstableloader

五、生产备份恢复策略制定

5.1 推荐策略

• 频率：
• Snapshot：每日全量（夜间）
• Incremental：每小时/实时rsync
• 存储：
• 本地：保留最近3天
• 远程：S3/OSS，版本化，保留30天/永久
• 多副本：备份存储RF=3
• 加密：传输TLS，存储SSE

5.2 自动化脚本模板（crontab）

# /etc/cron.d/cassandra_backup
0 2 * * * /opt/scripts/daily_snapshot.sh
*/30 * * * * /opt/scripts/incr_backup.sh

5.3 灾难恢复演练（DR Drill）

季度演练：

1. 模拟集群全毁
2. 新建空集群（相同版本、配置）
3. sstableloader加载最近全备+增备
4. 验证数据一致性（行数、checksum）
5. 记录RTO

工具：cassandra-stress验证

六、常见问题排查与案例

1. Snapshot空间膨胀 → Compaction删除原文件后硬链接失效 → 先备份再clear
2. Incremental缺失文件 → Compaction清理旧SSTable → 依赖全Snapshot
3. sstableloader卡住 → 网络/Throttle → 检查netstats
4. 恢复数据不一致 → 未加载所有增量 → 按时间序加载
5. 大表加载慢 → 分批sstableloader或--connections-per-host调高

真实案例：

• 某公司误删Keyspace → 最近Snapshot + 增量sstableloader，RTO 4小时，零丢失
• 机房故障 → 异地S3备份恢复新集群，RTO 12小时
• 版本升级 → sstableloader迁移数百TB，平滑无停机