有时你需要一些运气（原：build.opensuse.org 停机）

作为管理员来说，最糟糕的早晨：从存储阵列中的单个磁盘开始故障，最终导致整个阵列崩溃。

build.opensuse.org 后端服务器背后的存储阵列检测到损坏的磁盘，并开始重建受影响的虚拟磁盘 vd02。在重建过程中，使用的目标磁盘（之前的备用磁盘）开始以高频率抛出错误，导致存储控制器崩溃。最初故障的磁盘是 2.0（机箱 2 中的磁盘 0）。

从当地时间下午 12:32 开始，OBS 后端无法访问其存储。

该阵列实际上运行着两个控制器作为故障转移。拥有虚拟磁盘的控制器会尝试重建，崩溃，然后另一个控制器会接管，同样开始重建并以相同的方式崩溃。

是时候更换存储了，以及备份（顺便说一下，备份不包括 home:* 仓库，所以请注意，不要相信我们会备份你项目构建的二进制文件），这需要一些时间来恢复……

但在咨询了我们的供应商和制造商的 L3 支持后，我们移除了磁盘 2.1（机箱 2 中的磁盘 1）。因此，虚拟磁盘 vd02 目前处于离线状态。好消息是，vd02 实际上不包含任何数据——有时你需要一些运气。

包含 openSUSE 数据（backend-opensuse 和 back-home-opensuse）的虚拟磁盘 01 中的驱动器不受影响，停机是由于存储控制器崩溃造成的。

随着 vd02 离线，阵列现在再次稳定。制造商的支持团队目前正在检查我们日志文件的所有细节，并要求提供磁盘 2.1 以进行更仔细的检查。此外，所有磁盘驱动器的固件级别也在检查中。开发人员已经将代码添加到他们的固件源代码仓库中，以避免这些崩溃，并且这些修复将包含在未来的二进制固件版本中。

存储在当地时间下午 6:16 再次可用，在与 L3 确认当前的虚拟磁盘将保持不变的状态后，我们开始将文件系统恢复在线。

由于磁盘阵列的多次重新启动，我们丢失了一些缓存数据，因此 OBS 后端机器上的 xfs 文件系统受到了一些影响，但对两台机器都进行了两次 xfs_repair 操作，并将移动到 lost+found 的部分进行了检查和清理。

搜索并删除了通常产生的 0 字节文件（这在 backend-opensuse 上已完成，并在 back-home-opensuse 上进行中）。

所有后端进程都已启动并正在运行，backend-opensuse 上的冷启动已完成，back-home-opensuse 上的调度器冷启动也即将完成。

OBS api 的 Web 服务器已重新启动，使 OBS 再次可用，对于 software.opensuse.org，Web 服务器和 memcached 已重新启动（后者需要修复列表的 120 分钟负缓存）。