redis 持久化失败时崩溃本质是只读文件系统叠加配置限制所致，并非 bgsave 失败直接触发；默认 stop-writes-on-bgsave-error yes 会拒绝写入但不退出，仅当 aof 重写也失败且磁盘彻底只读时才主动退出。

Redis 持久化失败时为什么直接崩溃而不是降级？

因为 bgsave 失败本身不触发崩溃，真正让 Redis 退出的是后续写入——当 stop-writes-on-bgsave-error yes（默认）且上一次 bgsave 出错后，任何写命令都会被拒绝并返回错误，但进程仍在运行；只有当你同时启用了 appendonly yes 且 aof-rewrite 也失败、再叠加磁盘彻底只读（比如挂载为 ro），才可能观察到 Redis 主动退出。常见现象是日志里反复出现 Can't save in background: fork: Cannot allocate memory 或 Failed to open the temp AOF file: Permission denied，接着写请求全返回 ERR Error: write commands not allowed when used with read-only filesystem。

如何确认是不是只读文件系统导致的持久化失败

别猜，直接查三件事：

• 运行 mount | grep $(dirname $(redis-cli config get dir | awk '{print $2}'))，看输出里有没有 ro
• 检查 dir 配置路径的权限：ls -ld <code>/var/lib/redis，确认 Redis 进程 uid（通常是 redis）有写权限
• 手动模拟写入：sudo -u redis touch /var/lib/redis/test-write，如果报 Read-only file system，就是它了

stop-writes-on-bgsave-error 设为 no 真的安全吗？

不安全，只是把问题藏得更深。设为 no 后，即使 bgsave 连续失败十次，Redis 仍允许写入，RDB 文件却一直没更新。一旦重启，数据就倒退回上次成功的快照——你可能丢了最近几小时的变更。更麻烦的是，AOF 如果也因同个只读路径失败，appendfsync always 会卡住写入线程，导致响应延迟飙升。所以这不是“开关一关就没事”，而是“从立刻报警变成静默丢数据”。

只读文件系统下还能做哪些有限保护

核心思路：不让 Redis 试图写任何东西。

• 把 save 配置全清空，例如注释掉所有 save 900 1 类行，避免定时触发 bgsave
• 关闭 AOF：appendonly no，否则 bgrewriteaof 一样会失败并可能阻塞
• 确保 dir 指向一个可写的临时路径（哪怕只是 /tmp/redis），哪怕只是用于 pidfile 和 socket
• 监控必须跟上：用 redis-cli info Persistence | grep rdb_last_bgsave_status 检查是否一直是 err

最棘手的其实是容器或 systemd 场景下，/var/lib/redis 被 bind mount 成只读——这时候改配置不如修挂载参数，因为 Redis 自己根本没法绕过内核的只读限制。