Redis 重启后数据丢失怎么办？RDB、AOF、挂载目录与恢复证据清单-煜钧云

直接答案：Redis 重启后数据变空，先限制应用继续写入并保存启动日志、INFO persistence、CONFIG GET dir dbfilename appendonly appenddirname、实例 ID 与挂载信息。常见原因包括未启用持久化、RDB 最近保存点之后的数据本就未落盘、AOF 关闭或损坏、Redis 以不同用户/目录启动、Docker 没挂 volume、空目录覆盖了原数据路径，或同时启用 RDB/AOF 时实际加载了 AOF。不要立即把找到的旧 dump.rdb 覆盖当前目录；先复制证据并在隔离实例恢复。

本文适用于单机 Redis、systemd 或 Docker 场景。若 Redis 只是可重建缓存，恢复策略与权威数据库不同；若保存会话、队列或唯一业务状态，应按数据事故处理并冻结进一步写入。

本文按 2026 年 9 月可查的官方文档核对。示例命令以只读取证为主；凡涉及删除、覆盖、重启、权限、网络或数据库参数的动作，都应先确认操作对象、备份、维护窗口和带外恢复入口。不同发行版与软件版本的路径可能不同，必须先查询实际配置再改。

先用证据判断故障在哪一层

现象或检查点	它能说明什么	直接证据	不要误判为
persistence均关闭	重启后内存数据不会自动恢复	CONFIG与启动前设计	文件加载失败
RDB存在但时间较旧	最近保存点之后有预期丢失窗口	LASTSAVE、文件mtime与写入时间	RDB一定损坏
appendonly=yes且AOF加载失败	AOF路径、权限或尾部损坏	启动日志、manifest与文件完整性	Redis忽略AOF使用RDB
容器重建后目录为空	未持久挂载或挂错宿主路径	docker inspect Mounts与volume内容	Redis自动清库
加载成功但应用看不到键	连接了不同实例、端口、DB编号或集群	ROLE、run_id、dbsize与连接串	恢复文件无数据

这张表的用法不是“看到一个关键词就改一个参数”，而是把客户端、DNS或边缘、Web 代理、应用、数据层依次分开。至少保留故障时间、完整 URL、状态码、关键响应头、同一时刻的服务日志和一份正常样本。只有时间能够对齐，才能判断两个现象是否属于同一次故障。

六步排查与修复顺序

1. 先阻止新写入覆盖现场

将受影响实例从应用流量中摘除或把应用切到只读/维护模式，保存当前 RDB/AOF、日志和配置副本。不要连续重启；每次启动都可能重写日志、快照或 AOF 文件。

2. 确认连接的是哪一个实例

记录主机、端口、TLS、run_id、role、Redis版本、选择的 DB 和 key 数。容器、哨兵或集群环境可能让应用连接到另一节点；“空库”有时只是查错实例或 DB 编号。

3. 读取持久化配置与启动日志

核对 dir、dbfilename、appendonly、appenddirname、save 规则和最近成功时间。Redis 7 的 AOF 使用多部分文件与 manifest，不能只寻找单一 appendonly.aof。启动日志会说明加载、校验或权限失败。

4. 核对文件、用户和挂载

检查数据目录所有者、权限、磁盘空间和文件时间；Docker 要检查 named volume/bind mount 的真实宿主路径，避免空目录覆盖镜像内数据。不要直接修改 Docker volume 内活动文件。

5. 在隔离实例验证候选备份

复制而非移动候选 RDB/AOF，在与生产兼容的 Redis 版本和独立端口/网络中启动，记录加载日志、DBSIZE、关键键、TTL 和应用抽样。需要修复 AOF 时先对原文件做不可变副本，并理解工具会截断尾部。

6. 恢复生产并重建保护

确认恢复点和丢失窗口后，停止生产实例，替换为验证过的副本并以正确用户/目录启动。应用恢复前检查会话、队列和重复任务；随后配置合适 RDB/AOF、异地备份、磁盘告警和定期恢复演练。

