大数据（big data），指无法在可承受的时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力来适应海量、高增长率和多样化的信息资产。
数据库（Database）是按照数据结构来组织、存储和管理数据的仓库，它产生于距今六十多年前，随着信息技术和市场的发展，特别是二十世纪九十年代以后，数据管理不再仅仅是存储和管理数据，而转变成用户所需要的各种数据管理的方式。数据库有很多种类型，从最简单的存储有各种数据的表格到能够进行海量数据存储的大型数据库系统都在各个方面得到了广泛的应用。
大数据应用的发展趋势是在拥有大存储容量的同时配备用于执行数据分析的融合硬件设备与分析软件包。这些应用通常不会用于处理运营数据;相反，用户会通过查询数据来分析过去的产品销售、预测趋势和确定未来的客户购买模式。大数据应用通常并不会被定位为关键业务系统，虽然它们也支持销售和营销决策，但是并不会显著影响一些核心业务，如客户管理、订单、库存和配送等。
我们来看一下如何进行大数据的灾难恢复。 数据太大，无法备份
灾难恢复最佳实践包括在指定的时间里将重要数据及时恢复到一致状态的能力。这段时间称为恢复时间目标(RTO)，它必须在业务所依赖的运营数据的限制范围之内(最多几个小时)。大多数公司认为大数据的备份与恢复并不重要。其中包括以下这些原因。
运营系统更重要。在发生灾难之后，最高优先级的工作是恢复那些支持运营系统的数据。这些系统包括会计、订单条目、支付受理、工资等，它们是保证公司正常运营的必要条件。在这些数据恢复之后，第二优先级的工作是支持这些系统的运行。
大数据并不是关键业务系统。预测和趋势分析可能是营销的重要手段，但是这些分析及其相关的查询和用户报表都基于历史数据，而非实时数据。
大数据的体量非常巨大，一个大数据应用所存储的数据量可能是所有运营数据之和的数十倍。这是因为大数据应用工作在数据的历史 快照上。十年的历史数据就会包含几千天的快照。它备份在什么介质上，备份需要多长时间，然后需要的备份存储有多大？
备份与恢复流程需要I/O通道容量。在短时间内迁移大容量的数据要求使用较大的容量。备份与恢复会耗尽I/O通道，唯一可行的替代方法是安装足够的附加容量去处理这些任务。
大数据的备份方法：如果准备在灾难恢复计划过程中恢复全部或部分大数据应用，那么可以考虑选择下面这些备份方法。最重要的是要记住：大数据主要是历史数据和静态数据。运营数据快照会被提取到一个分段集结区域，进行整理和转换，然后再加载到企业数据仓库和大数据应用中。在此之后，它们都不会更新。这意味着在每一个快照上只需要运行一次备份流程。
最常用的备份方法主要有： 数据复制。这是一个常用的备份方法。当数据加载到数据仓库或大数据应用程序时，它们会同步传输到一个备份流程中，其中会载入大数据应用程序的一个备份副本。这个流程通常发生在灾难恢复站点中，然后在发生灾难时它仍然保有一份最新的数据。
虚拟快照。这是一个硬件解决方法，它允许在 存储介质上创建整个系统的虚拟备份。数据库写操作会在中断一小段时间，这时管理 存储子系统的硬件会对所有文件执行内部复制操作。这个复制流程可能非常快，有时会在几秒钟内完成。在复制完成之后， 数据库管理系统又会重新允许执行写操作。快照提供了超快速的恢复时间，它的假定前提是可以恢复到创建快照的指定时间点。除此之外，恢复到非快照创建的时间点需要有一些方法能够将所有最新数据库变化(日志捕捉)应用到快照中。另一个问题是存储容量。快照可能要求将当前使用的存储加倍。而且，当灾难发生时，当时的快照会作为当前数据，但是还必须分配另一个快照区域，以备应付新的灾难事件。
本地与远程副本。这是一个经典方法，它由 磁盘备份和包含物理磁盘驱动器或数据库的阵列备份构成。DBA使用供应商工具访问那些通常存储为一种压缩私有格式的数据。这些备份会快速地执行和加载，因为它们采用的是内部数据格式。
总结 大数据无论部署还是使用都非常耗费时间、金钱和资源。许多公司迫切希望从这些大投入中获取回报，查询和报表能够提供一些宝贵的洞察力，帮助执行决策、应付变化和获得收益。大数据应用最终会变成关键业务系统。在此之前，一定要保证自己的IT基础架构能够备份和恢复这些数据。