帮助中心产品文档与操作指南

Redis重启后数据没了：RDB与AOF检查

发布时间：2026-11-05

Redis 重启后键变少，先不要连续重启或重新初始化。连错实例、选错逻辑库、加载了另一个目录，也会表现成“数据没了”。本文面向自建 Linux 单机 Redis 7 及以上版本；Cluster、Sentinel 和复制切换需要另查对应拓扑。

发现缺失后，先控制无关写入，保存启动日志和旧存储文件。尤其不要在空数据集上随手执行 SAVE、BGREWRITEAOF 或删除 AOF 文件，这可能覆盖或改变原有恢复依据。

先排除连错实例或数据库

沿用现有的安全管理连接进入 redis-cli，再执行下面三条。需要身份认证时使用已有账号；遇到 NOPERM，由具备诊断权限的管理员处理，不取消认证。

INFO server
INFO replication
INFO keyspace

核对 redis_version、tcp_port、config_file和启动时长。role若不是预期的单机主实例，先查是否连到了其他节点。INFO keyspace会列出有键的逻辑库，不能只因 DB 0 为空就判定全部丢失。

如果应用实际使用 DB 1，可在当前连接检查；库号和键名都要换成自己的实际值：

SELECT 1
DBSIZE
EXISTS app:known-key
TTL app:known-key

SELECT只切换当前连接使用的库。TTL 为 -2 表示键不存在，-1 表示未设置过期时间，非负值是剩余秒数。过期时间不会因 Redis 停机暂停；停机期间已经到期的键，重新加载后消失可以是正常结果。部分键缺失还应结合内存淘汰策略检查。

看运行配置，别只看磁盘上的redis.conf

CONFIG GET dir dbfilename appendonly appenddirname appendfilename appendfsync save
INFO persistence

CONFIG GET返回当前进程生效值。只修改了某份 redis.conf，或者只用 CONFIG SET 临时改过，都不能证明下次启动仍使用同一配置；还要对照启动参数和实际配置文件。这里一次读取多个配置名，需要 Redis 7 或更高版本。

当前配置 重启时需要核对什么
使用RDB快照 查看 dir 与 dbfilename 指向的文件、保存时间和载入日志。最后一次成功快照之后的写入，可能尚未保存。
appendonly为yes 核对 AOF 目录与完整文件组。每秒同步通常仍存在最近约一秒写入的丢失窗口，不能当成零丢失承诺。
AOF关闭，save也为空 没有自动RDB保存规则，也未开启AOF；另外核查是否曾手工保存或有独立备份。

两种持久化同时启用时，重启会使用 AOF 重建数据，不是把旧 RDB 与 AOF 简单合并。Redis 7 起 AOF 可以由基础文件、增量文件和 manifest 清单组成，只寻找或复制单个 appendonly.aof 容易漏文件。也不要为“找回数据”临时切换 appendonly。

在 INFO persistence中检查 rdb_last_bgsave_status、aof_last_write_status和aof_last_bgrewrite_status；对应功能未开启时，部分字段可能不存在。出现 err 就继续看日志。一次 ok 或某个时间戳，不能代替实际文件与启动载入结果。

按实际路径核对文件和启动日志

如果前面确认 dir 为 /var/lib/redis、dbfilename 为 dump.rdb、appenddirname 为 appendonlydir，退出 redis-cli 后可在 Linux 终端执行；其他值先替换路径：

redis_data_path='/var/lib/redis'
sudo ls -ld -- "$redis_data_path"
sudo ls -lh -- "$redis_data_path/dump.rdb" "$redis_data_path/appendonlydir"
sudo df -h -- "$redis_data_path"
sudo df -i -- "$redis_data_path"

根据启用的方式核对文件大小、修改时间和归属，RDB 与 AOF 不要求同时存在。目录能列出来不代表 Redis 服务账号一定能读写；容量与 inode 都要看。不要用 777 权限或关闭持久化失败保护来掩盖问题。

由 systemd 管理且服务名确为 redis-server 时，查看最近启动记录；时间窗口按故障时间调整：

sudo journalctl -u redis-server --since "-30 min" --no-pager

重点找加载了哪个 RDB/AOF、载入键数，以及文件不存在、权限拒绝、格式错误或写盘失败。面板、容器运行时则查看对应进程日志，详见日志按时间筛选方法。日志中的载入成功还要与实际库号、键和TTL交叉核对。

Docker 环境还要检查当前数据挂载。换了 Compose 项目名、卷名或宿主机目录，可能得到一个新的空卷，旧数据却仍在原位置。按数据卷与目录挂载教程核对，不先执行带 -v的删除命令。

需要恢复时，保留原件再到隔离环境验证

找到旧 RDB 或 AOF 文件组后，先保存受限访问的副本，记录来源、大小、时间与校验值。多文件 AOF 不能在重写切换过程中随意逐个复制；应安排停止写入或采用经过确认的一致性备份流程，保留 manifest 与它引用的全部文件。仍在重写时不能仅凭“业务已停写”认定复制安全。

先在独立目录、仅本机可访问的临时端口，用兼容版本验证副本。检查启动载入日志、各逻辑库键数、关键值和TTL，再由应用确认业务数据是否对应。不要直接用旧文件覆盖已产生新写入的正式实例。

持久化解决的是进程重启后的数据载入，不能替代独立备份。确认恢复方案后，把可用副本保存到实例之外；包含业务数据的文件应限制权限并加密保存。最后再安排维护窗口验证配置、持久化和应用连接，而不是靠反复重启碰运气。