当实际项目上线到生产环境中，难以避免一些意外情况，如数据丢失、服务器停机等。对于系统的搜索服务来说，当遇到停机的情况意味着在停机这段时间内，用户都不能通过搜索的相关功能进行访问数据，停机意味着将这一段时间内的数据服务完全停止。如果项目是互联网项目依赖于用户数量，这将严重影响用户访问和用户的产品体验。
针对于这种实际情况，在实际的项目开发维护过程中，如果系统使用的大数据平台是Cloudera公司是CDH，可以考虑使用Cloudera Search来进行数据的增量备份和数据恢复工作。Cloudera Search是Cloudera公司基于Apache的开源项目Solr发布的一个搜索服务，安装非常简单，通过Cloudera Manager的管理页面就可以进行一键式安装，本文将对使用Cloudera Search进行各个应用场景做灾备的方案一一介绍。
1.HDFS - HDFS
一般情况下，一个大数据项目中所有用到的原始数据都会存储HDFS中（Hive和HBase存储也是基于HDFS存储数据）。对HDFS做灾备和数据恢复最直接的方式是在源HDFS集群和备份HDFS集群之间设置数据定期增量更新，例如时间Cloudera BDR工具，基础数据备份之后可以选择使用MapReduce Indexer或者Spark Indexer对备份HDFS集群中的同步过来的原始数据建立索引并追加到和备份HDFS集群同一集群中的正常运行的Solr服务中。这样在原始集群故障后，可以从原始集群的Solr服务切换到备份集群的Solr服务，从而达到不影响用户使用搜索服务的需求。
这种情况存在一个问题就是我的原始集群中数据有新产生的数据，还没来得及同步到备份HDFS集群中，这时发生原始集群发生故障会切换到备用集群会导致数据缺失，导致这种情况有两个方面的原因，一是设置的在两个集群间增量同步数据的传输频率，这也是主要因素。二是使用MapReduce或者Spark建立索引并加到Solr中需要多久的时间。
下图是一个具体的例子，文件A存储在HDFS中，通过Cloudera BDR工具进行数据文件的定期备份，将它备份到数据备份用的HDFS集群中。在两个集群中使用Spark或者MapReduce对新文件建立索引，并将新建立的索引添加到各自集群中的Solr服务里提供搜索功能。
图1
2.HBase - HBase
如果数据存储在HBase表中，并且希望可以对这些数据进行搜索，这种场景使用Solr集成HBase，可以实现大数据量快速检索，替代HBase中的列值过滤器，并且HBase在Rowkey设计中也会更加容易，只需要保证每一行的唯一性就可以。
从灾备的角度来看，HBase本身就具备将数据备份到恢复集群的能力，所以对搜索HBase的搜索服务需要做的就是及时同步数据到恢复集群，并在恢复集群的Solr服务上建立索引。HBase集群间的数据同步取决于两个HBase集群之间的网络。
用户每次写入到HBase的数据同步到HBase恢复集群（可以使用HBase自带的hbase.replication配置项实现），集成使用Cloudera Search和同集群Solr服务实时监听建立索引的机制相同。同理在HBase恢复集群也需要实时监听数据变换，为新数据建立索引，可以采用HBase协处理器或者Cloudera的Key-Value Store Indexer组件实现。
图 2
3.Solr - Solr
搜索服务灾备一方面是对基础数据进行同步和备份，一方面则是对索引进行备份，Cloudera Search 实现了索引备份的方案，使用索引备份工具可以高效的将索引文件复制到其他位置，例如S3或ADLS，但是在做灾备的场景下，你的恢复集群很可能是一个HDFS集群，在需要切换备用集群时，需要将索引加载到备用集群的Cloudera Search 服务中。只要索引文件加载到了Solr中，就可以为用户提供搜索服务。
备份的操作是基于Solr的快照功能，Cloudera Search允许为当前Solr中的所有数据做快照。之后使用hadoop distcp命令将索引和相关的元数据文件复制到别处（其他的HDFS集群）。
由于创建快照是对数据和元数据的保留，可能不是完整的副本，因此在这种情况下两个集群数据同步的延迟取决于备用集群上的可以Solr服务需要多长时间将索引副本加载到集群的Cloudera Search服务中。
总结来说备份Solr数据的步骤如下：
a) 原始集群创建快照
b) 准备要导出的快照
c) 将快照导出到本地集群或者远程集群（hadoop distcp命令）
图 3
个人建议：
项目上线后建议定期进行系统的基础数据备份和索引数据备份。原始数据计算使用过后建议全量保留，这是为了避免后续想要更改数据计算方式却没有原始数据的情况。
来源：oschina
链接：https://my.oschina.net/u/4408243/blog/3978523