redis企业级数据备份方案以及数据恢复

---

redis企业级数据备份方案以及数据恢复

企业级的持久化的配置策略

1. 在企业中，RDB的生成策略，一般用默认的就可以了。如下所示：

save 900 1
save 300 10
save 60 10000
1
2
3

save 60 10000 表示每 60 超过10000 条键值对时则生成 RDB，根据自己的应用和业务的数据量，可改成 save 60 1000 或者其他。

2. AOF 一定要打开，fsync 设置成 everysec 即可。如下所示：

appendfsync everysec
1

3. 设置 AOF 重写策略，如下所示：

auto-aof-rewrite-percentage 100 # 当前AOF大小膨胀到超过上次100%，上次的两倍
auto-aof-rewrite-min-size 64mb # 要求达到的最小数据量
1
2

企业级的数据备份方案

RDB 非常适合做冷备，每次生成之后，就不会再有修改了。

数据备份方案

1. 每小时都 copy 一份 rdb 的备份，到一个目录中去，仅仅保留最近 48 小时的备份。
2. 每天都保留一份当日的 rdb 的备份，到一个目录中去，仅仅保留最近 1 个月的备份。
3. 每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去。

每次 copy 备份的时候，都把旧的备份删除。

数据备份方案的实现

以每小时 copy 一次备份，删除 48 小时前的数据为例：

1. 在 /usr/local/redis/copy 目录下，创建每小时备份脚本 redis_rdb_copy_hourly.sh，内容如下所示：

#!/bin/sh 

cur_date=`date +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date

del_date=`date -d -48hour +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$del_date
1
2
3
4
5
6
7
8
9

/usr/local/redis/snapshotting/$cur_date 为备份 RDB 的存储路径。

crontab -e 创建定时任务，任务内容如下所示：

0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh
1

数据恢复方案

场景1：如果是 redis 进程挂掉，那么重启 redis 进程即可，直接基于 AOF 日志文件恢复数据。

场景2： 如果是 redis 进程所在机器挂掉，那么重启机器后，尝试重启 redis 进程，尝试直接基于 AOF 日志文件进行数据恢复。

• AOF 文件没有损坏，也是可以直接基于AOF 恢复的；
• AOF 文件损坏，那么用 redis-check-aof fix 检查。

场景3：如果 redis 当前最新的 AOF 和 RDB 文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的 RDB 数据副本进行数据恢复。

当前最新的 AOF 和 RDB 文件都出现了丢失/损坏到无法恢复，一般不是机器的故障，而是人为。可通过删除 AOF 文件和 RDB 文件模拟此场景。

踩坑一：将备份 dump.rdb 文件 copy 到 生成路径下，然后重启 redis，发现 redis 自动生成的appendonly.aof 是没有数据，dump.rdb 被覆盖。

打开了 aof 持久化，redis 就一定会优先基于 aof 去恢复，即使文件不在，那也会创建一个新的空的 aof 文件，导致内存中的数据也为空。

redis 启动的时候，自动重新基于内存的数据，生成了一份最新的 rdb 快照，直接用空的数据，覆盖掉了拷贝过去的那份 dump.rdb。

踩坑二：停止 redis，暂时在配置中关闭 aof，然后拷贝一份 rdb 过来，再重启 redis，数据能恢复过来；之后，再关掉 redis，手动修改配置文件，打开 aof，再重启 redis，数据又没了。

疑问：如何完美的恢复数据？

停止 redis，关闭 aof，拷贝 rdb 备份，重启 redis，确认数据恢复。之后，直接在命令行热修改 redis 配置，打开 aof，redis 就会将内存中的数据写入 aof 文件中，此时 aof 和 rdb 两份数据文件的数据就同步了。

config set 热修改配置参数，配置文件中的实际的参数并没有被持久化的修改，需要再次停止 redis，手动修改配置文件，打开 aof 的命令，再次重启 redis。

场景4：如果当前机器上的所有 RDB 文件全部损坏，那么从远程的云服务上拉取最新的 RDB 快照回来恢复数据。

场景5：如果是发现有重大的数据错误，比如某个小时上线的程序一下子将数据全部污染了，数据全错了，那么可以选择某个更早的时间点，对数据进行恢复。