HDFS和Hbase误删数据恢复
1.hdfs的回收站机制
客户有时会误删一些数据，在生产环境下，误删数据会造成非常严重的后果。
在hdfs上有一个回收站的设置，可以将删除的数据存在目录”/user/$
| fs.trash.interval=0 以分钟为单位的垃圾回收时间，垃圾站中数据超过此时间，会被删除。如果是0，垃圾回收机制关闭。可以配置在服务器端和客户端。如果在服务器端配置trash无效，会检查客户端配置。如果服务器端配置有效，客户端配置会忽略。也就是说，Server端的值优先于Client。 如有同名文件被删除，会给文件顺序编号，例如：a.txt,a.txt(1) |
| fs.trash.checkpoint.interval=0 以分钟为单位的垃圾回收检查间隔（这个应该是检查回收站过期的数据定期的删除。）。应该小于或等于fs.trash.interval。如果是0，值等同于fs.trash.interval。该值只在服务器端设置。 |
如果disable+drop误删了hbase表数据，数据不会放到回收站中，hbase有自己的一套删除策略。
2. 误删HBase表的恢复
HBase的数据主要存储在分布式文件系统HFile和HLog两类文件中。Compaction操作会将合并完的不用的小Hfile移动到<.archive>文件夹，并设置ttl过期时间。HLog文件在数据完全flush到hfile中时便会过期，被移动到.oldlog文件夹中。
HMaster上的定时线程HFileCleaner/LogCleaner周期性扫描.archive目录和.oldlog目录, 判断目录下的HFile或者HLog是否可以被删除，如果可以,就直接删除文件。
关于hfile文件和hlog文件的过期时间，其中涉及到两个参数，如下：
（1）hbase.master.logcleaner.ttl
HLog在.oldlogdir目录中生存的最长时间，过期则被Master的线程清理，默认是600000（ms）；
（2）hbase.master.hfilecleaner.plugins
HFile的清理插件列表，逗号分隔，被HFileService调用，可以自定义，默认org.apache.hadoop.hbase.master.cleaner.TimeToLiveHFileCleaner。
反编译hbase的代码，在类org.apache.hadoop.hbase.master.cleaner.TimeToLiveHFileCleaner中，可以看到如下的设置：
默认hfile的失效时间是5分钟。由于一般的hadoop平台默认都没有对该参数的设置，可以在配置选项中添加对hbase.master.hfilecleaner.ttl的设置。
实际在测试的过程中，删除一个hbase表，在hbase的hdfs目录下的archive文件夹中，会立即发现删除表的所有region数据（不包含regioninfo、tabledesc等元数据文件），等待不到6分钟所有数据消失，说明所有数据生命周期结束，被删除。在hfile声明周期结束到被发现删除中间间隔不到一分钟。
下面以星环的TDH（transwarp data hub）为例讲一下hbase（星环版本中为hyperbase）表数据恢复的具体过程。
TDH的hbase在hdfs上数据目录如下：
表的存储位置为/hyperbase1/data/default/<表名>。
Hbase表在hdfs的文件结构：
包括表的描述的文件夹.tabledesc，一个临时的文件夹.tmp（从后台日志中看到，删除的时候数据会进行archiving归档，归档过程中数据会暂时存储到这个文件夹中），和region数据。打开任何一个region的文件夹，里面包含该regioninfo文件和列族命令的文件夹，一个列族命令的文件夹应该就是一个store，里面有若干的storefile（对应hfile），如下图所示。
Disable+drop删除表test1，下面介绍下恢复过程。
第一步：抢救数据
保证在删除表之后的5分钟之内将hdfs目录/hyperbase1/archive/文件夹下的数据拷贝到/tmp下。
第二步：新建同名和同列族的表
第三步：将抢救下来的region数据拷贝到hbase表对应的目录下
第四步：元数据修复
查询执行修复的帮助命令，
sudo -u hbase hbase hbck –help
由于缺少regioninfo信息，不能直接用hbck –fixMeta修复。
尝试先用fixHdfsOrphans,fixTableOrphans,fixMeta的顺序进行修复，失败。只能用-repair修复，但是内部的执行顺序可能不对，执行一遍失败，多执行几遍，成功。