如何解决Redis bgsave失败导致的持久化异常_检查磁盘权限与dir配置路径是否正确-Redis-PHP中文网

需手动验证三件事：目录存在、属主匹配（如redis用户）、权限到位（属主至少rwx）；用ls -ld、df -h、df -i及redis-cli info persistence等命令交叉确认，config get dir仅返回配置值，不校验实际可写性。

如何解决redis bgsave失败导致的持久化异常_检查磁盘权限与dir配置路径是否正确

看到 CONFIG GET dir 返回了路径，不代表 Redis 就能往里写——它只告诉你配置值，不校验可用性。必须手动确认三件事：目录存在、属主匹配、权限到位。

运行 redis-cli CONFIG GET dir | tail -1 拿到路径（比如 /var/lib/redis），再执行 ls -ld /var/lib/redis；如果报 No such file or directory，说明目录根本没创建
检查输出里的属主字段，如 drwxr-xr-x 1 root root，但 Redis 进程是以 redis 用户跑的，那它就无权写入；应改为 chown redis:redis /var/lib/redis
权限位不能只有 r-x，至少得是 rwx（对属主）；用 chmod 755 /var/lib/redis 即可，别上 777，SELinux 或容器环境会直接拒绝

常见错觉：查了 / 或 /var 分区有空余，却忽略了 dir 配置可能指向独立挂载点（比如 /data/redis）。bgsave 只关心那个路径所在文件系统的实际用量。

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

先执行 redis-cli CONFIG GET dir | tail -1，再套用 df -h $(redis-cli CONFIG GET dir | tail -1)，这才是真实落盘位置的磁盘使用率
Docker 容器里必须进容器执行，宿主机 df 看不到容器内挂载卷的用量；云数据库（如阿里云 Redis）则要查控制台“磁盘使用率”，SSH 登录无意义
除了空间，还要查 inode：运行 df -i $(redis-cli CONFIG GET dir | tail -1)，Use% 到 100% 也会导致 No space left on device

CONFIG SET dir 在绝大多数生产部署中是无效的——它只在 Redis 启动时未显式配置 dir（即 redis.conf 里没写这行）且用默认值的情况下才可能生效。即使设成功，也不会迁移已有文件，更不会自动触发一次保存。

真正生效的方式只有两种：改 redis.conf 中的 dir 行 + 重启；或 CONFIG SET dir /new/path 后立刻 CONFIG REWRITE + 重启
设完新 dir，必须手动触发 BGSAVE 或 SAVE，否则不会生成新 dump.rdb
检查是否加载了别的配置文件：systemd 服务文件里可能带 --config /etc/redis/other.conf，你改的其实是另一个文件

这是典型的“静默失败”：bgsave 子进程启动了，但在写入临时文件阶段卡住或退出，Redis 主进程没收到完成信号，状态就僵在那里。不是没日志，是你没盯对地方。

查日志别只扫 Can't save in background，重点搜 Failed to open the temp RDB file for saving 或 fork: Cannot allocate memory（内存不足导致 fork 失败很常见）
运行 redis-cli INFO persistence | grep -E "(rdb_bgsave_in_progress|rdb_last_bgsave_status)"，如果 rdb_last_bgsave_status:err 且长时间不变成 ok，基本确认失败
别信 CONFIG GET dir 的返回值就万事大吉——用 ls -l $(redis-cli CONFIG GET dir | tail -1)/dump.rdb 看文件是否存在、修改时间是否变化，才是硬证据