企业生产环境中的数据备份和各种灾难下的数据恢复，到底是怎么做得呢？
1、企业级的持久化的配置策略
在企业中，RDB的生成策略，用默认的也差不多
save 60 10000：一分钟内有一万个key变成，就触发一次RDB快照。如果你希望尽可能确保RDB最多丢1分钟的数据，那么尽量就是每隔1分钟都生成一个快照，低峰期，数据量很少，也没必要
60s 10000--->生成RDB，1000--->RDB，这个根据你自己的应用和业务的数据量，你自己去决定
AOF一定要打开，fsync everysec：每秒从操作系统缓存刷新一次到硬盘
auto-aof-rewrite-percentage 100: 就是当前AOF大小膨胀到超过上次100%，上次的两倍
auto-aof-rewrite-min-size 64mb: 根据你的数据量来定，如果系统中数据量比较少，那么可以设置成16mb，32mb。如果数据量比较大，那么可以设置成128MB
2、企业级的数据备份方案
RDB非常适合做冷备，每次生成之后，就不会再有修改了
数据冷备份方案：
（1）写crontab定时调度脚本去做数据冷备份
（2）每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份，这个还是需要根据各自的系统情况来定，也可以每2-3个小时copy一份RDB数据。
（3）每天都保留一份当日的rdb的备份，到一个目录中去，仅仅保留最近1个月的备份（根据需要来定）
（4）每次copy备份的时候，都把太旧的备份给删了
（5）每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去(可以保证当服务器硬盘损坏时，还可以有备份数据恢复)
使用Linux系统中的 crontab 机制进行数据的定时备份：
crontab机制简介：Linux中的定时器机制，可以通过设置，在固定的时间或者间隔一定的时间来执行特定的命令或者shell脚本
创建备份数据的脚本目录：/usr/local/redis/crontab ，每小时copy一次备份，删除48小时前的数据
crontab -e 编辑定时器crontab的命令
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh
redis_rdb_copy_hourly.sh
脚本内容：
#!/bin/sh
cur_date=`date +%Y%m%d%k` // ``符号是Tab建上面的符号
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 //将当前rdb文件复制到备份目录中
del_date=`date -d -48hour +%Y%m%d%k` //得到48小时之前的时间戳
rm -rf /usr/local/redis/snapshotting/$del_date //删除48小时之前的数据
chomd 777 redis_rdb_copy_hourly.sh 给当前脚本一个777权限
每天copy一次备份
crontab -e
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/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 -1month +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$del_date
每天一次将所有数据上传一次到远程的云服务器上去
3、数据恢复方案
（1）如果是redis进程挂掉，那么重启redis进程即可，如果AOF持久化机制开启，那么redis默认直接基于AOF日志文件恢复数据
（2）如果是redis进程所在机器挂掉，那么重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复AOF没有破损，也是可以直接基于AOF恢复的
AOF append-only，顺序写入，如果AOF文件破损，那么用redis-check-aof fix
（3）如果redis当前最新的AOF和RDB文件出现了丢失/损坏，比如出于人为的原因，失误将/var/redis/6379/dump.rdb文件给删除了。那么可以尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复
找到RDB最新的一份备份，小时级的备份可以了，小时级的肯定是最新的，copy到redis里面去，就可以恢复到某一个小时的数据。
appendonly.aof + dump.rdb，优先用appendonly.aof去恢复数据，但是我们发现redis自动生成的appendonly.aof是没有数据的
然后我们自己的dump.rdb是有数据的，但是明显没用我们的数据。
并且在redis启动的时候，自动重新基于内存的数据，生成了一份最新的rdb快照，直接用空的数据，覆盖掉了我们拷贝过去的那份dump.rdb，导致无论是appendonly.apf、还是dump.rdb快照，都没有数据了。
你停止redis之后，其实应该先将redis.conf中的appendonly yes 改为 no ，然后再删除appendonly.aof，最后将我们的dump.rdb拷贝过去，然后再重启redis，数据就可以恢复了。
很简单，就是虽然你删除了appendonly.aof，但是因为打开了aof持久化，redis就一定会优先基于aof去恢复，即使文件不在，那就创建一个新的空的aof文件。
本来很开心，但是脑子一热，再关掉redis，手动修改配置文件，打开aof，再重启redis，数据又没了，空的aof文件，所有数据又没了！！！
在数据安全丢失的情况下，基于rdb冷备，如何完美的恢复数据，同时还保持aof和rdb的双开：
停止redis，关闭aof，删除aof文件，拷贝rdb备份，重启redis，确认数据恢复，直接在命令行热修改redis配置，打开aof，
命令：config set appendonly yes 这时redis就会将内存中的数据对应的日志，写入aof文件中，此时aof和rdb两份数据文件的数据就同步了。可能配置文件中的实际的参数没有被持久化的修改，再次停止redis，手动修改配置文件，打开aof的命令，再次重启redis即可。