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 自己根本没法绕过内核的只读限制。
