企業生產環境中的數據備份和各種災難下的數據恢復，到底是怎麼做得呢？
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即可。