我努力使雙方的備份副本dump.rdb每X時間和appendonly.aof每Y個時間，因此，如果文件被損壞，無論出於何種原因（甚至只是AOF的appendonly.aof文件）我可以從dump.rdb.backup快照中恢復我的數據，然後從我擁有的appendonly.aof.backup的最新副本開始更改其他任何內容。如何備份Redis服務器RDB和AOF文件進行恢復以確保最小的數據丟失？
我備份dump.rdb每5分鐘，和備份appendonly.aof每隔1秒。
1）由於dump.rdb被寫入背景到一個臨時文件，子進程 - 會發生什麼變化，而孩子的過程是創建一個新的圖像時出現的重要變化？我知道AOF文件將繼續追加，無論背景寫入如何，但新的dump.rdb文件是否也包含密鑰更改？
2）如果dump.rdb不包含密鑰更改，是否有某種方法可以找出子進程分叉的確切位置？這樣我就可以跟蹤AOF文件獲得最新信息的時間點。
謝謝！
通常，人們使用RDB或AOF作爲持久性策略。兩者都很貴。每5分鐘運行一次轉儲，並且每秒複製aof文件聽起來非常頻繁。除非Redis實例僅存儲少量數據，否則可能會終止您的盒子的I/O子系統。
現在，關於你的問題：
1）語義的RDB機制
傾倒機構的利用現代操作系統的內核，當克隆/前叉過程中實現的寫入時複製機制。當fork完成後，系統通過複製頁表來創建後臺進程。頁面本身在兩個進程之間共享。如果寫入操作是由Redis進程在頁面上完成的，則操作系統將透明地複製頁面（比Redis實例具有自己的版本，並且後臺處理先前的版本）。後臺進程因此保證了內存結構保持不變（因此一致）。
結果是任何寫入操作開始後，叉不會被轉儲。轉儲是在分岔時拍攝的一致快照。
2）保持追蹤叉點
可以通過運行INFO持續性命令並計算rdb_last_save_time估計叉時間戳 - rdb_last_bgsave_time_sec，但它不是很準確的（第二隻）。
是有點更準確（毫秒），您可以分析Redis的日誌文件中提取下面幾行：
[3813] 11 Apr 10:59:23.132 * Background saving started by pid 3816
你至少需要「通知」日誌級別，看看這些線。
據我所知，沒有辦法將AOF中的特定條目與RDB的分叉操作相關聯（即，它不可能是100％準確的）。