大忙人系列_企业级数据备份方案（Redis）

素雪风华

已于 2022-04-29 21:57:02 修改

阅读量801

点赞数

于 2020-05-22 11:16:49 首次发布

本文链接：https://blog.csdn.net/ultingcsdn/article/details/105366468

版权

运维专栏收录该内容

4 篇文章 0 订阅

订阅专栏

写在开始

本文总结于石杉老师的“亿级流量电商详情页系统实战”.

处理方案

写crontab定时调度脚本去做数据备份
每小时copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份
每天都保留一份当日的rdb的备份，到一个目录中去，仅仅保留最近1个月备份
每次copy备份的时候，都把太旧的备份给删了
每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去

备份脚本

### 每小时copy一份，删除48小时前的数据
文件名：redis_rdb_copy_hourly.sh
文件内容：
    #!/bin/sh 
    # 如果使用：date +%Y%m%d%k，时间格式可能要出问题“20190715 0”中间0显示不出来
    # 这儿最好用：date +%y%m%d%H，显示的时间格式为“2019071500”
    cur_date=`date +%Y%m%d%H`
    # snapshotting自己创建的目录
    rm -rf /apps/redis/snapshotting/$cur_date
    mkdir /apps/redis/snapshotting/$cur_date
    cp /apps/redis/data/dump.rdb /apps/redis/snapshotting/$cur_date
    
    # 删除48小时以前的数据
    del_date=`date -d -48hour +%Y%m%d%H`
    rm -rf /apps/redis/snapshotting/$del_date
设置权限：chmod 777 redis_rdb_copy_hourly.sh
设置cron：crontab -e
# 第一个*：每小时
# 第二个*：每天
# 第三个*：每月 
# 第四个*：每周
设置cron定时每小时执行上面的脚本：0 * * * * sh /apps/redis/redis_rdb_copy_hourly.sh

每天拷贝，并且删除一个月前的

### 每天拷贝，并且删除一个月前的
文件名称：redis_rdb_copy_daily.sh
文件内容：
    #!/bin/sh 
    cur_date=`date +%Y%m%d`
    rm -rf /apps/redis/snapshotting/$cur_date
    mkdir /apps/redis/snapshotting/$cur_date
    cp /apps/redis/data/dump.rdb /apps/redis/snapshotting/$cur_date
    #删除一个月前的
    del_date=`date -d -1month +%Y%m%d`
    rm -rf /apps/redis/snapshotting/$del_date
设置权限：chmod 777 redis_rdb_copy_hourly.sh
设置cron：crontab -e
设置cron定时每天执行上面的脚本：0 0 * * * sh /apps/redis/redis_rdb_copy_daily.sh

数据恢复方案

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

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

AOF没有破损，也是可以直接基于AOF恢复的

AOF append-only，顺序写入，如果AOF文件破损，那么用redis-check-aof fix

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

此时一般是人为，并非机器故障（找到最新的一份RDB最新的一份备份，小时级的备份就可以了...此时只能恢复到一小时）

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

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

容灾演练

依旧会丢失的做法（无法同步RDB和AOF数据）：    
    appendonly.aof + dump.rdb，优先用appendonly.aof去恢复数据，但是我们发现redis自动生成的appendonly.aof是没有数据的
    然后我们自己的dump.rdb是有数据的，但是明显没用我们的数据
    redis启动的时候，自动重新基于内存的数据，生成了一份最新的rdb快照，直接用空的数据，覆盖掉了我们有数据的，拷贝过去的那份dump.rdb
    你停止redis之后，其实应该先删除appendonly.aof，然后将我们的dump.rdb拷贝过去，然后再重启redis
    很简单，就是虽然你删除了appendonly.aof，但是因为打开了aof持久化，redis就一定会优先基于aof去恢复，即使文件不在，那就创建一个新的空的aof文件
    停止redis，暂时在配置中关闭aof，然后拷贝一份rdb过来，再重启redis，数据能不能恢复过来，可以恢复过来
    脑子一热，再关掉redis，手动修改配置文件，打开aof，再重启redis，数据又没了，空的aof文件，所有数据又没了
    在数据安全丢失的情况下，基于rdb冷备，如何完美的恢复数据，同时还保持aof和rdb的双开

最正确的做法（会同步RDB和AOF）：
    停止redis，关闭aof，拷贝rdb备份，重启redis，确认数据恢复，直接在命令行热修改redis配置，打开aof，这个redis就会将内存中的数据对应的日志，写入aof文件中
    此时aof和rdb两份数据文件的数据就同步了
    
    在redis-cli界面里面操作
        查看appendonly状态：config get appendonly
        热修改appendonly状态：config set appendonly yes
    热修改配置参数，可能配置文件中的实际的参数没有被持久化的修改，再次停止redis，手动修改配置文件，打开aof的命令，再次重启redis