BGSAVE 失败与写保护
当后台快照因为磁盘写满、目录权限变化或文件系统异常而失败时，Redis 会把 rdb_last_bgsave_status 置为 err，并默认开启写保护：stop-writes-on-bgsave-error 为 yes 时，所有会修改数据的命令一并被拒绝，返回以 MISCONF 开头的错误。这个设计的用意很直接，既然当前数据无法被持久化，就宁可拒绝写入也不要让业务误以为数据安全。
基本信息
| 失败标志 | INFO persistence 的 rdb_last_bgsave_status 变为 err |
|---|---|
| 写保护开关 | stop-writes-on-bgsave-error，默认 yes |
| 报错特征 | 命令返回以 MISCONF 开头的错误文本 |
| 常见根因 | 磁盘空间不足、目录权限变化、挂载点掉线 |
| 恢复条件 | 快照成功后状态字段回到 ok，写保护自动解除 |
典型使用场景
- 写入全面报错时的快速定位：先看错误是否以 MISCONF 开头，把持久化问题与业务问题区分开
- 磁盘容量治理：把 rdb_last_bgsave_status 与磁盘使用率一起监控，在写满前预警
- 容器化环境的排查：宿主机挂载卷变化导致目录不可写，表现为实例仍在运行但快照持续失败
- 临时止血：确认根因前可临时关闭写保护让业务恢复，但必须同步处理磁盘或权限问题
- 恢复验证：清理空间后手动 BGSAVE 一次，确认状态字段回到 ok 再宣布恢复
排查与恢复
排查与恢复
redis-cli INFO persistence | grep -E 'rdb_last_bgsave_status|rdb_bgsave_in_progress'
redis-cli CONFIG GET stop-writes-on-bgsave-error
redis-cli CONFIG GET dir # 确认快照目录
redis-cli CONFIG GET dbfilename
df -h /var/lib/redis # 磁盘空间与挂载点
redis-cli BGSAVE # 清理空间后手动验证
redis-cli INFO persistence | grep rdb_last_bgsave_status # 期望回到 ok常见根因对照
| 现象 | 根因 | 处置 |
|---|---|---|
| 写入报 MISCONF | 快照持续失败 | 查磁盘空间与目录权限，修好后等状态恢复 |
| 状态为 err 但业务正常 | 尚未触发写保护或已被人工关闭 | 尽快修复根因，关闭写保护只是临时措施 |
| 快照耗时突然变长 | 磁盘 IO 饱和或文件系统异常 | 换用独立磁盘或提高 IOPS |
| 磁盘还有空间仍失败 | 目录属主或权限在变更后不匹配 | 核对运行用户与目录属主 |
写保护的双刃剑性质：它让业务在有数据风险时立刻感知，避免「以为写进去了实际丢了」的静默故障；代价是快照问题会直接升级为全站写入不可用。因此监控必须在快照失败的第一时间告警，而不是等业务开始报错。
关闭 stop-writes-on-bgsave-error 只是止血：它让写入继续成功，但数据仍处于无法持久化的状态，一旦机器故障这段时间的写入全部丢失。关闭后必须在同一维护窗口内解决磁盘或权限问题，并尽快重新打开。