数据备份和灾难恢复方面有哪些地方需要注意?

Jon Toigo: 数据备份和灾难恢复方面实际上是融为一体的。两者密不可分。数据备份和灾难恢复之间的关系有一点需要被强调的是，灾备计划需要定期测试以确保计划是切实可行的以及计划是满足业务最新需求的。许多人浪费了不少宝贵的时间用于数据测试，数据恢复测试，以确保备份磁带备份能够正确恢复，或者再看一下数据是否被镜像保护以及在需要的时候能随时切换到镜像数据上。

在灾难恢复额测试部分里我们不用做如上的操作。这势必将拖延整个测试的过程，同时也相应的让整个测试变得相对复杂。我们更应该专注于数据保护方案，具体说来就是确保数据的完整性，正确性，可恢复性等。更好的做法是，将这部分变成日常维护操作的补充，而不应该将其视为正式的测试范畴。

因此，我认为最好的方式是设定一个数据备份的策略，比如对于备份操作来说，需要经常的测试数据的可恢复性，使之成为一种习惯，而非定期的正式测试，后者则更应该是灾难恢复里面需要考虑的部分。但是当我们尝试将二者区别开的时候，我们也同样不应忽视二者的关联。备份与灾备之间是息息相关的。

存放拷贝的位置是否会影响部署灾备的方式？

Toigo: 有关这点我想说的是，只要有一份拷贝并存放到站点以外的位置，那么就大约有99%的机会实现了灾备。比如说，通过城域网，我们将数据由一个磁盘传输到了另外一个磁盘，这是一种方式。这也是许多公司常用的方式之一。这种方式中值得注意的一点是确保数据存放的位置离原来的位置保持足够的距离，以抵抗像Sandy这样的飓风袭击。

我们也会遇到一些涉及地理位置广泛的灾难。如果恰巧受灾区包含了主站点和灾备站点的位置，那么就是十分不走运了。因此我们建议两站点之间至少保持50到100英里。如果是通过城域网传输数据，那么也需要考虑大量数据传输时候带来的成本因素。

如果要传输10TB数据，即便是使用AT&T这样运营商提供的核心网络，也需要耗费四小时。如果是使用传统的T1网络传输，那大约要耗费1年。最快的方式是通过ipvac的方式传输，在一个USB设备的帮助下，数据传输速率将大大提升。所以，听起来这并不是很实际的做法，但这也的确见证了磁盘到磁盘城域网复制的变迁。后期像磁带的转变利用了全新的传输方式，但使用的则是快递的方式。

云备份不是我们推荐的方式。首先，我们需要通过基于城域网的复制将数据存放到云平台上。此外，一旦云平台所在的地理区域受到了类似Sandy飓风这样的灾难，云服务提供商将无法保证能第一时间将数据恢复给客户。他们甚至没有相应的带宽提供这样的服务，我们甚至听到过有的客户等待了一年的时间才能恢复数据。试想一下，谁能够在没有数据支持的情况下维持一年的业务？

因此，在了解这些不同的解决方案的同时需要考虑一些控制因素。云备份永远是好的吗？其实不一定，如果云平台之间在同一个地理区域里，那么不管是遇到自然的或者人为灾难的时候都可能无法避免。因此在选择方案的时候，需要考虑到最坏情况，以及最有效的应对方式。

如果企业需要查看数据保护的历史信息,那么应该从哪方面开始着手?备份,灾备或者是归档?

Toigo:我想说的是，判断如何查询历史的数据保护信息取决于架构本身的情况是怎样的。最起码的要求是，整个架构我可以了然于胸。不幸的事实是，有许多的实施场景下的架构并不具备可管理性。因此我们将会有许多的方法可以应对。

我们可以要求相应的厂商们以业界通用的REST管理方式的架构进行交付，这样在通用的标准下，我们可以拭目以待其中哪些厂商可以按照要求提供，哪些不能按照要求提供；甚至我们可以从中选择合适管理的产品，例如Tivoli，CA，Symantec产品，之后相应的存储管理架构就会基于此框架下建设。之后，我们就将告诉每家厂商需要按照规划好的存储管理框架提供相应的产品选择，否则将不予考虑。我们需要了解架构的情况，因为不同的产品所出现的故障都是不一样的。

