我们的新备份系统如何节省 24 小时以上的停机时间

[shukla7789]

实验室

还记得我们去年 10 月宣布新基础设施的时候吗？我们特别引以为豪的创新部分是我们内部创建的备份/恢复系统。几天前，该系统进行了首次关键的现实测试，结果令人印象深刻。与之前仍在使用旧备份解决方案时相比，我们能够恢复 3 倍的数据，速度提高 7 倍。以下是我们做到这一点的方法。


我们多久需要进行一次大规模备份恢复？
简短的回答是：很少。拥有高度冗余的基础设施，在 RAID 中配备多个 SSD，几乎消除了这种恢复的需要。通常，当 SSD 发生故障时，它会被无缝替换为新硬件，不会有任何值得注意的停机时间或数据丢失。磁盘故障 加拿大 whatsapp 数据 非常常见：对于我们这种规模的提供商来说，几乎每天都会看到此类事件，这是很正常的。然而，时不时地，不幸地同时发生几个硬件和软件故障，可能会使标准的硬件更换变得不可能。而这些时候，我们需要从备份副本中恢复损坏实例上的所有帐户。

以前，在我们的新备份系统之前。
上一次我们需要对整个共享托管服务器进行完整备份恢复是在一年多以前。当时我们使用 R1Soft 备份，它是我们行业中最受欢迎的备份之一。像我们这样的托管服务提供商使用该软件主要有两个原因。首先，它非常可靠。我们几乎从未遇到过任何丢失或损坏备份的严重问题。其次，它非常轻量，在创建备份（每天都在进行的资源密集型过程）时不会对生产服务器造成重大负载。凭借这两个功能，R1Soft 在 99% 的时间内都能完美运行 - 当它创建备份和需要单个备份副本时。

然而，在极少数情况下，当需要完全恢复多个帐户时，R1Soft 有一个严重的缺点——恢复过程非常缓慢，受影响的网站可能会长时间停机。在所讨论的事件中，我们所有受影响的帐户都停机了 28 个小时。之所以花了这么长时间，有两个原因。首先，R1Soft 不允许同时从多个位置恢复数据。所有数据都需要通过一个网络接口恢复，这很慢。R1Soft 的另一个问题是恢复不能是增量的，并且服务器实例在整个恢复过程中都处于停机状态。所有受影响的网站只能在将全部信息从备份服务器传输到生产机器后才能同时恢复在线状态。因此，即使是最小的网站也无法恢复，直到我们恢复整个服务器。

大多数共享托管服务提供商几乎不会认为这是一个严重的问题，在恢复完成后需要采取进一步行动。毕竟，只有一台机器受到影响，所有客户的网站都恢复了，没有数据丢失。网站的停机时间在一年中也几乎可以忽略不计：28 小时仅占一年的 0.3%。然而，在 SiteGround，我们对问题的持续时间非常不满，并决心防止这种情况在未来再次发生。

现在，我们有了新的备份系统。
就这样，我们下定决心创建自己的备份系统，以保证更快的恢复过程，我们才华横溢的 DevOps 部门也开始着手解决这个问题。我们在 2015 年 10 月推出了新的解决方案，但直到几天前，我们才不得不在类似上述事件中使用它。与我们当时使用的解决方案 R1Soft 相比，我们自己的系统可以进行分布式备份，并允许从多个备份实例同时恢复到多个生产服务器。因此，我们现在能够在短短 4 小时内恢复 4TB 的数据（几乎是之前的三倍），而上述故事中需要 28 小时。此外，我们的系统允许增量恢复，第一批帐户在问题发现后几分钟内即可恢复，最长的停机时间（约 4 小时）仅影响少数几个单独的站点。这使所有受影响帐户的平均停机时间从之前的 28 小时缩短到不到 2 小时。这是一个相当令人印象深刻的进步，不是吗？但是……