站点恢复过程中的经验和教训

最近 Jeff Atwood 丢失了两个 blog 站点： Blog @ Stackoverflow 和 Coding Horror 。他设法恢复了这两个站点的内容，但是从这个事件中我们应该得到什么教训呢？

在 Jeff 的博客上，他写了一篇为什么人们需要备份内容以及如何进行该项工作的文章，2008 年一月发布的，在其中他做出了以下结论：

可以肯定的是：只有在你拥有某种备份策略，并且坚持执行的时候，你才会了解它。如果备份数据看起来有点麻烦，那就对了，因为它的确是那样。打住！我知道怎么回事儿。听我的。不管怎样都要做。

Jeff 针对 Stackoverflow 以及 Codeing Horror 的博客都有备份策略，其中后者是由 CrystalTech 管理的，他们会经常备份整个站点。但是又怎么可能会丢失站点的内容呢？原因是由于站点是存放在虚拟机中的，而 CrystalTech 备份的是虚拟机的镜像，而镜像全都被破坏了。这样，虽然备份包含了大量被破坏了的虚拟机镜像，但是它们没什么用处，因为使用它们无法启动虚拟机。在文章的开始，Jeff 将责任归咎于他自己以及提供商：

Jeff Atwood ：呃，CrystalTech 的服务器崩溃了。很显然他们通常所用的备份流程在备份虚拟机镜像的时候失败了，而没有给出提示。 Jeff Atwood ：对此，我和站点提供商各负 50% 的责任（不要相信站点提供商，还是要做你自己的离线备份！）

在一些用户的帮助下，Jeff 设法恢复了他的站点中丢失的内容。Rich Skrenta 帮助他找回了文本：

幸亏有 blekko.com 的 Rich Skrenta，这样我才能几乎立即找到 Coding Horror 站点上的静态的 HTML 版本。他热心地提供了该站点上每个爬虫页面的结果。有些人有目标，而有些人有大胆的的目标。Rich 的目标尤其令人惊叹：在 Google 最擅长的搜索领域与其进行较量。这是为什么他能够恰好找到 Coding Horror 完全的文本存档的原因。Rich，我是否曾经告诉你，你是我的英雄？不管怎样，幸亏有了 Rich，你现在还能够浏览 Coding Horror 的静态 HTML 版本。令人惊奇的是，对于这个站点，静态的 HTML 版本和动态的版本没有很大的不同。我想这是作为极简主义者的好处吧。

而图片都来自于 Carmine Paolino，恰好一个用户拥有“这个站点几乎完全的镜像，这些数据都存放在他的 Mac 上！多亏他的镜像，我现在才能够几乎 100% 地恢复丢失的图片和内容。”在恢复了站点之后，Jeff 获得了重生，同时也停止了自责：

因为我是个笨蛋，我没有对 Coding Horror 做自己的（最新的）备份。天哪，我多希望曾经读过一些好的关于备份策略的博文啊！

他做出如下结论：

从这些悲惨的事件中，我们能够得到什么教训呢？ 1. 我吸取教训。
2. 是的，真的，我吸取教训。
3. 不要依赖于你的提供商或者任何其他人来备份你重要的数据。而应该自己来做。如果你不能够对你自己的备份负责，那么数据丢失就不会是偶然事件了。
4. 如果你的数据真的出了问题，那么你怎么才能够恢复呢？过程是什么呢？恢复最困难的部分是什么呢？我想在我思想深处对 Coding Horror 的灾难恢复能力有错误的信心，因为我一直认为它大多数都是文本。当然，后来发现文本是其中最简单的部分。而我曾经认为是很好方式的镜像比我意识到的更加重要，而且更加难以恢复。有些人认为我们不应该讨论如何备份，而应该讨论如何恢复。
5. 定期对你的恢复过程进行检查，以确认它仍然是可用的、有效的并且功能齐备，这是非常有价值的工作。
6. 我太伟大了！不，只是开玩笑。我还是要吸取教训。

