一、持久化配置

• RBD和AOF建议同时打开（Redis4.0之后支持）

• RDB做冷备，AOF做数据恢复（数据更可靠）

• RDB采取默认配置即可，AOF推荐采取everysec每秒策略

AOF和RDB还不懂的，请转移到如下几篇：

看完这篇还不懂Redis的RDB持久化，你们来打我！

天天在用Redis，那你对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进程。

• 完美收官。

END

精彩推荐

一百期Java面试题汇总

SpringBoot内容聚合

IntelliJ IDEA内容聚合

Mybatis内容聚合

我知道你 “在看”