下载掌阅APP，畅读海量书库
立即打开
笔者在20世纪90年代早期进入数据保护行业，那时我们照常使用备份系统的头号理由就是机械故障或系统故障。文件系统与数据库都直接放在物理硬盘上，如果硬盘“挂了”，上面的数据也就一起完蛋了。
现在的情形跟当年有很大区别，造成这种区别的原因比较多，其中第一个原因就是：关键的工作数据现在都保存在某种形式的固态介质上。另外，在终端用户所使用的设备（例如笔记本计算机、智能手机、平板计算机以及物联网设备）中，数据也保存在这样的介质上。于是，目前的IT人员就不太可能遇到我们当年经历的那种设备问题。
我们的存储设备比原来更加健壮，而且任何一个重视数据的数据中心，都会配备RAID这样的冗余存储机制以及纠删码（erasure coding）技术。另外，磁盘生产商似乎也会在设备的固件里面内置完整性检查（integrity checking）逻辑，宁可让数据无法保存，也不让磁盘发生故障。这意味着现在已经很少出现因为硬盘故障而恢复数据的情形，但这并不意味着这种情形绝不会发生。
就算有能够同时处理多个磁盘故障的RAID与纠删码技术，我们也还是会遇到刚说的硬件故障。例如依然要面对停电的问题，而且某些固件可能导致多个硬盘驱动器全都出现错误。当然，整个RAID阵列中的磁盘同时故障的情况相当少见，但也不是从来没有发生过。因此，即便有RAID或纠删码，我们也还是得做备份。虽然很少遇到这种因发生机械故障而必须恢复数据的情形，但这样的情形确实存在。
尽管笔者很讨厌用身边的事情举例，但我们目前确实在经历轮流停电（rolling blackout）的问题。在容易失火的季节里，电力公司会通过轮流停电降低火灾发生率。
这个因素是很容易设计方案来应对的，从数据保护的角度讲，你也应该能把这样的事情处理好。任何一个颇具规模的数据中心，都会有冗余电源与大型发电机。如果你能知道何时停电，那就应该能够应付规模较大的断电事件。
问题在于，如何应对突发的停电。如果在你事先没有得到通知的情况下，数据中心的所有供电都突然断了，那么其中的所有服务器就全都无法运作。这个时候，有些数据可能没有适当地得到保存，因此可能会遭到破坏。结构化的数据基本上应该不会受到破坏，因为数据库有内置的数据完整性检查机制，不会让结构上有问题的数据写到数据库里面。无结构的数据（也叫非结构化的数据）基本上也应该没事，只是停电那一刻正在写入的少数几个文件可能会有点问题。另外，数据库虽然可以通过数据完整性检查机制来保护数据，但是对数据库做介质恢复（media recovery）所花的时间（这种恢复会在第7章讲解），可能比全恢复（full restore，也就是直接恢复所有数据）更长。
上一段里有好几个“应该”，然而“应该”并不等于“肯定”，所以这正是我们要做备份的理由。有时服务器一旦崩溃，里面的数据库就再也救不回来了。有时断电那一刻正在写入的可能是一份相当重要的文件，大家为了这份文件忙碌了好多天。这些都是我们（不能仅依靠数据库自身的机制）必须做备份的理由。
虽然笔者很喜欢公用云（public cloud），但这只是一种包装和营销的概念而已。其实并没有所谓云（cloud）这个东西，它还是得依靠别人的计算机来实现。当然，云平台会通过各种编程技术，让用户能够在上面轻松地存放应用程序与数据并对其加以管理，同时还会把这些东西做得更加健壮。但云平台没有那么神奇，它本质上还是一批给你提供服务的计算机而已。这些计算机与安装在它们之中的磁盘，都有可能发生故障。
所以我们一定要意识到，云平台所支持的各种数据存储机制，从数据保护的角度看，是有所区别的。采用对象存储（object storage）机制来保存的数据，可以在多个位置上存留多份副本，因此能够经受多次事故，而采用块存储（block storage）机制来保存的数据，则只是虚拟驱动器里面的一个LUN（Logical Unit Number，逻辑单元号），这个虚拟的驱动器仅位于某一间数据中心的某一个存储阵列里面。这种存储方式没有任何冗余机制，因此采用该方式存储的数据必须加以备份。当然有些云平台也提供了带有冗余的块存储机制，但大多数人没有启用这个方案。另外，本章后面会讲到，由人引发的数据事故并非总能通过冗余（也就是通过把某个东西多备一份）来解决。
无论你用的是仅依赖某一个存储阵列的单一服务器（由不同位置的多个数据中心所构成的大型服务器集群），还是由云端所提供的服务，都无法保证其完美无缺。程序员总是会犯错误，因此总是会有不好的事情发生。这正是我们必须把重要数据备份下来的原因。
这是一本讲数据保护的书，但本书第1章的初稿却恰好由于用户的操作失误与程序的逻辑错误相遇而彻底丢失，也就是说，它完全没有得到保护，这简直是一个绝妙的讽刺。笔者在本书的其他地方提到过，这本书是我于疫情期间，在跑步机上用Dragon听写软件说出来的。Dragon的默认设置，是在保存文档时把你说的这些话所对应的音频数据也保存起来，因此与那种仅保存文档而不保留音频的软件相比，要花很长时间。由于笔者不会用到这些音频数据，因此某天早晨，我决定修改设置，让Dragon在存储音频数据之前先询问用户。
在跑步机上说了大约两个小时之后，我才突然意识到自己竟然没有存档。于是我就说：“Click File...Save”（单击“文件”菜单下的“保存”菜单项）。我想要以此来触发保存流程。软件弹出了一个对话框，问我要不要保存文档，但当时不知怎么回事，我以为它问的是要不要保存音频，于是我说“No”（不），接下来，软件居然在没有保存文档的前提下，就把文档给关了。两个小时的话白说了。
在这个过程中，用户的操作固然有失误（我本来应该仔细看一下这个对话框问的到底是什么，然后再回答），然而软件编写得也有问题，用户没有让它把文档关闭，但它却把文档给关了。实际上，用户只是触发了Dragon的保存流程，并在Dragon提示用户是否执行保存操作时，告诉它不要保存，用户并没有命令Dragon把文档关掉。这个故事是想说，软件与硬件未必总是按照预想的方式运作，因此我们必须做备份。当然，这个例子举得不好，因为在本例中，文档其实保存在计算机的RAM（内存）里面，因此就算启用了备份机制，哪怕是采用了带有持续数据保护（Continuous Data Protection, CDP；又称实时数据保护）功能的备份产品，也没什么用。
本书所给的大多数建议，都应该适用于采用计算机来存储其运营数据的各种商业实体、政府实体或非营利实体。因此，笔者尽可能采用组织（organization）这个词来指代这些需要保护其数据的实体。这个组织可以指某个政府机构、某个NGO（Non-Governmental Organization，非政府组织）、某个营利的非上市公司或上市公司，以及非营利的公司等。
目前的系统与数据库已经能够应对许多数据问题，因此由物理故障及系统故障所造成的数据损失，应该不会很常见。然而，接下来我们要讲一种很难由组织本身来应付的数据威胁，也就是自然灾害。你最好对这样的威胁有所准备。