Redis 集群备份策略如何配置 cron 定时任务脚本

Redis 集群备份通常通过在每台节点服务器上配置 cron 任务，分别触发单节点的 BGSAVE 命令或复制 RDB 文件实现。该方案适合常规灾难恢复场景，主要风险在于多节点同时 fork 可能导致集群短暂延迟，且无法保证跨分片的全局数据一致性。

先说结论：Redis 集群没有全局备份命令，必须针对每个分片节点独立配置定时任务，建议错开执行时间以避免资源争抢。

适合：需要定期保留数据快照用于灾难恢复或归档的 Redis 集群环境
先准备：确认磁盘空间充足，规划各节点备份时间窗口，编写具备错误处理的 Shell 脚本
验收：检查 cron 日志确认任务执行状态，验证备份文件完整性及可恢复性

命令速用版

以下脚本示例展示了登录本地 Redis 实例触发 BGSAVE 并将 RDB 文件复制到备份目录的过程，需根据实际路径调整。

#!/bin/bash
# redis_backup.sh
REDIS_CLI="/usr/bin/redis-cli"
REDIS_HOST="127.0.0.1"
REDIS_PORT="6379"
REDIS_PASSWORD="your_password"
BACKUP_DIR="/data/backup/redis"
DATE=$(date +%Y%m%d_%H%M%S)

# 触发保存
$REDIS_CLI -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASSWORD BGSAVE

# 等待片刻让文件生成，实际生产建议检查 lastsave 时间戳
sleep 10

# 复制 RDB 文件，路径需根据 redis.conf 中的 dir 和 dbfilename 确认
cp /data/dump.rdb $BACKUP_DIR/dump_$DATE.rdb

# 删除 7 天前的旧备份
find $BACKUP_DIR -name "dump_*.rdb" -mtime +7 -delete

Cron 配置示例（每天凌晨 2 点执行）：

0 2 * * * /path/to/redis_backup.sh >> /var/log/redis_backup.log 2>&1

为什么会这样

Redis 集群采用分片架构，数据分散存储在不同节点上，原生不支持跨所有分片的全局原子备份。

每个节点独立管理自己的 RDB 或 AOF 文件，因此备份策略必须落实到单个操作系统实例。如果在同一时刻对所有节点触发 BGSAVE，会导致所有节点同时执行 fork 操作，可能引起 CPU 瞬时飙升和集群响应延迟。公开资料中没有看到可靠的量化数据说明具体延迟时长，但运维经验表明错开时间能显著降低风险。

分步处理

步骤 1：编写备份脚本

创建 Shell 脚本，包含连接认证、触发保存、文件复制和旧文件清理逻辑。脚本中必须处理 Redis 认证密码，避免明文暴露在进程列表，建议使用环境变量或配置文件读取。

步骤 2：配置 Cron 任务

在每台 Redis 节点服务器上执行 crontab -e，添加定时规则。确保各节点的执行时间错开，例如节点 1 在 02:00，节点 2 在 02:05，节点 3 在 02:10。

步骤 3：设置文件权限

确保脚本具有执行权限 chmod +x redis_backup.sh，且运行 cron 的用户对 Redis 数据目录和备份目录有读写权限。

怎么验证是否生效

常见坑

磁盘空间不足：备份文件会占用额外空间，未清理旧文件可能导致磁盘写满，引发 Redis 阻塞。
主节点压力：建议优先从从节点（Slave）进行备份，避免 BGSAVE 影响主节点写入性能。
一致性风险：不同节点备份时间不同步，恢复时可能存在跨分片数据不一致，关键业务需配合应用层逻辑或停写备份。

常见问题

Redis 集群备份能保证数据强一致性吗？

不能保证全局强一致性。因为各分片独立备份，不同节点快照时间点存在差异，恢复后可能丢失部分跨槽事务。

应该备份 RDB 还是 AOF 文件？

建议优先备份 RDB 文件用于冷备，文件紧凑且恢复快；AOF 文件较大且重写频繁，适合作为补充或近实时备份。

Cron 任务执行失败怎么排查？

检查脚本是否有执行权限，确认 Redis 密码是否正确，查看系统邮件或重定向的日志文件获取错误信息。

参考来源

Redis Official Documentation, Persistence, https://redis.io/docs/management/persistence/