我们希望企业能迅速的采取这样的方式这样就可以在失控之前对齐有所把握。如今，比起更为严峻的问题其实是数据管理的问题。当应用对数据进行写操作的时候，用户将会被提供一系列的服务来帮助他们使用这些数据。如果这些数据需要长期的保留，那么就需要一种层级的机制来帮助实现。数据首先被写入进高速存储，如果是经常被访问的数据那么将常驻；否则就会被迁移至稍慢一些的存储，这类存储的优势在于他们的容量更大成本更低，优先级再低的数据则会被存至磁带里。如果用户能严格执行这样的策略，最后会发现大约有60%左右的数据将会存放在磁带层，最终将帮助企业节省大量的架构成本。假设整体规模有100TB的数据总存储量，那么按此推算大约将为企业节省平均350,000美元的成本。即使用两层的方式，即高速磁盘到低速磁盘，也将帮助企业节省大约1500万美金的成本。

这些数据来源于行业专家中的一位，一个名叫Fred Moore的人通过他创办的Horizon Information Strategies公司，试图确定存储分层策略为企业节省的成本多少。如今他们将其作为一项服务将其以策略的方式应用到数据迁移的整个生命周期里。另外一些服务类别则将侧重于防范各类数据灾难事件的发生，可以进行深度防御。即便是数据写入了磁盘一样有损坏的风险。因此可以从RAID数据包含或者纠错码方面考虑，或者其他的一些技术手段比如说连续数据保护等，这种技术可以连续的对某处的数据进行写操作，一旦磁盘或者上面的数据出问题，就可以及时恢复数据。

也有一些不常见的情况发生，比如说会不会将可乐忘打翻在机柜上然后造成后背板短路？再比方说会不会遇到屋顶的下水道管破裂而你却无从应对？相信我，这些我都经历过，这些也都可能发生。

当遇到地理性质的灾难时，比如像飓风地震，恐怖袭击等，就需要以各种形式来保护数据的安全。本地拷贝可以以镜像的方式将数据从一个阵列里复制到另一个阵列，不管就在相邻的机柜还是在其它的某个公司的机房里，使用的都是公司的局域网连接。除此之外，遇到这样的灾难时还需有磁带备份这样的方式，可以放置到远程的站点里，再或者使用基于城域网的复制方式等，诸如此类。

因此，可能的情况是我们会使用连锁的一系列数据保护策略，将它们整合成一系列服务；这样理想的情况是，用户能够从数据写入开始就以服务的方式进行检查，每完成一项就交到下一个服务里，最后再将数据写到对应的卷里。如果最后将存储虚拟化完成了那么就能够实现这些。理论上说可以通过定义写数据的虚拟卷，然后基于此提供一系列的服务类别。

您认为在备份以及灾备规划中最常见的误区有哪些？

Togio：两方面。首先，用户往往对数据丢失的威胁过于紧张。因此，可能会做出为了包含一部电影写下复杂脚本的事情。此外，用户会花费大量的时间来做灾备规划，当然这的确也是很有趣的，我之前也这样经历过。但很明显好莱坞编剧才更合适做这些。结果往往是，花了大量的时间假想事情发生的过程，而这些并不在谁的控制之内。

也许你在剧情中邀请了布鲁斯威利斯，或者是神秘的外星人来让剧情变得更加引人入胜，但是这些谁又在乎呢？让我们一起来面对现实。最现实的方法是，当面对最坏情况的灾难时，能有相应的灾备方法来应对紧急事件。如上是第一点，那么第二点则是，计划好后需要进行灾备数据保护的演练。

我希望能看到的，我们能有一块演示版上能看到镜像保护是能有效工作的，因为镜像本身是无法测试的。镜像需要首先静默应用，将数据从缓存中写到磁盘里，然后再镜像到第二块硬盘中，最后再逐个文件的比对两块盘之间的差异以确保两者是完全一致的。这要花费不少时间。

我们想实现的一点是找到一个可以稳固测试的方式。最后，不要将其称之为灾难恢复。当公司管理层听到这个词的时候，他们会下意识的不愿意在可能不会发生的灾难保护上进行投资。

尽管如此，还是有很多人对于潜在的威胁显得过于谨慎，他们希望涵盖所有的一切。比如他们会和管理层说，“我们需要马上准备好应对灾难的各种防护措施。”而往往管理层不会因此买账。因此需要换个说法。比如完全换一个说辞。例如，“我们正全面考虑的企业法规遵从。我们正在努力确保我们的数据在未来十年之内都满足HIPAA的监管要求。”如果能以这样，换一个说辞，例如合规性管理或者什么别的，那么管理层将可能提供给这样的一笔资金，否则如果还是仅仅称之为灾难，以我的经验，应该不会有人愿意提供资金支持。