背景在上一篇文章裡面已經提過了。【參考：記一次mysql資料庫被勒索（上）】
現在面臨的問題是nextcloud沒有mysql資料庫，用不起來了。
因為檔案沒丟，一種方法是啟動新的mysql資料庫，把檔案重新提交一次。
為了程式設計師的面子，沒有選擇這麼沒技術含量的方法。我想通過恢復mysql資料庫來解決這個問題。
恢復mysql資料庫
於是，在mysql目錄裡面找找看，發現了一堆binlog檔案。上網查了一下，binlog檔案裡面好像有記錄mysql的操作，可以用來恢復資料庫。
檢視binlog：# ll -th binlog.*
先把最近的binlog轉成SQL：
mysqlbinlog /var/lib/mysql/binlog.000011 > /var/lib/mysql/11.sql
開啟11.sql，裡面果然有被黑的記錄。建立了一個“PLEASE_READ_ME_VVV"的資料庫和"WARNING"的資料表。
看來有希望。
把所有binlog都轉成SQL，檢視什麼時候建立nextcloud資料庫的。
# grep -i "create database" *.sql
注：需要找到第一次建立nextcloud庫的記錄，這個記錄會包含建表操作，否則恢復資料時會報如下資料表找不到的錯誤：
順便找一下，什麼時候被刪除資料庫的。
# grep -i "drop database" *.sql
檢視11.sql，找到黑客入侵前的日誌，只恢復到這個時間點的資料（之後的資料也恢復的話，相當於又刪除一遍資料）
只轉換部分binlog的話，可以使用--start-position 和 --stop-position來界定，引數的值就是上圖紅框處，# at 82015的值。
或者也可以全部轉換成SQL後，手動將SQL中不要的操作刪除掉。
# mysqlbinlog --stop-position=82015 /var/lib/mysql/binlog.000011 > /var/lib/mysql/11_1.sql
根據上面的grep結果，我只需要恢復5~10的全部LOG，以及11的部分LOG（刪除黑客操作的部分）。
將5~11的binlog轉換成SQL準備好，就可以開始恢復了。
恢復過程：
1，刪除nextcloud倉庫以及PLEASE_READ_ME_VVV倉庫；
mysql> drop database `nextcloud`;
mysql> drop database `PLEASE_READ_ME_VVV`;
2，載入5~10和11_1的SQL檔案。
mysql> source /var/lib/mysql/5.sql;
。。。
恢復完成後，檢視一下nextcloud倉庫，資料表已經恢復回來了。哦耶！
隨著資料庫的恢復，心情也逐漸暢快起來，就是不能向惡勢力低頭嘛，哈哈哈。
----------------------------------------------------------------------------------------------------------------------------------
本來，至此，nextcloud應該就可以直接恢復成功了。然而。。。又出么蛾子了。。。。
nextcloud還是顯示"Internal server error" ，檢視日誌發現，錯誤變成了mysql訪問拒絕。
這個地方報錯原因是密碼錯誤。因為nextcloud在之前重新配置過資料庫導致的。參考：記一次mysql資料庫被勒索（上）
真的是手賤了。。。這個問題，又費了九牛二虎之力才找到原因，好在最後也恢復成功了。
這個留在下篇再寫吧。