可复制的只读取证命令

以下命令中的域名、服务名、路径和时间范围要替换为自己的真实值。先执行查询命令并保存原始输出；不要把“命令能运行”误当成“业务已恢复”。

text redis-cli INFO server | grep -E 'redis_version|run_id|process_id' redis-cli INFO persistence redis-cli CONFIG GET dir dbfilename appendonly appenddirname save redis-cli INFO keyspace docker inspect --format '{{json .Mounts}}' redis-container

redis-cli INFO server | grep -E 'redis_version|run_id|process_id'：标识当前连接实例与进程
redis-cli INFO persistence：查看RDB/AOF状态、最近保存与加载信息
redis-cli CONFIG GET dir dbfilename appendonly appenddirname save：读取持久化文件位置与策略
redis-cli INFO keyspace：查看各逻辑数据库键数与过期键
docker inspect --format '{{json .Mounts}}' redis-container：容器环境核对数据卷真实映射；替换容器名

如命令输出包含公网 IP、用户名、Cookie、令牌、数据库连接串或客户数据，分享工单前先脱敏。对比时保留时间戳、时区和命令本身，否则后来无法复现同一观察条件。

五个最容易扩大故障的误区

找到dump.rdb就直接覆盖：可能覆盖更新数据、版本不兼容或选错实例，应先隔离恢复验证。
反复重启尝试：可能改写文件和日志，扩大取证困难。
只看RDB不看AOF：两者同时启用时Redis启动通常优先使用更完整的AOF。
容器没有volume仍当持久化：删除或重建容器会丢可写层中的数据。
恢复键数相同就上线：还需抽查TTL、类型、队列/会话语义和应用一致性。

变更、回滚与数据边界

恢复前保留当前数据目录、候选备份和校验值，所有操作先在隔离实例完成。若上线恢复点后发现键、TTL或业务不一致，停止新写入并退回变更前保存的目录/实例；但恢复期间已经产生的新数据需要单独合并或重放，不能通过再次覆盖文件解决。AOF修复工具可能截断数据，必须对原文件保持只读副本。

如果只能先恢复服务、还不能确认根因，应把措施标记为“临时缓解”，例如限流、摘除单节点、切回上一配置或临时绕过一层代理。恢复后仍要在受控环境复现原因，并验证同类故障不会在下一次重启、发布或高峰重新出现。

统一验收清单

[ ] 应用写入已受控且现场文件已复制
[ ] 实例、端口、run_id与DB编号确认
[ ] RDB/AOF配置和实际加载路径一致
[ ] 容器volume或宿主目录映射正确
[ ] 候选备份在隔离实例加载成功
[ ] 关键键、类型、TTL和业务抽样一致
[ ] 丢失窗口与重复任务风险已记录
[ ] 异地备份和定期恢复演练已建立

验收必须同时覆盖机器内部和真实外部路径。首页返回 200 不能证明上传、长连接、登录、数据库写入或移动端都正常；同样，控制台显示“运行中”也不能证明应用已能处理请求。至少选一个正常请求、一个边界请求和一个失败请求，记录预期与实际结果。

常见问题

RDB 会丢多少数据？

取决于 save 规则和最后成功快照时间。崩溃可能丢失最近一段写入，不能用统一分钟数回答。

AOF 一定零丢失吗？

不一定。fsync策略、操作系统和故障类型决定窗口；everysec 通常有小窗口，always代价更高，也不能替代备份。

同时开RDB和AOF会加载哪个？

官方文档说明两者都启用时，重启通常使用更完整的AOF重建。应结合当前版本和启动日志确认。

Docker重建后volume还在为什么空？

可能挂了新卷、错误宿主目录、权限失败或应用连接到不同实例。检查 Mounts、volume名和run_id。

缓存Redis需要持久化吗？

若可从权威源快速重建，可选择不持久化，但必须验证重建时间、雪崩保护和应用降级；会话/队列不应误当普通缓存。

Redis 重启后数据丢失怎么办？RDB、AOF、挂载目录与恢复证据清单