◆大数据需不需要备份和灾难恢复？
浏览次数：1736日期：2015-06-03
大数据应用的发展趋势是在拥有大存储容量的同时配备用于执行数据分析的融合硬件设备与分析软件包。这些应用通常不会用于处理运营数据；相反，用户会通过查询数据来分析过去的产品销售、预测趋势和确定未来的客户购买模式。大数据应用通常并不会被定位为关键业务系统，虽然它们也支持销售和营销决策，但是并不会显著影响一些核心运营业务，如客户管理、订单、库存和配送等。
那么，为什么许多领先的企业IT部门都迅速将大数据整合到他们的灾难恢复计划中呢？这些数据量如此之大，会不会给备份带来影响呢？即便是备份了数据，从备份恢复数据是否会花费几天（几周或更长时间）呢？带着这些问题，我们来看一下如何进行大数据的灾难恢复。
数据太大，无法备份
灾难恢复最佳实践包括在指定的时间里将重要数据及时恢复到一致状态的能力。这段时间称为恢复时间目标（RTO），它必须在业务所依赖的运营数据的限制范围之内（最多几个小时）。但是，遇到大数据时该怎么办？大多数公司认为大数据的备份与恢复并不重要。其中包括以下这些原因。
运营系统更重要。在发生灾难之后，最高优先级的工作是恢复那些支持运营系统的数据。这些系统包括会计、订单条目、支付受理、工资等，它们是保证公司正常运营的必要条件。在这些数据恢复之后，第二优先级的工作是支持这些系统的运行。
大数据并不是关键业务系统。预测和趋势分析可能是营销的重要手段，但是这些分析及其相关的查询和用户报表都基于历史数据，而非实时数据。
大数据的体量非常巨大，一个大数据应用所存储的数据量可能是所有运营数据之和的数十倍。这是因为大数据应用工作在数据的历史快照上。十年的历史数据就会包含几千天的快照。它备份在什么介质上，备份需要多长时间，然后需要的备份存储有多大？
备份与恢复流程需要I/O通道容量。在短时间内迁移大容量的数据要求使用较大的容量。备份与恢复会耗尽I/O通道，唯一可行的替代方法是安装足够的附加容量去处理这些任务。
当大数据成为关键业务系统
上面介绍的原因并非适用于所有公司。有一些关注客户的系统也会使用大数据分析，这意味着大数据应用将属于运营处理的一部分。在其他企业中，大数据开始成为一种简单的查询和报表工具。有一些专用查询会慢慢体现其重要作用，然后变成一些常规报表。这些有用的报表会受到管理层的关注，他们会因此将这些报表变成一些重要的操作。最终，管理层会逐渐依赖这些报表来作出运营决策。因此，他们的大数据应用就会逐渐向关键业务系统靠拢。
大数据应用发展成为关键业务系统的趋势是不可避免的。这些应用的安装和配置过程代价高昂且耗费时间，同时也需要由高素质的技术人员来完成。此外，查询数据的业务分析师很少会亲自处理数据。通常他们会使用一些专门用于查询和分析大数据的分析软件包。这些软件同样非常昂贵，同时只有经过大量培训的技术人员才能高效使用这些软件。
公司在大数据应用投入了大量的金钱。公司迫切希望从他们的投资中获取有价值的回报。从数据分析得到的报表可能产生更好的客户服务、更快的产品周转速度和更高的收益。而收益恰恰就意味着关键业务。
大数据备份方法
如果准备在灾难恢复计划过程中恢复全部或部分大数据应用，那么可以考虑选择下面这些备份方法。
最重要的是要记住：大数据主要是历史数据和静态数据。运营数据快照会被提取到一个分段集结区域，进行整理和转换，然后再加载到企业数据仓库和大数据应用中。在此之后，它们都不会更新。这意味着在每一个快照上只需要运行一次备份流程。
最常用的备份方法主要有：
·数据复制。这是一个常用的备份方法。当数据加载到数据仓库或大数据应用程序时，它们会同步传输到一个备份流程中，其中会载入大数据应用程序的一个备份副本。这个流程通常发生在灾难恢复站点中，然后在发生灾难时它仍然保有一份最新的数据。
·虚拟快照。这是一个硬件解决方案，它允许在存储介质上创建整个系统的虚拟备份。数据库写操作会在中断一小段时间，这时管理存储子系统的硬件会对所有文件执行内部复制操作。这个复制流程可能非常快，有时会在几秒钟内完成。在复制完成之后，数据库管理系统又会重新允许执行写操作。
快照提供了超快速的恢复时间，它的假定前提是可以恢复到创建快照的指定时间点。除此之外，恢复到非快照创建的时间点需要有一些方法能够将所有最新数据库变化（日志捕捉）应用到快照中。另一个问题是存储容量。快照可能要求将当前使用的存储加倍。而且，当灾难发生时，当时的快照会作为当前数据，但是还必须分配另一个快照区域，以备应付新的灾难事件。
·本地与远程副本。这是一个经典方法，它由磁盘备份和包含物理磁盘驱动器或数据库的阵列备份构成。DBA使用供应商工具访问那些通常存储为一种压缩私有格式的数据。这些备份会快速地执行和加载，因为它们采用的是内部数据格式。
恢复自动化与测试
灾难计划的另一个重要部分是保证恢复在规定的RTO内完成。对于大数据而言，这通常意味着要使用标准流量或供应商工具实现恢复自动化。聪明的DBA会尽可能自动化更多的任务，从而最大可能减少相对较慢的人为干预。这其中就包括要避免以下行为：
·人工处理备份存储（例如，移动和操作磁带）；
·输入命令行；
·检查纸质报表或文档。
在实现恢复自动化之后，要定期测试、测试再测试。记住，大数据总是在不断地增长，而且随着数据量的增加，备份和恢复时间也会增加。
总结
大数据无论部署还是使用都非常耗费时间、金钱和资源。许多公司迫切希望从这些大投入中获取回报，查询和报表能够提供一些宝贵的洞察力，帮助执行决策、应付变化和获得收益。大数据应用最终会变成关键业务系统。在此之前，一定要保证自己的IT基础架构能够备份和恢复这些数据。
那么，为什么许多领先的企业IT部门都迅速将大数据整合到他们的灾难恢复计划中呢？这些数据量如此之大，会不会给备份带来影响呢？即便是备份了数据，从备份恢复数据是否会花费几天（几周或更长时间）呢？带着这些问题，我们来看一下如何进行大数据的灾难恢复。
灾难恢复最佳实践包括在指定的时间里将重要数据及时恢复到一致状态的能力。这段时间称为恢复时间目标（RTO），它必须在业务所依赖的运营数据的限制范围之内（最多几个小时）。但是，遇到大数据时该怎么办？大多数公司认为大数据的备份与恢复并不重要。其中包括以下这些原因。
运营系统更重要。在发生灾难之后，最高优先级的工作是恢复那些支持运营系统的数据。这些系统包括会计、订单条目、支付受理、工资等，它们是保证公司正常运营的必要条件。在这些数据恢复之后，第二优先级的工作是支持这些系统的运行。
大数据并不是关键业务系统。预测和趋势分析可能是营销的重要手段，但是这些分析及其相关的查询和用户报表都基于历史数据，而非实时数据。
大数据的体量非常巨大，一个大数据应用所存储的数据量可能是所有运营数据之和的数十倍。这是因为大数据应用工作在数据的历史快照上。十年的历史数据就会包含几千天的快照。它备份在什么介质上，备份需要多长时间，然后需要的备份存储有多大？
备份与恢复流程需要I/O通道容量。在短时间内迁移大容量的数据要求使用较大的容量。备份与恢复会耗尽I/O通道，唯一可行的替代方法是安装足够的附加容量去处理这些任务。
当大数据成为关键业务系统
上面介绍的原因并非适用于所有公司。有一些关注客户的系统也会使用大数据分析，这意味着大数据应用将属于运营处理的一部分。在其他企业中，大数据开始成为一种简单的查询和报表工具。有一些专用查询会慢慢体现其重要作用，然后变成一些常规报表。这些有用的报表会受到管理层的关注，他们会因此将这些报表变成一些重要的操作。最终，管理层会逐渐依赖这些报表来作出运营决策。因此，他们的大数据应用就会逐渐向关键业务系统靠拢。
大数据应用发展成为关键业务系统的趋势是不可避免的。这些应用的安装和配置过程代价高昂且耗费时间，同时也需要由高素质的技术人员来完成。此外，查询数据的业务分析师很少会亲自处理数据。通常他们会使用一些专门用于查询和分析大数据的分析软件包。这些软件同样非常昂贵，同时只有经过大量培训的技术人员才能高效使用这些软件。
公司在大数据应用投入了大量的金钱。公司迫切希望从他们的投资中获取有价值的回报。从数据分析得到的报表可能产生更好的客户服务、更快的产品周转速度和更高的收益。而收益恰恰就意味着关键业务。
大数据备份方法
如果准备在灾难恢复计划过程中恢复全部或部分大数据应用，那么可以考虑选择下面这些备份方法。
最重要的是要记住：大数据主要是历史数据和静态数据。运营数据快照会被提取到一个分段集结区域，进行整理和转换，然后再加载到企业数据仓库和大数据应用中。在此之后，它们都不会更新。这意味着在每一个快照上只需要运行一次备份流程。
最常用的备份方法主要有：
·数据复制。这是一个常用的备份方法。当数据加载到数据仓库或大数据应用程序时，它们会同步传输到一个备份流程中，其中会载入大数据应用程序的一个备份副本。这个流程通常发生在灾难恢复站点中，然后在发生灾难时它仍然保有一份最新的数据。
·虚拟快照。这是一个硬件解决方案，它允许在存储介质上创建整个系统的虚拟备份。数据库写操作会在中断一小段时间，这时管理存储子系统的硬件会对所有文件执行内部复制操作。这个复制流程可能非常快，有时会在几秒钟内完成。在复制完成之后，数据库管理系统又会重新允许执行写操作。
快照提供了超快速的恢复时间，它的假定前提是可以恢复到创建快照的指定时间点。除此之外，恢复到非快照创建的时间点需要有一些方法能够将所有最新数据库变化（日志捕捉）应用到快照中。另一个问题是存储容量。快照可能要求将当前使用的存储加倍。而且，当灾难发生时，当时的快照会作为当前数据，但是还必须分配另一个快照区域，以备应付新的灾难事件。
·本地与远程副本。这是一个经典方法，它由磁盘备份和包含物理磁盘驱动器或数据库的阵列备份构成。DBA使用供应商工具访问那些通常存储为一种压缩私有格式的数据。这些备份会快速地执行和加载，因为它们采用的是内部数据格式。
恢复自动化与测试
灾难计划的另一个重要部分是保证恢复在规定的RTO内完成。对于大数据而言，这通常意味着要使用标准流量或供应商工具实现恢复自动化。聪明的DBA会尽可能自动化更多的任务，从而最大可能减少相对较慢的人为干预。这其中就包括要避免以下行为：
·人工处理备份存储（例如，移动和操作磁带）；
·输入命令行；
·检查纸质报表或文档。
在实现恢复自动化之后，要定期测试、测试再测试。记住，大数据总是在不断地增长，而且随着数据量的增加，备份和恢复时间也会增加。
总结
大数据无论部署还是使用都非常耗费时间、金钱和资源。许多公司迫切希望从这些大投入中获取回报，查询和报表能够提供一些宝贵的洞察力，帮助执行决策、应付变化和获得收益。大数据应用最终会变成关键业务系统。在此之前，一定要保证自己的IT基础架构能够备份和恢复这些数据。
