Redis数据恢复那些事儿，手把手教你从零开始重建数据过程

综合自Redis官方文档、社区运维经验分享以及常见数据库恢复实践）

想象一下，你正喝着咖啡，悠闲地看着系统运行报表，突然收到报警：Redis服务挂了，而且重启失败，数据可能丢了！这时候千万别慌，深呼吸，我们一步步来把数据救回来，这篇文章就是你的救命稻草，咱们不讲那些难懂的专业术语,就用大白话聊聊怎么从零开始把Redis的数据重建起来。

第一步：先别乱动，搞清楚发生了什么

数据恢复最忌讳的就是慌乱中一通瞎操作，把本来能恢复的数据给覆盖了，第一件事是“保护现场”。

1. 立刻停止写入：如果Redis实例还在运行但响应异常，第一时间通过客户端执行 redis-cli CONFIG SET appendonly no 命令关闭AOF持久化（如果开启着），防止新的写操作继续写入可能已经损坏的持久化文件，加重问题，如果可能,让应用端也暂停对Redis的写入。
2. 备份残存文件：找到你的Redis数据目录（可以在还在运行的Redis中用 CONFIG GET dir 命令查看，或者查看配置文件里的 dir 项），把目录下所有文件（dump.rdb, appendonly.aof 等）立刻复制一份到安全的地方，这是你的“原始证据”，哪怕文件是坏的,也多一分希望。

第二步：检查你的“救命稻草”——持久化文件

Redis的数据恢复，全靠它平时有没有“写日记”的习惯，这“日记”主要有两种形式：RDB快照和AOF日志,你得先看看你手头有哪种。

• RDB文件（默认方式）：这就像是你给数据拍了一张完整的照片，文件名通常是 dump.rdb，它的特点是文件小，恢复速度快,但可能会丢失最后一次快照之后的所有数据。
• AOF文件：这就像是记录了你对数据做的每一个操作的流水账，文件名通常是 appendonly.aof，它的优点是数据完整性高，最多损失一秒的数据（取决于配置），但文件通常比较大,恢复起来慢。

怎么判断用哪个恢复？

• 理想情况：你既有最新的RDB快照，又有完整的AOF日志，这时候优先使用AOF恢复,因为它数据更全。
• 常见情况：只有RDB文件，那就用它，虽然会丢点数据,但总比全没了强。
• 最坏情况：两个文件都损坏或丢失，那可能就需要从业务系统的原始数据库（比如MySQL）重新导入数据了,这超出了Redis恢复的范畴。

第三步：手把手恢复操作

现在我们假设你有一个备份的RDB文件（dump.bak.rdb）可以用来恢复。

1. 准备新环境：为了安全起见，最好在一个新的、干净的服务器上操作,或者至少确保原Redis服务已彻底停止。
2. 放置备份文件：
   • 找到新Redis实例的数据目录（同样通过配置文件查看）。
   • 确保Redis服务是停止状态。
   • 把你备份好的 dump.bak.rdb 文件复制到这个数据目录下，并重命名为Redis默认加载的文件名（通常是 dump.rdb）。注意：这一步会覆盖该目录下原有的任何 dump.rdb 文件。
3. 检查配置文件：打开Redis的配置文件 redis.conf，确认以下几点：
   • dbfilename dump.rdb：确保这个配置的名字和你刚放进去的文件名一致。
   • dir /path/to/your/data：确保这个路径就是你放RDB文件的正确路径。
   • 如果之前关闭了AOF，现在可以先保持关闭（appendonly no）,让恢复过程更简单纯粹。
4. 启动Redis：使用命令启动Redis服务，redis-server /path/to/redis.conf。
5. 验证数据：用 redis-cli 连接上Redis，执行 INFO keyspace 命令，看看是否有键空间显示，或者用 KEYS *（生产环境慎用）或者 DBSIZE 命令看看数据量是否大致符合预期，抽查几个关键的业务数据,确认其值是否正确。

如果用的是AOF文件恢复呢？ 过程类似,但更简单：

1. 停止Redis服务。
2. 将备份的AOF文件（如 appendonly.aof.bak）放入数据目录，并重命名为 appendonly.aof。
3. 在配置文件中确保 appendonly yes 是开启的。
4. 启动Redis，Redis在启动时会自动读取AOF文件并重新执行所有命令来重建内存数据，这个过程可能会比较慢,取决于AOF文件的大小。

第四步：重建之后与预防未来

数据恢复成功，值得庆贺！但事儿还没完。

1. 数据回源：如果你的Redis只是缓存，数据在主数据库（如MySQL）里有完整备份，那么恢复Redis后，应用在读取缓存失败时，会自动回源到主数据库去取数据并重新填充缓存，这是一个更常见、更自动化的“重建”过程。
2. 亡羊补牢：赶紧检查你的持久化策略！
   • RDB配置：save 900 1 表示900秒内至少有1个key变化就保存一次快照，根据业务对数据丢失的容忍度调整频率，频率越高，数据越安全,但性能影响也越大。
   • AOF配置：appendfsync everysec 是推荐配置，在性能和安全性之间取得平衡，它每秒同步一次,最多丢失一秒数据。
   • 混合持久化：Redis 4.0以后支持了RDB-AOF混合持久化（在AOF重写时，先以RDB格式写入全量数据，再追加增量AOF日志），结合了两者的优点，恢复时速度快且数据完整，在配置文件中开启 aof-use-rdb-preamble yes 即可。
3. 定期备份：不要把鸡蛋放在一个篮子里，除了依赖Redis自身的持久化，还应定期将RDB或AOF文件备份到其他安全的存储空间，比如另一台服务器、对象存储或者磁带库，可以写个定时任务（cron job）来自动完成。

Redis数据恢复的核心就是：冷静 -> 备份现场 -> 识别持久化文件 -> 在安全环境重建 -> 验证 -> 优化预防，只要平时做好了持久化配置和定期备份，真遇到问题时，你就能有条不紊地应对,把损失降到最低。