背景在上一篇文章里面已經提過了。【參考：記一次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數據庫被勒索（上）
真的是手賤了。。。這個問題，又費了九牛二虎之力才找到原因，好在最后也恢復成功了。
這個留在下篇再寫吧。