如果我当前正在使用 dump.rdb 快照，如何切换到 AOF？
在 2.0 版和更高版本中执行此操作的过程有所不同，您可以猜到自 Redis 2.2 以来它更简单，并且根本不需要重新启动。
Redis >= 2.2
第一个 CONFIG 命令启用 Append Only File 持久性。
第二个 CONFIG 命令用于关闭快照持久性。这是可选的，如果您希望可以启用两种持久性方法。
**重要提示：**记得编辑你的 redis.conf 以打开 AOF，否则当你重新启动服务器时，配置更改将丢失，服务器将以旧配置重新启动。
雷迪斯 2.0
备份最新的 dump.rdb 文件。
将此备份转移到安全的地方。
停止对数据库的所有写入！
发出一个redis-cli BGREWRITEAOF. 这将创建仅附加文件。
当 Redis 完成生成 AOF 转储时停止服务器。
编辑 redis.conf 结束启用仅附加文件持久性。
重新启动服务器。
确保您的数据库包含与切换前相同数量的键。
确保将写入正确附加到仅附加文件。
AOF 和 RDB 持久化之间的交互
Redis >= 2.4 确保避免在 RDB 快照操作已经在进行时触发 AOF 重写，或者允许一段 BGSAVE 时间 AOF 重写正在进行。这可以防止两个 Redis 后台进程同时进行繁重的磁盘 I/O。
当快照正在进行中并且用户使用服务器明确请求日志重写操作 BGREWRITEAOF 时，服务器将回复一个 OK 状态代码，告诉用户该操作已安排好，一旦快照完成，重写将开始。
在启用 AOF 和 RDB 持久性的情况下，Redis 重新启动 AOF 文件将用于重建原始数据集，因为它保证是最完整的。
备份 Redis 数据
在开始本节之前，请务必阅读以下句子：确保备份您的数据库。磁盘损坏，云中的实例消失等等：没有备份意味着数据消失到 /dev/null 的巨大风险。
Redis 对数据备份非常友好，因为您可以在数据库运行时复制 RDB 文件：RDB 一旦生成就永远不会修改，并且在生成时它使用临时名称并仅使用 rename(2) 以原子方式重命名为其最终目标当新快照完成时。
这意味着在服务器运行时复制 RDB 文件是完全安全的。这是我们的建议：
在您的服务器中创建一个 cron 作业，在一个目录中创建 RDB 文件的每小时快照，并在不同目录中创建每日快照。
每次运行 cron 脚本时，请确保调用find命令以确保删除太旧的快照：例如，您可以拍摄最近 48 小时的每小时快照，以及一两个月的每日快照。确保使用日期和时间信息命名快照。
每天至少一次确保将 RDB 快照传输到您的数据中心之外，或者至少传输到运行您的 Redis 实例的物理机之外。
备份 AOF 持久性
如果您运行仅启用 AOF 持久性的 Redis 实例，您仍然可以执行备份。appenddirname从 Redis 7.0.0 开始，AOF 文件被拆分为多个文件，这些文件驻留在由配置确定的单个目录中。在正常操作期间，您只需复制/压缩此目录中的文件即可实现备份。但是，如果这是在 rewrite 期间完成的，您最终可能会得到一个无效的备份。要解决此问题，您必须在备份期间禁用 AOF 重写：
使用 确保在此期间 不手动启动重写（使用）关闭自动重写。 CONFIG SET auto-aof-rewrite-percentage 0 BGREWRITEAOF
检查当前没有正在进行的重写，使用 验证为 0。如果为 1，则您需要等待重写完成。 INFO persistence aof_rewrite_in_progress
现在您可以安全地复制目录中的appenddirname文件。
完成后重新启用重写： CONFIG SET auto-aof-rewrite-percentage <prev-value>
**注意：**如果您想最大限度地减少禁用 AOF 重写的时间，您可以创建指向文件的硬链接appenddirname（在上面的步骤 3 中），然后在创建硬链接后重新启用重写（步骤 4）。现在您可以复制/tar 硬链接并在完成后将其删除。这是有效的，因为 Redis 保证它只附加到该目录中的文件，或者在必要时完全替换它们，因此内容在任何给定时间点都应该是一致的。
**注意：**如果您想处理在备份期间重新启动服务器的情况，并确保在重新启动后不会自动开始重写，您可以更改上面的步骤 1 以也通过 CONFIG REWRITE. 只需确保在完成后重新启用自动重写（第 4 步）并将其与另一个 CONFIG REWRITE.
在 7.0.0 版本之前，备份 AOF 文件可以简单地通过复制 aof 文件来完成（就像备份 RDB 快照一样）。该文件可能缺少最后一部分，但 Redis 仍然可以加载它（请参阅前面关于 截断 AOF 文件 的部分）。
使用 确保在此期间 不手动启动重写（使用）关闭自动重写。 CONFIG SET auto-aof-rewrite-percentage 0 BGREWRITEAOF
检查当前没有正在进行的重写，使用 验证为 0。如果为 1，则您需要等待重写完成。 INFO persistence aof_rewrite_in_progress
现在您可以安全地复制目录中的appenddirname文件。
完成后重新启用重写： CONFIG SET auto-aof-rewrite-percentage <prev-value>
**注意：**如果您想最大限度地减少禁用 AOF 重写的时间，您可以创建指向文件的硬链接appenddirname（在上面的步骤 3 中），然后在创建硬链接后重新启用重写（步骤 4）。现在您可以复制/tar 硬链接并在完成后将其删除。这是有效的，因为 Redis 保证它只附加到该目录中的文件，或者在必要时完全替换它们，因此内容在任何给定时间点都应该是一致的。
**注意：**如果您想处理在备份期间重新启动服务器的情况，并确保在重新启动后不会自动开始重写，您可以更改上面的步骤 1 以也通过 CONFIG REWRITE. 只需确保在完成后重新启用自动重写（第 4 步）并将其与另一个 CONFIG REWRITE.
在 7.0.0 版本之前，备份 AOF 文件可以简单地通过复制 aof 文件来完成（就像备份 RDB 快照一样）。该文件可能缺少最后一部分，但 Redis 仍然可以加载它（请参阅前面关于 截断 AOF 文件 的部分）。
灾难恢复
Redis 环境中的灾难恢复与备份基本相同，并且能够在许多不同的外部数据中心传输这些备份。即使在某些灾难性事件影响 Redis 正在运行并生成其快照的主数据中心的情况下，这种方式也可以保护数据。
我们将回顾成本不高的最有趣的灾难恢复技术。
Amazon S3 和其他类似服务是实施灾难恢复系统的好方法。只需以加密形式将您的每日或每小时 RDB 快照传输到 S3。您可以使用gpg -c（在对称加密模式下）加密您的数据。确保将您的密码存储在许多不同的安全位置（例如，将副本提供给组织中最重要的人）。建议使用多个存储服务以提高数据安全性。
使用 SCP（SSH 的一部分）将您的快照传输到远程服务器。这是一个相当简单和安全的方法：在离你很远的地方找一个小型 VPS，在那里安装 ssh，并生成一个没有密码的 ssh 客户端密钥，然后将其添加到authorized_keys你的小型 VPS 的文件中。您已准备好以自动方式传输备份。在两个不同的提供商中获得至少两个 VPS 以获得最佳效果。
重要的是要理解，如果没有以正确的方式实施，这个系统很容易失败。至少，绝对确保在传输完成后您能够验证文件大小（应该与您复制的文件匹配）以及可能的 SHA1 摘要，如果您使用的是 VPS。
如果新备份的传输由于某种原因无法正常工作，您还需要某种独立的警报系统。
529