乍一看，又是“宕机”惹的祸。可是，元芳，你怎么看？

疑点一：具体表现。
       从美国西海岸时间周日下午4点开始，GitHub.com一直处于抽疯的状态。具体来说，该网站仍在提供页面服务，它只是间歇性地提供过期的文件，但忽略了提交上去的Gist、代码错误报告和帖子。有时候，它似乎在提供只读缓存或它本身的旧备份，不过一些推送的新代码无法发布到网站上。

官网故障

疑点二：官方声明。
       开发团队在下午5点后说：“我们在继续努力迁移数据存储系统，以便恢复访问GitHub.com的服务。”该团队随后在过去的几分钟补充道：“我们在继续修复GitHub.com的数据存储系统。在此过程中您可能会看到不一致的结果。”

官网声明

   
       一般来说，像上面案例中提到的“迁移数据存储系统，以便恢复访问GitHub.com的服务”，也是应对IT事故、恢复业务的常规流程，无可厚非。然而在故障8小时候，仍旧无法提供业务支持，只能提供“旧备份”数据或者“不一致”的数据，让我不禁怀疑GitHub网站的数据有丢失的嫌疑。

       作为一个面向开源及私有软件项目的托管平台，Github拥有超过900万开发者用户。在GitHub，用户可以十分轻易地找到海量的开源代码。这意味着每时每刻都有大量重要数据在GitHub汇集。如果真的丢失了部分数据，对GitHub来说可能只是一小丢丢，可是对最终用户而言，则是100%的灾难。

       虽说容灾备份领域早就突破了早期的“数据备份与恢复”范畴，而增加了“业务连续”方面的内容，但数据才是根本，没有数据，谈何业务？

       在这一点上，我十分赞同容灾备份老牌厂商和力记易提出的“一个优秀的容灾备份方案，数据可用是底线”的说法。

       2015年底，笔者在一次行业会议上结识了和力记易公司的张总。当时大会就数据安全的重要性进行热烈讨论，在交流时，有人提起前不久银监会通报了某银行的数据丢失问题，为什么明明做了“双机双柜”，怎么还是不能“幸免于难”？和力记易的张总寥寥数语解开了这个疑问，“数据库数据还在，但是发生了内部逻辑错误（比如ASM头文件错误），所以整个数据库就不可用了。”

       我开玩笑的问张总“双机双柜方案都解决不了问题，你们和力记易的容灾备份方案呢？”张总斩钉截铁的说“我们可以！”

       不论是何种数据备份，定时也好，实时也好，快照也好，镜像也好，技术上的差别就决定了数据备份与恢复的不同结果。“备份数据”能忠实于“源数据”是最基本的，但是如果这份数据恢复回来以后无法使用，那这个恢复就没有任何意义。和力记易容灾备份软件——备特佳的CDP持续数据保护技术，区别于市场其他备份软件的最核心的一点就是：不仅能够保证备份数据的完整性，更能保证恢复数据的可用性。这一点，和力记易称之为“容灾备份的底线”。

       两年前的经历现在却历历在目，当时是因为震撼，今天被Github勾想了起来，却是衷心的希望GitHub的事故，乍一看是“宕机”，实际上也是“宕机”，千万不要丢失数据，浪费了忠实用户的心血和成绩。

       所幸，发文时，Github在历经了24小时磨难后，终于恢复正常，数据没有丢失，真好。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。