云备份的诸多选择

“把你的数据从你的大楼里弄出来”是我针对数据保护所能提出的最佳建议，而这是很多公司都仍在纠结的那部分流程。很多公司都在危机出现的时候被打个措手不及，因为他们还在计划他们的数据保护方案，或者采用的“方案”过于令人费解以至于实际使用的时候不能工作。

把备份作为服务

伴随着所有有关“云”的讨论，云备份——或者BaaS(backup as a service备份即服务)——看起来是一个对把数据移出站点的问题的自然而然的解决方案。这在某些情况下是正确的，不过你需要对一些关键点十分清楚：

认识到你考虑一个基于服务的模型的主要业务动机是降低备份的运营复杂性。好消息是你不必用从前那么多精力来管理它了。坏消息是它不归你管理，所以你要准备好迎接一些新的界面、安装方法、任务系统和其它的东西。

理解备份到云相对简单，但是从云恢复就不是了。你需要很好地定义你的恢复目标，而且你可能需要考虑某种恢复设备来加速恢复过程，而不是从Internet下载数据。

承认最关心你的恢复过程的是你自己。如果你无法在需要的时候恢复需要的数据，你的云服务商只是丢掉了一个客户，而你可能丢掉你的工作或者整个公司。所以，测试它就比使用传统站内方案时更加重要了。

云备份方案可以解决IT世界中很重要领域的一些棘手问题，不过和所有新架构一样，它不能包治百病。你需要象对待其它业务相关的IT项目一样，对其小心地测试和评估。

使用云作为备份介质

传统的站内备份供应商未曾忽视他们的客户对基于云的备份的兴趣，他们也没有低估把数据转移出机房的需求。他们多数很久之前就开始提供从一个备份服务器复制数据到另一个站点的次级备份服务器的功能。那工作的很好，当然你要有两个机房而且两边都有IT支持人员。

但有些备份供应商只是把云作为另一种介质形式来使用。那意味着在安装你的传统备份架构之后，你可以从磁盘、磁带介质、或从云中恢复。有时候那个第三层是在供应商的数据中心里管理的，而其它的会使用公共存储云架构，例如亚马逊网络服务（ Amazon Web Services - AWS）。

对很多人来说，这是一个很有吸引力的可选项。如果你目前的备份应用已经支持云存储作为一个介质层级，那你所有正在使用的备份代理可以不用改变。你现有的备份服务器还会继续使用，来实现从本地存储快速恢复，而且你现在还有了一个存在机房之外的额外的数据拷贝。（参阅我们的专题“集成的云备份”）

当你的数据已经在云上的时候

备份即服务和混合云的方式都基于一个假设，那就是你的生产数据是在你公司内部的（或者在你的外场员工那里）。但是如果你的生产数据已经在别的地方了，或者其本身就是一个云，那么你的备份模式会大大改变，甚至彻底消失。

如果你在使用在线文件共享，你的主要数据拷贝已经是基于云的了，你的数据可能已经存在于多个数据中心里的你所使用的那种云上。你已经得到了部件级的故障保护，而如果你的供应商支持恢复到之前版本的功能，你可能就不需要这些数据的任何额外的备份了，在线文件共享和备份即服务不可避免地存在交集；例如Mozy最近为他们的备份即服务用户推出了在线文件共享服务。

如果你的数据真的是存在于两个地理位置的，例如 Riverbed在他们的Granite产品中提供的iSCSI扩展技术，通过支持时间点恢复的存储设备，你已经在分公司和数据中心都有数据的拷贝了。

如果你的数据基于云但存在本地，例如使用 Nasuni、 StorSimple和其它供应商的网关设备方案，本地站点内的数据和亚马逊S3(Amazon Simple Storage Service)或者其它的云存储服务同步，每个站点都有原生的灾难恢复能力，简单到只需要打开一个干净的虚拟机并挂载基于云的LUN即可。党人你也可以再用一个站点内部的备份方案来额外备份一份你的数据。

不管你决定如何利用云备份服务，目标都是一样的：把数据转移到机房之外。