BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Abel Avram 关注 10 他的粉丝 ,译者 侯伯薇 关注 0 他的粉丝 发布于 2010年1月6日. 估计阅读时间: 8 分钟 | AICon 关注机器学习、计算机视觉、NLP、自动驾驶等20+AI热点技术和最新落地成功案例。

最近Jeff Atwood丢失了两个blog站点:Blog @ StackoverflowCoding 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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

InforGuard防篡改,好东西!!! by 刘 鹏

给你个好建议,使用InforGuard 防篡改产品,里面有网站备份策略,细致到每个文件。对文件的备份和篡改绝对放心。

意外的事情太多! by Xu James

也许我们会有更详细的备份策略。
但是环境的复杂程度和突发事件太多。
我们只能尽量降低意外!

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT