Redis提供了多種不同級別的持久化方式:
- RDB 持久化可以在指定的時間間隔內產生資料集的時間點快照（point-in-time snapshot）
- AOF持久化記錄伺服器執行的所有寫操作命令，並在伺服器啟動時，通過重新執行這些命令來還原資料集。AOF檔案中的命令全部以Redis協議的格式來儲存，新命令會被追加到檔案的末尾.Redis還可以在後臺對AOF檔案進行重寫(rewrite)，使得AOF檔案的體積不會超過儲存資料集狀態所需的實際大小。
- Redis還可以同時使用AOF和RDB持久化。在這種情況下，當Redis重啟時，它會優先使用AOF檔案來還原資料集，因為AOF檔案儲存的資料集通常比RDB檔案所儲存的資料集更完整。
- 可以關閉持久化功能，讓資料只在伺服器執行時存在。
RDB的優點
- RDB是一個很緊湊的檔案，它儲存了redis在某個時間點上的資料集。
- RDB非常適用於災難恢復，它只有一個檔案，並且內容緊湊，可以將它傳送到別的資料中心
- 可以最大化redis的效能；父程式在儲存RDB檔案時，唯一要做的就是fork一個子程式，然後這個子程式就會處理接下來的所有儲存工作，父程式無需執行任何磁碟I/O操作
- RDB在恢復大資料集的時候比AOF的速度要快
RDB的缺點
- 因為RDB是儲存在某個時間點上的資料集，這樣的話，伺服器故障可能會丟失資料。
- 每次儲存RDB的時候，redis要fork一個子程式，並由子程式來進行實際的持久化工作，在資料集比較大的時候，fork可能會非常耗時，可能會造成伺服器停止處理客戶端請求；如果資料集非常巨大，並且cpu比較緊張的話，那麼 這種停止時間設定可能會長達整整1秒。雖然AOF重寫也需要進行fork，但無論AOF重寫的執行間隔有多長，資料的耐久性都不會有任何損失
AOF優點
- 使用AOF持久化會讓redis變得非常耐久，你可以設定不同的fsync策略，比如無fsync，每秒鐘一次fsync，或者每次寫入命令是fsync。AOF的預設策略為每秒鐘fsync一次，在這種配置下，redis仍然可以保持良好的效能，並且就算髮生故障停機，也最多隻會丟失一秒鐘的資料
- AOF檔案只是一個日誌檔案追加操作（append only log），因此對AOF檔案的寫入不需要進行seek，即使日誌因為某些原因而包含了未寫入完整命令（比如寫入時， 磁碟滿了，寫入時中途停機等），redis-check-aof工具可以輕易的修復這種問題
- redis可以在AOF檔案體積過大時，自動在後臺對AOF進行重寫，重寫後的AOF檔案包含了恢復當前資料集所需的最小命令集合。這個重寫操作是絕對安全的，因為redis在建立新的AOF過程中，會繼續講命令追加到現有的AOF檔案裡面，即使重寫過程中發生停機，現有的AOF檔案也不會丟失，而一旦新AOF檔案建立完畢，redis就會從舊檔案切換到新AOF檔案，並開始對新AOF檔案進行追加操作
- AOF檔案有序地儲存了對資料庫執行的所有寫入操作，這些寫入操作以redis協議的格式儲存，因此AOF檔案的內容非常容易被人讀懂，對檔案進行分析也很容易。到處AOF檔案也非常簡單。
AOF缺點
- 對於相同的資料來說，AOF檔案的體積通常要大於RDB檔案的體積
- 根據所使用的fsync策略。AOF的速度可能會慢於RDB。
- AOF的bug，曾經因為個別命令的原因，導致AOF檔案在重新載入是，無法將資料集恢復成儲存時的樣子。