灾难恢复让SaaS不再沦陷于停用？

软件即服务(SaaS)应用程序的出发点是：与应用程序有关的一切都在云中，所以数据的维护、冗余和恢复均由SaaS提供商负责。但实际情况比较复杂，所以部署的大型SaaS环境中出现了值得关注的微妙之处。虽然本文关注的是Salesforce.com的应用程序，但汲取的经验教训可以运用于几乎任何SaaS提供商。　　

数据库基本知识

　　不妨先从基本方面即应用程序底层的数据库聊起。为了确保服务连续性，几乎任何SaaS提供商针对客户数据都要有集群或复制策略。 Salesforce.com持续不断地复制用户数据，其数据中心提供了相当高的冗余性。由于它采用了集群多租户架构，所以备份和冗余服务相当复杂–而且它有许多工作要做。主生产环境集群可能不得不处理1万个客户和10万个用户的交易事务。

　　Salesforce.com在确保正常工作时间方面有着出色的记录。

　　虽然SaaS应用程序中包含了免费的数据备份服务，但只有因提供商的失误而需要恢复时，数据恢复服务才是免费的。如果客户因自身的失误而需要把数据恢复到某个历史时间点，那么恢复这些数据需要另行收费。考虑到随时都有数量众多的同步备份线程，找出三个星期前你数据记录的历史状态面临的复杂性也就可想而知了。

　　所以汲取的第一个经验教训就是，定期对你自己的数据进行备份。如果你的SaaS提供商有自动导出或存档功能，可以把数据备份到本地文件存储系统，就要使用该功能。要是没有，可以使用高速数据装载工具(data loader)。如果是客户关系管理(CRM)系统，周六上午清晨进行全面的每周快照(snapshot)最稳妥;我们通常建议保留六个月的备份文件。别忘了制定一项策略来备份附件(以及对象模型中的附件指针)。

　　未雨绸缪

　　但问题可没有这么简单，因为势必会出现这么种情况：你需要某些数据，但标准的导出工具却忽视了这部分数据。你确实需要每个表中每个部分的数据，包括管理日志。比方说，由于一名满腹牢骚的员工提出诉讼，我们的一个客户正处于出示证据的阶段。该客户需要证明：这名员工每次都没有按公司要求登录进入到系统。整整两年都是这样!从SaaS提供商恢复这部分数据所需要的费用高得连律师都觉得不好意思。

　　此外，SaaS备份系统不会对系统的对象模型、元数据、定制元素、报表定义或你的代码拍快照。虽然这些数据不需要每个星期都进行备份，但为了便于配置控制，每个星期备份并没有坏处。备份这些数据可能需要使用一些外部实用工具，通过应用程序的应用编程接口(API)来提取数据，不过这些实用工具通常是开源工具，不收费。

未经允许不得转载：DOIT » 灾难恢复让SaaS不再沦陷于停用？