那是個周五傍晚我在清理腳本里手滑多打了一個通配符rm -rf cache*變成了對一整個項目目錄的處刑。冷靜下來的第一反應(yīng)是去搜「Linux 誤刪恢復」。教程們熱情洋溢extundelete、testdisk、photorec步驟齊全。我照做了——部分成功刪掉的源碼找回了七成另外三成永遠消失。當時我不明白為什么是七成也沒人告訴我這數(shù)字還能更低。這篇把恢復的真實面貌講清能救多少、什么時候救不了、以及為什么「預防」比「恢復」便宜一萬倍。〇、先花兩分鐘rm 的時候磁盤上發(fā)生了什么常識想象是「數(shù)據(jù)被擦掉了」。幾乎不是。真實過程以 ext4 為例rm只干兩件小事把文件目錄項里那行刪了以后按名字找不到它了把inode 標記為空閑inode B2 講過的那頁賬本記錄數(shù)據(jù)塊位置數(shù)據(jù)塊本身一個字節(jié)沒動——文件內(nèi)容還躺在盤上只是「沒人認領(lǐng)」真正的抹除發(fā)生在之后任何新寫入的文件都可能認領(lǐng)這些空閑塊覆寫舊內(nèi)容。推論是這篇的核心誤刪后的盤像一杯打翻的水恢復像搶救桌面上的水——每過一秒桌面都在變干。誤刪后系統(tǒng)繼續(xù)跑、日志繼續(xù)寫、瀏覽器繼續(xù)緩存全在喝你的水。所以誤刪后第一個動作不是裝恢復工具裝包本身就在寫盤是停止寫入能 umount 就 umount能關(guān)機就關(guān)機mount -o remount,ro也行。云主機還有一招大招先打快照然后在快照上恢復原盤一個字節(jié)不動。圖示rm 后磁盤真實狀態(tài)、正確動作順序與失敗場景一、extundelete能用的姿勢前提三件事ext3/ext4 文件系統(tǒng)、設(shè)備已只讀或卸載、包名相同sudo apt install extundelete。sudo extundelete /dev/sdb1 --restore-file projects/app/main.py sudo extundelete /dev/sdb1 --restore-all怎么讀前者指定路徑恢復單個文件相對分區(qū)根的路徑不帶開頭斜杠帶斜杠它會報「找不到」——高頻翻車點后者全盤掃描恢復一切可識別的?；謴统鰜淼奈募旁趫?zhí)行目錄下的RECOVERED_FILES/里。它的工作原理值得知道一句掃描磁盤上「沒被覆寫的舊 inode 殘影」把 inode 記錄的數(shù)據(jù)塊鏈重新串起來。這個原理直接推導出所有失敗場景——二、三大失敗場景教程不會說的部分場景 1塊已被覆寫。誤刪后繼續(xù)用盤一小時再恢復新寫入的數(shù)據(jù)認領(lǐng)了舊塊。殘影在內(nèi)容已是別人的。這是「七成」變「兩成」的頭號原因時間就是成功率。場景 2小文件 日志式文件系統(tǒng)。ext4 的刪除會清掉 inode 里的數(shù)據(jù)塊指針日志式文件系統(tǒng)為了一致性刪除時順手抹了指針。于是 extundelete 找得到 inode「這里曾有個文件、大小多少」卻不知道數(shù)據(jù)在哪只能按文件大小在附近「猜」著抓。小文件常抓成碎片或亂碼。ext3 時代恢復率反而高些——這是個殘酷的技術(shù)倒退。場景 3XFS/Btrfs 上extundelete 直接不適用。它只認 ext 系。XFS 上基本只剩photorec見下這種內(nèi)容掃描流。順帶一說photorec不讀文件系統(tǒng)賬本直接按文件頭簽名JPEG 的_ff d8、PDF 的 %PDF 這類掃描全盤內(nèi)容。好處是什么文件系統(tǒng)都行連 Windows 盤都行壞處是丟文件名和目錄結(jié)構(gòu)——恢復出 3000 張f0001234.jpg靠人眼一張張歸位。適合「只要內(nèi)容不要結(jié)構(gòu)」的絕望時刻。三、三個真實建議rm 是延遲陷阱先-i一次再放行。交互式 rm 太煩但通配符 rm 前先ls一遍同表達式看看命中誰成本三秒。我現(xiàn)在的肌肉記憶任何帶*的 rm先跑一遍同參數(shù)的 lsrm 沒有回收站但可以造一個。桌面環(huán)境其實有GNOME 的「垃圾箱」純命令行的替代方案是trash-clisudo apt install trash-cli用trash-put代替 rmtrash-list查看、trash-restore恢復。腳本里繼續(xù)用 rm手動刪除改用 trash-put就夠了真正靠譜的從來是備份rsync 定時快照、LVM 快照D3 那套、云盤打快照?；謴凸ぞ叩某晒β适歉怕蕚浞莸某晒β适?100%。F4 那篇會寫一個能進生產(chǎn)的備份腳本。四、和前后篇的關(guān)系刪除的底層機制inode、鏈接計數(shù)與B3已刪文件仍被進程占用、磁盤不釋放是同一枚硬幣的兩面B3 是「刪了但進程還拽著」本篇是「刪了真沒人拽」「先打快照再操作」的底氣來自D3的 LVM 快照或云平臺快照ext4 vs XFS 的選擇D4直接影響你能用哪條恢復路線。速查表文末收藏版誤刪后第一動作 → 停止寫入umount / remount,ro / 云機先打快照 ext3/ext4 恢復 → sudo extundelete /dev/sdX1 --restore-file 相對路徑/不帶開頭斜杠 全掃 → sudo extundelete /dev/sdX1 --restore-all 結(jié)果在 RECOVERED_FILES/ 其他文件系統(tǒng)/絕望局 → photorec按文件頭掃內(nèi)容丟文件名和目錄 恢復前 → 設(shè)備只讀別在原盤裝工具、別往原盤寫任何東西 失敗三大場景 → 塊被覆寫 ext4 小文件指針已清 XFS/Btrfs 不適用 帶 * 的 rm → 先跑一遍同參數(shù)的 ls 命令行回收站 → trash-clitrash-put / trash-list / trash-restore 成功率排序 → 備份 100% 快照 恢復工具概率 祈禱