Joel Spolsky 展示了多种其他可能的情况，其中如果没有提供恢复的话，那么备份策略就不起作用：

• 我们使用加密安全密钥对备份文件进行了加密，而密钥位于丢失数据的那台计算机上。
• 服务器有大量存储在 IIS 的元数据库中的配置信息，而它们没有备份。
• 备份文件被复制到 FAT 分区上，并且被截断为 2GB，而没有给出提示
• 你的备份位于 LTO 驱动器上，它和数据中心一起丢失了，并且你无法在三天之内得到另一个 LTO 驱动器。
• 还有其它成千上万种可能出现的错误，即便你拥有备份策略。

可靠服务的最小限度并非是你已经做了备份，而是你已经为恢复做了准备。如果你正在运行一个 Web 服务，那么你需要明白的是，你能对整个站点创建合理的最新副本，并且是在合理的时间之内，在一个新的服务器上或者过去没有访问过原来的数据中心上任何东西的服务器。底线是你已经做了对恢复的准备。

让我们不再询问人们他们是否做了备份，而要询问他们是否为恢复做了准备。

Jeff 转移了他的博客站点，以便于存放 Stackoverflow 的数据中心和其他在家中的服务器更加可靠，因为它们带有更好的备份策略：

1. 我们在早上四点、下午四点和晚上 12 点会对所有数据库做全备份。（某些数据库可能会更频繁，但这是通常的方式）这些数据库的全备份都存储在 PEAK 数据中心机架上的 NAS RAID-6 设备中。
2. 我们有一个连接在数据库服务器上的 500GB 的 USB 硬盘。还有一段 C#的脚本，它会在每晚的凌晨一点左右将最新的备份从 NAS 复制到 USB 硬盘上。最旧的文件会被删除，从而为新的文件腾出所需要的空间。（当前的 Stack Overflow 的全备份压缩之后有 7GB 左右，而另一个数据库压缩后大概有 2GB）。新措施是：我们会在服务器上连接两个 USB 硬盘，从而并行地做验证复制，以免其中之一出现问题。
3. Geoff Dalgas 是我们团队的一员，他住在离 PEAK 数据中心一英里的地方。他每过几周就会顺便到数据中心更换 USB 硬盘。他在家里放有四块 500 GB 的硬盘，还有两个在数据中心。他会不时地持续循环更换。
4. 新措施：Fog Creek 每周都会使用 FTP 接入，然后将最新的数据库备份到他们的伺服设备上，在星期六流量低的时候进行。
5. 我们每个月都会为所有站点（Stack Overflow、Server Fault、Super User）创建共享的数据块（dump）。这是数据的子集，但是是可以控制大小的，并且提供在 Legal Torrents 上。这些数据块被物理存储，并且由 Legal Torrents 提供种子。
6. 我们的 Subversion 源代码控制库每天都会被复制到 NAS 上，并且被复制到外部的 USB 硬盘上等等，这都是通过相同的脚本完成的。
7. 我们还运行了几个虚拟机镜像——大多数是为了提供 Linux 辅助服务——他们也是通过同样的过程备份的。因为我们的其他提供商吸取了困难的方式的教训，所以像虚拟机那样备份更有技巧性，而这肯定是你需要小心的事情。
8. 我们有规律地下载最新的数据库备份并在本地恢复它们（我们总是针对真实数据进行开发），从而我们知道我们的备份是有效的。

这个策略听起来比在开始的时候设置更好一些。在这种情况下薄弱的环节在于“Geoff”。如果 Geoff 没有出现并更换驱动器怎么办？或者他丢掉了一块怎么办？或者小偷从他家里把硬盘偷走了怎么办？

Jeff Atwood 不是真的要责怪谁。这对任何人都有可能发生，即便拥有更好的备份策略。问题在于：我们在此能够得到什么样的教训？

查看英文原文： Validating a Backup Strategy with Restore