优选备份的方案试试开源设备.docVIP

优选备份的方案试试开源设备 　　过去，在中小企业环境下的备份很简单：装好磁带和自动加载机，在备份软件中排好备份计划，就可以进行备份了。但这样的日子早已远去，备份已经变得并不简单。 　　 　　备份不简单 　　 　　备份现在是一项重要操作，下面几个因素导致了曾经很简单的备份过程变得不简单。 　　管理复杂的备份程序。过去备份用的是磁带，而现在使用磁带、虚拟磁带库（VTL）、SAN、NAS、DAS和云等。选择哪一种取决于诸多因素：已经拥有什么存储介质？熟悉什么介质？数据是主数据还是二级数据？数据是否受管制或很宝贵？有多少时间可用于备份？多个应用需要多套备份程序，而备份程序也会发生变化，这取决于服务器的位置、应用类型、数据大小、服务级别协议（SLA）和备份的目标。有多套程序的复杂情况加大了管理及核对的难度。 　　应对恢复问题。如果想通过备份进行恢复，就必须保护好备份。最基本的程序是把不常用的备份磁带保存在异地，但这带来了迅速恢复优先级数据的问题。异地保存优先级较低的数据完全可以，但应确保关键数据受保护，而且触手可及，以便快速恢复。这就要求构建能够几乎立即恢复关键数据的二级站点，不过这么做很花钱。如果在二级站点使用价格较低的硬件，可以降低成本。由于费用高昂，二级站点这种架构通常适用于那些资金充裕的企业。 　　以应用为中心的备份。不同的应用需要不同的备份机制来处理，而传统的备份软件是否易于支持，这点还不好说。比如，Oracle备份不同于VMware备份，VMware备份不同于SharePoint备份，而SharePoint备份又不同于文件服务器备份。备份软件应该借助向导、模板以及面向这些流行而有挑战性的应用的内置前端程序，来简化这项任务。把这种简化工作所需要的指令编入到自行开发的备份脚本既困难又费时，而传统备份软件常常缺少Oracle等应用的重要的前端程序。 　　 　　常用的备份方案 　　 　　不妨看一下中小企业常用的几种选择： 　　 　　第一种方案：传统备份 　　传统备份厂商牢牢占稳了企业级领域。多年来，企业一直在安装许多这类备份产品，尽管它们常常很昂贵、很复杂，又基于需要投入大量开发和维护工作的专有代码。备份软件扩展、升级后，用户还必须适应变化，购买新的功能。 　　有时企业被厂商的产品牢牢锁定，不值得推倒重来、更换新的备份产品或程序。但有时，既有的产品成本高，又复杂，这时就值得关注其他方案。进行选择时，要考虑将来被某种专有格式锁定而带来的成本。当然，如果你还没有被某一款备份软件锁定，那么选择余地就比较广泛。传统备份是一种流行的选择，但不是惟一的选择。 　　 　　第二种方案：自行编写备份脚本 　　中小企业或大企业的分支业务部门决定编写备份脚本可能是出于诸多原因：IT人员喜欢编写脚本、想省钱、需要定制，以及相对比较容易。 　　如果一家公司发展势头良好，那么自行编写的备份脚本就可能带来问题。脚本编写人员常常从某个应用入手，利用自带拷贝工具来编写备份脚本。不过，一旦花了时间编写了某段脚本，其维护脚本则是责无旁贷的事。而当其他同样值得备份的应用也需要编写备份脚本，又会出现怎样的一幕呢？可能得支持一大堆应用程序、服务器、恢复时间目标、恢复点目标和备份目标。而这仅仅针对磁带，如果需要备份测试VMware环境，又会怎样呢？要是备份到新的VTL、甚至备份到云端呢？脚本编写任务从来不该占用整个工作日。 　　 　　第三种方案：自己动手的开源备份 　　避开脚本编写难题的一条途径是，采用开源备份方案。这有诸多优点，因为它提供了现成的代码库和活跃的用户及开发人员社区。至少可以说，从购置的角度来看，开源成本非常低。 　　开源备份的购置成本也许很低，但未必划得来。你可能会遇到与自行编写备份脚本同样的一些问题，仍不得不对代码库进行修改，以便手动更新代码，还得密切关注社区或自行编写的模块，还得改动代码，以满足不同应用的需要。要是扩增代码，以满足多个备份目标和流程的需要，还会面临复杂性问题。这一切在动态环境下可能不是很划算。 　　 　　第四种方案：开源备份设备 　　开源软件带来了自己的一系列难题，但它可以为备份设备充当良好的基础。按这个观点，购买的预先配置的备份设备应基于开源代码。开源特性使得购置和日常维护费用很低，而设备可以进行配置及定制。开源设备将不同的备份程序和自行编写的脚本换成适用于多个系统和应用的一个集中式备份实用软件。而且不像脚本或开源备份代码，在客户服务方面光靠自己的力量。 　　在关注基于开源的备份设备时，需要评估以下这些特性和功能： 　　部署和使用的简易性。系统应该易于使用向导、模板和应用前端程序来构建。集中式控制台能够进行高效的管理和灵活安排，比如先备份到磁盘，后备份到磁带，或者先备份到缓存，后安