WARNING! File system needs to be upgraded. You have version null and I want version 7. Run the '${HBASE_HOME}/bin/hbase migrate' script.
不用担心，其实你只是缺少个正常的hbase.version文件！
机房整体停电，集群所有节点都挂掉了。这种情况很少见，但是在管理不善的实验室也会时有发生。所以要沉着应对，相信hadoop的容灾性，一定能恢复数据。
hdfs的备份数只有2，长期在跑的有个数据不大的入库程序，节点很少才5个。
首先启动hadoop之后先运行
bin/hadoop dfsadmin -safemode wait
等待其退出安全模式，发现半分钟后没有反映，意识到肯定是出问题了在运行：
bin/hadoop fsck /
检查一下hdfs的健康状态，发现有很多corrupt blocks，不过还好备份数大于1.此时，hdfs需要自动的把备份数增加到2，所以需要对数据进行写操作，必须退出安全模式，于是：
bin/hadoop dfsadmin -safemode leave
关闭之后等待集群把数据备份好，达到2，吃个饭回来，运行：
bin/hadoop fsck -move
把那些破坏的块移到/lost+found这个目录下面，启动Hbase，发现Hmaster启动之后就悄悄挂调了，查看日志：
WARNING! File system needs to be upgraded. You have version null and I want version 7. Run the '${HBASE_HOME}/bin/hbase migrate' script.
而zk日志显示 client端关闭了session。很多人按照他的提示运行了migrate脚本，实际上这个会报错：ClassNotFound。这就奇怪了，文件系统居然要求升级，这很不科学。我看很多网友的做法是先把/hbase清理调，然后重启就好了，但是以前的数据就丢失了，这更不科学。于是我：
bin/hadoop -ls /hbase
发现/hbase/hbase.version已经消失了，这才恍然大悟，原来是之前的这个文件可能被损坏了，去/lost+found目录找确实能找到，但是这个文件似乎出了问题，-ls它也看不到。于是想到一个办法，我做了以下操作：
bin/hadoop fs -mv /hbase /hbase.bk
重启HBase，这时就生成了/hbase/hbase.version文件，然后：
bin/hadoop fs -cp /hbase/hbase.version /hbase.bk/
bin/hadoop fs -rmr /hbase
bin/hadoop fs -mv /hbase.bk /hbase
这样再次重启HBase，发现Hbase开始splitting hlogs，数据得以恢复。