今人不见古时月，今月曾经照古人
写下这些，不是为了幸灾乐祸，而是提醒“前事不忘，后事之师”（这么说话好象有点“颜值越高，责任越重”的傲娇之嫌）
当人民在狂饮大嚼欢度春节时，彼岸一群技术男正汗泪俱下心急如焚地修复系统、恢复数据；当“鸡年逢吉、恭喜发财”的微信在一遍一遍地刷吃瓜群众的屏时，一则消息振惊了IT人的心！GitLab.com出事了、出大事了！GitLab.com宕机了，停止服务超过10小时！而且丢失数据了，丢了超过6小时的数据！
在众多技术男们纷纷发表对此事的看法、观点、建议时，本文无意再重复那些事后诸葛亮的“永恒真理”。无论是“人肉运维”的缺陷还是“技术至上”的依赖，我们都一直在一次又一次地重复这样的错误和悲剧：GitLab.com不是第一个中招的，也绝对不会是最后一个！过去我们有多少同行出现过同样的失误？又有多少其它的故障、缺陷、错误令我们停止服务、恢复失败、丢失数据、业务崩溃？
众多文章提出这样的问题：“有了备份就万无一失了吗？” GitLab.com有备份，有5重不同的备份手段。有复制技术、快照技术、云备份等等，无所不用其极，结果呢？
在互联网服务覆盖面日益扩张的今天，任何原因的宕机、数据丢失都会影响巨大：所谓“受众越多、失误被放大得越巨”。之于运维和数据保护，本文想提醒读者的是：
技术依赖没有错，但要选择好的技术！
备份依赖没有错，但要选择好的备份！
那么，什么才是好的数据保护技术？本文的观点是：旧的技术，在新的IT生态环境、新的业务生态环境中已经无法解决新的问题了！我们需要新的、打破旧技术窒楛的技术！
既然旧的备份，总会影响生产系统的性能，那我们需要的就是解放生产系统的备份！
既然旧的周期性的备份，总有数据丢失窗口，那我们需要的就是实时持续的份！
既然旧的文件格式的备份，总有数据库无法恢复的可能，那我们需要得就是数据库的交易数据的备份！
既然旧的基于LUN的复制、快照，总有复制错误、恢复失败的机率，那我们需要
的就是隔断错误、100%确保数据库恢复的备份！
. ……
既然旧的备份技术，总有这样那样的缺陷和漏洞，那我们何不痛下决心、选择改变？