Redis又重启了，不过还好数据又恢复起来了，真是惊险一刻

（一）

那天下午，办公室里一如既往地响着键盘敲击声，我正埋头写代码，突然，测试组的同事小王在群里发了一条消息：“大佬们，咱们的测试环境页面怎么全都报错了？数据好像都空了！”

我心里“咯噔”一下，一种不祥的预感瞬间涌了上来，测试环境的核心数据都存储在一个Redis实例里，它要是出了岔子，整个系统的缓存、会话、还有一大堆临时状态就全完了，我赶紧打开终端，尝试连接那台作为Redis服务器的虚拟机，命令行光标闪烁了几下，弹出一行冰冷的错误提示：“Could not connect to Redis at 127.0.0.1:6379: Connection refused”。

“完了，Redis真的挂了。”我小声嘀咕了一句,旁边的同事也凑了过来。

我们首先怀疑是服务器本身的问题，是内存爆了？还是磁盘满了？我手忙脚乱地登录上那台虚拟机，一通检查。top命令显示系统负载正常，内存和CPU都还有不少余量。df -h一看，磁盘空间也绰绰有余，这就奇怪了,服务怎么会无缘无故地死掉呢？

（二）

抱着试一试的心态，我输入了启动Redis的命令：sudo systemctl start redis，屏幕安静了一秒，然后提示启动成功，我心里稍微松了一口气，赶紧再次尝试连接，这次，连接成功了！可是，还没等我们高兴,新的问题就来了。

小王很快又在群里反馈：“页面能打开了，但是所有用户都变成未登录状态了，之前创建的数据也全都没了！”

我心里一沉，立刻在Redis命令行里输入了keys *，结果令人窒息——返回的是空集，这意味着Redis虽然进程起来了，但里面的数据全都不翼而飞，这比服务宕机更可怕，宕机了重启就好,数据没了可就麻烦大了。

“是不是配置成不带持久化启动了？”一位经验丰富的老同事提醒道，我赶紧去检查Redis的配置文件redis.conf，果然，问题就出在这里，配置文件中，save选项被注释掉了，这意味着Redis被配置成了纯内存模式，没有开启RDB快照持久化，更糟糕的是，appendonly选项也被设置为了no，即关闭了AOF（追加日志文件）持久化。

换句话说，我们这个Redis实例就像一个失忆的人，每次重启都会清空所有记忆，从头开始，这次突然宕机，最后一次内存中的数据因为没有持久化,彻底丢失了。

（三）

冷汗开始冒出来了，这个测试环境虽然不像生产环境那么性命攸关，但里面也包含了大量我们辛苦构造的测试数据、用户会话和业务流程状态，如果找不回来，测试工作就得停滞,整个团队的进度都会受影响。

“别急，再仔细找找，有没有备份文件？”老同事沉稳地说，他的话点醒了我，我抱着最后一线希望，在服务器上疯狂地搜寻起来，按照默认配置，如果有过RDB持久化，会生成一个叫dump.rdb的文件，我在Redis的工作目录里找，在/var/lib/redis里找，甚至用了find命令全盘搜索，结果都是一无所获，看来，这个实例在很长一段时间里,根本就没产生过持久化文件。

就在我几乎要放弃，准备告诉大家“数据彻底丢了，我们重新构造吧”这个噩耗时，我突然想起一件事，大概在两周前，因为另一个临时需求，我好像手动执行过一次SAVE命令,当时还把生成的文件备份到了另一个位置以防万一！

这个念头让我心跳加速，我立刻切换到那个我用来放临时备份的目录，用颤抖的手输入ls -l，果然！在一个不起眼的角落里，静静地躺着一个名为dump-old.rdb的文件，看修改时间,正好是半个月前！

“找到了！有个半个月前的备份！”我几乎喊了出来,整个小组的人都围到了我的工位旁边。

（四）

接下来的操作，需要万分小心，我首先停止了刚刚启动的那个“空”的Redis服务，将这个宝贵的dump-old.rdb备份文件，小心翼翼地复制到Redis配置文件中指定的dir目录下，并重命名为dump.rdb，做完这一切，我深吸一口气,再次启动了Redis服务。

这一次的等待显得格外漫长，服务启动后，我没有立刻连接，而是先查看了Redis的日志，日志显示：“DB loaded from disk: ...”，后面跟着一个加载耗时，成功了！数据正在从磁盘备份文件中加载！

我迫不及待地连接上去，再次输入keys *，屏幕上终于不再是令人绝望的空行，而是快速滚动出了一长串key的名字！虽然数据是半个月前的，丢失了这两周新增的测试内容，但这已经是不幸中的万幸了！核心的业务数据和基础架构都回来了。

我立刻在群里通知：“数据恢复成功了！用的是半个月前的备份，大家检查一下，最近两周的数据需要重新构造一下。”

群里瞬间被“太好了！”“牛逼！”“救星！”的表情包刷屏，小王也回复说：“老数据都在就行，最近的我们很快就能补回来！真是惊险一刻啊！”

（五）

风波过后，我坐在椅子上，长长地舒了一口气，心里满是后怕，这次“惊险一刻”就像一次突如其来的消防演习,暴露了我们基础设施维护上的巨大疏忽。

我立刻着手做了三件事：第一，修改Redis配置文件，开启了合理的RDB快照策略和AOF持久化，确保数据丢失的风险降到最低，第二，设置了一个定时任务，每天凌晨自动将持久化文件备份到远程存储服务器上，第三，在团队的Wiki文档里，详细记录了这次事件的经过和恢复步骤,并强调了定期检查数据备份有效性的重要性。

这件事给我上了深刻的一课，技术工具用起来顺手，但绝不能掉以轻心，它就像家里的保险丝，平时感觉不到它的存在，可一旦熔断，整个生活都会陷入黑暗，数据是无价的，再简单的系统，也需要有可靠的数据保护伞，那句老话说得对，“晴天修屋顶”远比“雨天补漏”要明智得多，这次是测试环境，我们侥幸找到了一个陈旧的备份，如果是生产环境，后果简直不堪设想，那一刻的惊险，足以让我在以后的工作中，对每一个字节的数据,都怀有足够的敬畏。