1 調高osd的日志等級
加上紅框那一行就可以了
osd的日志路徑：/var/log/ceph/ceph-osd.3.log
注意：加上了這一行后日志會刷很多，所以要特別注意日志容量的變化，以防把var目錄寫滿了
2 缺少osdmap或者錯誤的osdmap
從osd日志中發現這兩種錯誤都是屬於osdmap不正常，可以從其它正常osd上拷貝osdmap到對應啟動錯誤的osd上，假設不正常的osdmap序號是816，上圖的是27601和671651
如以下圖：
在一個正常osd上如osd.4上用find命令查找816的osdmap
接着用scp命令將對應的文件拷貝到對應的啟動錯誤的osd對應的目錄下
3 修復leveldb文件
這種錯誤屬於缺少omap的sst文件，可嘗試用leveldb自帶的修復工具來修復
安裝leveldb模塊：
yum install epel-release -y
yum install python-pip python-devel gcc gcc-c++ -y
pip install --upgrade pip
pip install leveldb
注意：用pip命令時可能出現這樣的超時錯誤，如果出現則重新執行pip命令即可
修復命令執行（假設是修復osd.0）：
按下圖紅框所示執行：
修復完后可查看下修復的目錄下是否有多出來的ldb后綴的文件，如果有則通過mv改名將后綴改為sst
mv /var/lib/ceph/osd/ceph-0/current/omap/000009.ldb /var/lib/ceph/osd/ceph-0/current/omap/000009.sst
改文件名后再重啟該osd.0看看。
如果會報下面這樣的錯，則像第2點一樣的步驟拷貝對應的osdmap過來然后重新啟動
4 元數據校驗錯誤
該錯誤是由於遍歷加載pg的omap時出錯導致osd起不來，如上圖的報錯是1.13這個pg報錯導致的，如果只是單個pg有問題，在其它osd上有存儲，那大可去除該pg，但我們遇到的在客戶那里的情況是每個pg都有問題，那就感覺不是某個pg的問題了，是一個osd的共性問題，很有可能是leveldb的問題，但用leveldb修復卻不能修復好，還未有解決方法
5 Inconsistent的pg
有這種pg出現在ceph -s命令的輸出中應該可以看到有類似1 pgs inconsistent這樣的描述，使用命令：
ceph health detail | grep inconsistent
找出inconsistent的pg，比如是pg 1.1
一般情況下使用以下命令即可修復不一致的pg：
ceph pg repair 1.1
執行完后等待一段時間可能會自動修復好
如果一段時間后也沒修復好，則可以嘗試再執行一遍，如果還沒修復好則需要找出不一致的object來處理了
首先從osd的日志里找到inconsistent的obj
列出該object：
如果是3副本，則可以通過md5計算下哪個是不一致的，從而刪除掉該object讓其同步另外兩個的即可，但這里的錯誤其實並不是object文件內容上的不一致，而是缺少object文件的一些文件屬性，查看正常的：
異常的則沒有紅框里的屬性且用object-ceph-tool查看時會報這樣的錯：
可以將正常的object拷貝覆蓋異常的object：
注意：這里要用rsync來拷貝，這樣文件屬性也才能拷貝過去
6 pg down的處理
可先通過ceph pg query x.x來看某pg的情況，翻到最后面的recover項會有說明該pg為什么down且建議你如何恢復的說明
pg down的意思是含有最新數據pg的對應的osd沒起來，最簡單的做法就是將該osd拉起來，但如果該osd實在拉不起來且已經把它移出集群了，則可以告訴集群那個主pg的osd已經丟失了，讓其它副本的pg作為主osd，比如osd.5已經起不來了則：
ceph osd lost 5 --yes-i-really-mean-it
當然這樣也意味着主pg上有一些數據副pg是沒有的，可能會有一些數據丟失，如果想要保險，則可以通過object-ceph-tool工具將pg從掛掉的那個osd上先導出來，然后再通過該工具導入到正常的有該副本的osd上即可
注意：如果確實想把某osd標記為lost，則應該那個osd從osd crush中remove出去才有效
7 Journal問題
由日志可比較明顯的看出是在加載journal數據的時候crash了，可以通過給osd替換journal的方式來恢復osd，但這樣做也就意味到需要丟棄掉journal里的數據
恢復方法（以osd.0為例）：
（1） 停止服務
/etc/init.d/ceph stop osd.0
（2） 替換journal
# 這行--flush-journal很有可能報錯，因為本身就是因journal而crash的，報錯可以不用管它，繼續下一條命令
ceph-osd -i 0 --flush-journal
rm -rf /var/lib/ceph/osd/ceph-0/journal
touch /var/lib/ceph/osd/ceph-0/journal
ceph-osd -i 0 --mkjournal
（3） 啟動服務
/etc/init.d/ceph start osd.0
8 終極恢復方法
假設很不幸，你的osd掛了很多，橫跨了多個故障域，超出了你的副本數設置，通過數據均衡方式已經恢復不了你的數據了，則可以嘗試使用這種方法，它就算你的全部osd掛掉也能恢復，但前提是你的osd能夠掛載並能訪問到osd的current目錄里面的object數據文件，且存儲引擎用的是filestore
該方法的原理是通過將一個rbd的所有object收集起來重新拼接成一個raw格式的文件，然后可將該文件導入到虛擬存儲中重新成為一個rbd
腳本文件下載地址：https://github.com/luohaixiannz/ceph-recovery-master
情景假設：
假設虛擬存儲中一共有3個osd，osd.0、osd.1和osd.2
使用方法：
（1）找一個空間大一點的目錄，需要比ceph df中顯示的容量要大
比如這里顯示的是103M，則我們選的目錄的存放的空間應該大於這個容量的2倍以上，因為我們拼接后輸出的文件也存放到該目錄下
解壓腳本文件到該目錄
（2） 創建目錄
cd ceph-recovery-master
mkdir outputs
mkdir osds
cd osds
mkdir osd0 osd1 osd2
cd ..
通過scp的方式將3個osd的current目錄拷貝到對應的剛剛創建的osd目錄下，比如osd0的（其它節點上的則用scp）：
cp -r /var/lib/ceph/osd/ceph-0/current ceph-recovery-master/osds/osd0/
（3） 運行腳本
a. 收集osd里的object數據
執行命令：
./collect_files.sh osds
b. 查找要恢復的rbd
找虛擬機的系統盤可按如下圖的命令找對應關系：
如果是找數據盤的則按如下圖的命令找對應關系：
如果是鏡像的則：
上面列舉了我們知道名字如何找到對應的uuid，這個uuid是用來下一步恢復rbd時使用
c. 恢復rbd為一個raw的文件
比如我們想恢復testooo這個虛擬機的系統盤，則按上圖那些操作我們可以得知它對應的uuid是a4f0234a-e900-4d3c-a684-4d9fe4d1abc3
則執行如下命令：
獲取到這個虛擬機系統盤對應的rbd的uuid
執行命令恢復這個rbd為一個raw格式的文件：
這里解釋下該命令傳遞的參數含義：
（1）那個disk.id那一串就是我們上面找的rbd對應的uuid
（2）參數2表示2M，以M為單位，代表的含義是這個rbd的object是定義為2M的，這個可以通過rbd info pool_name/rbdname里可以看到
（3）參數5表示該磁盤的大小，以G為單位
命令執行完成后，腳本會將拼接后的raw文件放在outputs目錄下：
d. 驗證rbd是否正常
如果你當前的ceph環境是異常的，則很明顯你不能用當前ceph環境來驗證，可以通過其它ceph環境來驗證該raw文件是否是正常的。
ceph環境下的驗證方法，先導入該raw文件為一個rbd
查看是否導入進去了：
然后新創建一個虛擬機，然后找到它的rbd名字，然后通過rbd rename的方式交換兩個rbd，然后開啟這個虛擬機看是否正常即可
數據盤的方式也是用替換rbd的方式來驗證的
上面說的是用ceph環境來驗證到處的rbd是否是正常的，如果當前ceph不可用則可用本地存儲來驗證，本地存儲使用的磁盤格式是qcow2的，所以我們先要將raw格式的磁盤轉換為qcow2格式的：
然后新建一個本地虛擬機，用轉換出來的qcow2文件替換掉它的qcow2文件，然后開啟虛擬機檢查下磁盤是否是正常的
6 pg down的處理