上周朋友的电商后台崩了，Redis缓存全丢，订单状态错乱，凌晨三点还在翻日志。他说‘不就是个缓存嘛’，结果发现用户下单后查不到记录，客服电话被打爆——NoSQL不是‘不用备份’，而是‘得换种方式备份’。
MongoDB：别只靠mongodump，试试文件快照
mongodump看着简单，但大库导出慢、恢复时锁库、还不能保证时间点一致性。实际用的时候，我们更倾向配合文件系统快照（比如LVM或ZFS）+ oplog增量。先停写（或切到从节点），再执行：
mongodump --host rs0/192.168.1.10:27017 --out /backup/mongo_20240520 --oplog恢复时用mongorestore加--oplogReplay参数，能把快照之后的操作也补上。注意：oplog必须在dump期间没被覆盖，所以oplogSize建议调到至少24小时容量。
Redis：RDB和AOF不是二选一，是搭配用
单用RDB会丢最近几秒数据；单开AOF又怕文件太大拖慢性能。我们线上习惯这样配：
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec每天凌晨自动bgsave一次RDB，同时AOF每秒刷盘。万一挂了，优先用最新RDB启动，再重放AOF末尾未同步的部分。崩溃后手动修复AOF只需一条命令：redis-check-aof --fix appendonly.aof。
Cassandra：nodetool snapshot才是真·快照
别手动生成data目录tar包！Cassandra自带硬链接快照，不占额外空间、秒级完成。登录任一节点执行：
nodetool snapshot -t backup_20240520 mykeyspace快照存在/var/lib/cassandra/data/mykeyspace/*/snapshots/backup_20240520下。恢复时停掉对应节点，清空该表data目录，把snapshot里文件拷进去，再运行nodetool refresh mykeyspace mytable就行。多节点集群记得逐台操作，别一起重启。
通用提醒：备份≠存本地硬盘
见过太多人把mongodump输出直接扔在Mongo服务器/home/backups下，结果磁盘坏了连备份一起没了。我们默认规则：备份文件生成后立刻rsync -avz /backup/ user@nas:/volume1/backup/nosql/，再加个脚本校验md5。另外，每月挑一个备份，真正跑一遍restore到测试机——光有文件不等于能用。