vlambda博客
学习文章列表

Redis企业级数据备份与恢复方案

一、持久化配置

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

  • RDB做冷备,AOF做数据恢复(数据更可靠)

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

AOF和RDB还不懂的,请转移到如下几篇:



二、数据备份方案

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

精彩推荐

我知道你 “在看