业务写入突然全部失败，抛出的错误是 MISCONF Redis is configured to save RDB snapshots, but it is currently unable to persist to disk。意思是快照写不进去，出于保护拒绝了写操作。
先看磁盘和数据目录
redis-cli config get dir redis-cli info persistence df -h
info 里 rdb_last_bgsave_status 会显示 err，配合 df 基本能确认是不是磁盘满。磁盘满是最常见的原因，日志文件或备份堆积把分区塞满。
再看权限和 fork 限制
ls -ld $(redis-cli config get dir | tail -1) tail -n 20 /var/log/redis/redis.log
日志里如果是 Can’t save in background: fork，说明内存超额导致 fork 失败，需要调整系统的 overcommit 参数或降低实例内存占用。权限问题则表现为 Permission denied，按数据目录的属主修正即可。
不要长期关掉保护
执行 config set stop-writes-on-bgsave-error no 能让写入立刻恢复，但这只是把故障藏起来，数据实际没有落盘，重启就可能丢。清理磁盘、修好权限后，再把参数改回来。
持久化恢复后跑一次手动 bgsave，确认返回 OK 且状态正常，再观察一轮监控。
集群和主从要分别看
主从架构下，从节点磁盘写满不会影响主节点写入，但复制会中断，主节点内存里的积压会越来越多。检查 info replication 里的偏移量是否还在增长，比只看一台机器更容易发现隐患。
日常监控建议把 rdb_last_bgsave_status 和磁盘使用率都纳入告警，前者是结果，后者是原因，两个指标一起看定位最快。
如果业务对持久化要求不高，也可以改成只做定期备份，但要清楚这意味着宕机时会丢一段时间的数据，别在故障发生后才讨论取舍。