太平洋标准时间下午 12:30，我们开始能够从最新备份中获取部署元数据，并通过手动流程直接修复每个站点上损坏的部署。由于 CDN 缓存，大多数受影响的站点仍能正常运行，因此我们开始手动恢复站点，重点关注通过所有支持渠道报告的站点。
太平洋标准时间下午 1:45，我们已编写脚本来自动执行此过程，并逐个站点将任何站点恢复到上一个已知的良好状态。 太平洋标准时间下午 3:15，我们数据库备份中所有受影响的部署都已恢复。
我们开始运行脚本来识别尚未从数据库备份中恢复且自事件发生以来 俄罗斯电报号码数据库 没有任何新构建的站点。 太平洋标准时间下午 3:46，我们记录了所有受影响的部署，并通过从备份恢复或将站点恢复到最后已知状态进行处理。
在我们运行原始迁移和问题修复之间的时间间隔内部署的一些站点遇到了第二个问题，即现有部署的错误元数据会导致一些新文件上传陷入错误状态。我们正在识别所有受此影响的站点，并将与可能存在文件上传不正确的客户取得联系。
行动项目 昨天的事件在很多方面都是任何服务中最糟糕的情况，人为错误导致生产数据库中大量数据不可挽回地丢失。 讽刺的是，我们原计划在本月底进行首次重大灾难恢复演习，目的是改进我们处理重大问题的流程。
但我们却不得不在实际操作中学习。 由此产生的行动项目分为两类： 我们如何才能避免类似事件再次发生。 我们如何才能从这样的事件中更快地恢复过来。 避免类似事件发生 最终，这归结为避免人为错误，无论我们谈论的是数据库更新还是重大配置更改。