一、持久化配置
-
RBD和AOF建议同时打开（Redis4.0之后支持）
-
RDB做冷备，AOF做数据恢复（数据更可靠）
-
RDB采取默认配置即可，AOF推荐采取everysec每秒策略
AOF和RDB还不懂的，请转移到如下几篇：
详解Redis的RDB持久化方式
详解Redis的AOF持久化方式
二、数据备份方案
1、需求
我们需要定时备份rdb文件来做冷备，为什么？不是有aof和rbd了吗为什么还要单独写定时任务去备份？因为Redis的aof和rdb是仅仅有一个最新的，比如谁手贱再Redis宕机的时候执行rm -rf aof/rdb了，那不就GG了吗？或者rdb/aof文件损坏了等不可预期的情况。所以我们需要单独备份rdb文件以防万一。
为什么不定时备份aof而是rdb？定时备份aof没意义呀，定时本身就是冷备份，不是实时的，rdb文件又小恢复又快，她哪里不香？
2、方案
-
写crontab定时调度脚本去做数据备份。
-
每小时都copy一份redis的rdb文件到一个其他目录中，这个目录里的rdb文件仅仅保留48小时内的。也就是每小时都做备份，保留2天内的rdb，只保留48个rdb。
-
每天0点0分copy一份redis的rdb文件到一个其他目录中，这个保留一个月的。也就是按天备份。
-
每天半夜找个时间将当前服务上的所有rdb备份都上传到云服务上。
3、实现
3.1、按小时
每小时copy一次备份，删除48小时前的数据。
crontab -e
# 每小时都执行/usr/local/redis/copy/redis_rdb_copy_hourly.sh脚本
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh
# redis_rdb_copy_hourly.sh脚本的内容如下：
#!/bin/sh
# +%Y%m%d%k == 年月日时
cur_date=`date +%Y%m%d%k`
rm -rf /usr/local/redis/rdb/$cur_date
mkdir /usr/local/redis/rdb/$cur_date
# 拷贝rdb到目录
cp /var/redis/6379/dump.rdb /usr/local/redis/rdb/$cur_date
# date -d -48hour +%Y%m%d%k == 48小时前的日期，比如今天2020060214，这个结果就是2020053114
del_date=`date -d -48hour +%Y%m%d%k`
# 删除48小时之前的目录
rm -rf /usr/local/redis/rdb/$del_date
3.2、按天
每天copy一次备份，删除一个月前的数据。
crontab -e
# 每天0点0分开始执行/usr/local/redis/copy/redis_rdb_copy_daily.sh脚本
0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh
# redis_rdb_copy_daily.sh脚本的内容如下：
#!/bin/sh
# 年月日
cur_date=`date +%Y%m%d`
rm -rf /usr/local/redis/rdb/$cur_date
mkdir /usr/local/redis/rdb/$cur_date
# 拷贝rdb到目录
cp /var/redis/6379/dump.rdb /usr/local/redis/rdb/$cur_date
# 获取一个月前的时间，比如今天是20200602，那么del_date就是20200502
del_date=`date -d -1month +%Y%m%d`
# 删除一个月前的数据
rm -rf /usr/local/redis/rdb/$del_date
3.3、传到云
没法演示，最终目的就是磁盘备份完上传到云，云保留多少天等策略自己看需求。
三、数据恢复方案
1、redis挂了
如果仅仅是redis进程挂了，那么直接重启redis进程即可，Redis会按照持久化配置直接基于持久化文件进行恢复数据。
如果有AOF则按照AOF，AOF和RDB一起开的话也走AOF。
2、持久化文件丢了
如果持久化文件（rdb/aof）损坏了，或者直接丢失了。那么就要采取我们上面所做的rdb备份来进行恢复了。
不要脑子一热想着很简单，就以为直接把rdb拖过来重启redis进程就完事了，这种想法有很多问题。慢慢道来。
2.1、问题
问题一：直接把备份的rdb扔到redis持久化目录下然后重启redis不行的原因在于：redis是按照先aof后rdb进行恢复的，所以都是开启aof的，redis启动后会重新生成新的aof文件，里面是空的。所以不会进行任何数据恢复，也就是说虽然你把rdb丢给redis了，但是redis会按照aof来恢复，而aof是redis启动的时候新生成的空文件，所以不会有任何数据进行恢复。
问题二：那么我们把rdb文件丢给redis后，先将redis的aof关闭再启动redis进程不就能按照rdb来进行恢复了吗？是这样的，没毛病！但是新的问题来了，我们aof肯定要开的，aof对数据保障更可靠。那什么我们按照rdb文件恢复完后再修改redis配置文件开启aof然后重启redis进程不就得了嘛？大哥…你打开aof然后重启redis，这时候redis又会生成一个空的aof文件，这时候恢复的时候又是啥数据都没了。
因为数据是存到内存里，你重启后肯定没了，需要持久化文件来恢复。这时候aof是空的，我恢复个鸡毛啊。
2.2、具体方案
可能有人想到方案了，但是耐心看完，看看我的文采如何。
我不管你是持久化文件丢了还是坏了，我都先rm -rf * 给他删了。
-
停止redis进程
-
删除坏掉的rdb和aof持久化文件。
-
修改配置文件关闭redis的aof持久化。
-
找到最新备份的rdb文件扔到redis的持久化目录里。（这里最新的肯定是按照小时备份的最后一个）
-
启动Redis进程
-
执行
set appendonly yes动态打开aof持久化。
也就是说打开aof的操作不是修改配置文件然后重启，而是先热修改让他生成aof，这次生成肯定是会带着内存中完整的数据的。然后再修改配置文件重启。
-
等aof文件生成后再修改redis配置文件打开aof。
-
重启redis进程。
-
完美收官。