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

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

数据库基本知识

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

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

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

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

未雨绸缪

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

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

深入存档

要考虑的下一个方面是存档：从联机系统删除不活动或过时的记录。之所以可能需要这么做，是由于贵公司的信息保留政策、性能问题(大型报表尤其如此)，或者需要降低存储费用。我还没有遇到过这种情形：整整七年一动也没动的数据需要保留在CRM系统上;某些企业可能根本不需要再看到时间在两年以上的数据。

但CRM数据根本不是简单的数据库;从系统删除记录会带来复杂的后果。CRM数据库包含的表在10个到200个之间――具体取决于提供商，用户级对象可能会在表与表之间创建一些确实很有趣的指针。由于这个原因，绝对不能从系统删除一些CRM对象。我们进一步建议，Account(客户)和Opportunity(销售机会)这两类对象绝对不该删除，因为它们是好多指针的核心。

进行存档及从系统上删除最容易的部分是处于指针树上叶节点处的对象。比方说，对旧的附加文档、电子邮件、笔记注释和销售线索进行存档相当简单。不过，进行存档的整个意义在于能够在需要时获得相应数据!!!所以，确保每个存档都含有一个“使用说明”文件，里面有说明如何存档的核对一览表。毕竟六个月过后，没有人会记得如何拆开或解释存档库中的数据。

至于对CRM系统来说比较核心的对象，进行存档可能相当复杂。比方说，在Salesforce.com中合理存档“Contacts”(联系人)就需要提取10次，以及一系列必须按顺序进行的删除操作。

还有什么其他方法吗？在许多情况下，隐藏不需要的数据比从系统实际删除该数据来得容易。隐藏数据通常需要设置特殊的记录类型值，以表明这是不活动的数据。这个策略的关键在于，确保所有视图、报表、工作流、触发阈值和外部接口都已经过了改动，以便把有标记的记录排除在外。这听上去可能很复杂，但如果借助适当的配置管理，这个方法还是要比对嵌入得最深的CRM数据　进行存档来得简单。
 

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友