ibd 檔案被刪除了，該往哪個方向逃跑？
實驗
先來建乙個測試庫：
我們在這裡開啟了 innodb_file_per_table，但這個引數並非本實驗所必須，只是為了演示方便。
然後模擬乙個業務壓力：
現在刪掉相關的表檔案：
檢視一下 mysql 占用的控制代碼：
找到被刪除的表：
可以看到，除了臨時表，被我們手工刪除的表也在其中，對應檔案控制代碼號 54。
現在我們把資料庫的流量鎖起來（如果使用了支援 offline_mode 的版本，可以設定 offline_mode）：
現在記錄一下表的記錄數和校驗值，以便跟恢復後的資料比較：
現在通過檔案控制代碼找到消失的資料檔案，並將其複製出來（此處注意磁碟空間）：
現在可以將資料庫停下來，把恢復的資料複製到資料目錄中，啟動資料庫：
看看資料是否正常：
看起來還不錯。
實驗原理
linux 刪除檔案其實是減少了對檔案的使用數，當使用數降為 0 時，才正式刪除檔案。
所以當我們執行 rm 時，由於 ibd 檔案還在被 mysql 使用，檔案其實並沒有被真實刪除，只是沒辦法通過檔案系統訪問。
通過 procfs 查詢檔案控制代碼，可以讓我們追蹤到消失的檔案。
linux 恢復刪除的檔案
檔案實際上是乙個指向inode的鏈結,inode鏈結包含了檔案的所有屬性,比如許可權和所有者,資料塊位址 檔案儲存在磁碟的這些資料塊中 當你刪除 rm 乙個檔案,實際刪除了指向inode的鏈結,並沒有刪除inode的內容.程序可能還在使用.只有當inode的所有鏈結完全移去,然後這些資料塊將可以寫入...
linux檔案誤刪除恢復
首先準備好工具debugfs 1 以唯讀方式掛載誤操作的硬碟 mount r n o remount r dev 若提示磁碟有程序或者使用者在操作，則使用fusr 檢視什麼在使用這個硬碟。若無重要程序則使用fuser k v m dev 乾掉。2 debugfs dev hda.3 檢視被刪除的檔案...
linux恢復意外刪除的檔案
author skate time 2013 10 12 linux恢復意外刪除的檔案 當程序開啟某個檔案時，只要該程序保持開啟該檔案，即使將其刪除，它依然存在於磁碟中。這意味著，程序並不知道檔案已經被刪除，它仍然可以向開啟該檔案時提供給它的檔案描述符進行讀取和寫入。除了該程序之外，這個檔案是不可見...