那是個周五傍晚我在清理腳本里手滑多打了一個通配符rm -rf cache*變成了對一整個項目目錄的處刑。冷靜下來的第一反應(yīng)是去搜「Linux 誤刪恢復(fù)」。教程們熱情洋溢extundelete、testdisk、photorec步驟齊全。我照做了——部分成功刪掉的源碼找回了七成另外三成永遠消失。當(dāng)時我不明白為什么是七成也沒人告訴我這數(shù)字還能更低。這篇把恢復(fù)的真實面貌講清能救多少、什么時候救不了、以及為什么「預(yù)防」比「恢復(fù)」便宜一萬倍。〇、先花兩分鐘rm 的時候磁盤上發(fā)生了什么常識想象是「數(shù)據(jù)被擦掉了」。幾乎不是。真實過程以 ext4 為例rm只干兩件小事把文件目錄項里那行刪了以后按名字找不到它了把inode 標(biāo)記為空閑inode B2 講過的那頁賬本記錄數(shù)據(jù)塊位置數(shù)據(jù)塊本身一個字節(jié)沒動——文件內(nèi)容還躺在盤上只是「沒人認領(lǐng)」真正的抹除發(fā)生在之后任何新寫入的文件都可能認領(lǐng)這些空閑塊覆寫舊內(nèi)容。推論是這篇的核心誤刪后的盤像一杯打翻的水恢復(fù)像搶救桌面上的水——每過一秒桌面都在變干。誤刪后系統(tǒng)繼續(xù)跑、日志繼續(xù)寫、瀏覽器繼續(xù)緩存全在喝你的水。所以誤刪后第一個動作不是裝恢復(fù)工具裝包本身就在寫盤是停止寫入能 umount 就 umount能關(guān)機就關(guān)機mount -o remount,ro也行。云主機還有一招大招先打快照然后在快照上恢復(fù)原盤一個字節(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怎么讀前者指定路徑恢復(fù)單個文件相對分區(qū)根的路徑不帶開頭斜杠帶斜杠它會報「找不到」——高頻翻車點后者全盤掃描恢復(fù)一切可識別的?；謴?fù)出來的文件放在執(zhí)行目錄下的RECOVERED_FILES/里。它的工作原理值得知道一句掃描磁盤上「沒被覆寫的舊 inode 殘影」把 inode 記錄的數(shù)據(jù)塊鏈重新串起來。這個原理直接推導(dǎo)出所有失敗場景——二、三大失敗場景教程不會說的部分場景 1塊已被覆寫。誤刪后繼續(xù)用盤一小時再恢復(fù)新寫入的數(shù)據(jù)認領(lǐng)了舊塊。殘影在內(nèi)容已是別人的。這是「七成」變「兩成」的頭號原因時間就是成功率。場景 2小文件 日志式文件系統(tǒng)。ext4 的刪除會清掉 inode 里的數(shù)據(jù)塊指針日志式文件系統(tǒng)為了一致性刪除時順手抹了指針。于是 extundelete 找得到 inode「這里曾有個文件、大小多少」卻不知道數(shù)據(jù)在哪只能按文件大小在附近「猜」著抓。小文件常抓成碎片或亂碼。ext3 時代恢復(fù)率反而高些——這是個殘酷的技術(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)——恢復(fù)出 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恢復(fù)。腳本里繼續(xù)用 rm手動刪除改用 trash-put就夠了真正靠譜的從來是備份rsync 定時快照、LVM 快照D3 那套、云盤打快照?；謴?fù)工具的成功率是概率備份的成功率是 100%。F4 那篇會寫一個能進生產(chǎn)的備份腳本。四、和前后篇的關(guān)系刪除的底層機制inode、鏈接計數(shù)與B3已刪文件仍被進程占用、磁盤不釋放是同一枚硬幣的兩面B3 是「刪了但進程還拽著」本篇是「刪了真沒人拽」「先打快照再操作」的底氣來自D3的 LVM 快照或云平臺快照ext4 vs XFS 的選擇D4直接影響你能用哪條恢復(fù)路線。速查表文末收藏版誤刪后第一動作 → 停止寫入umount / remount,ro / 云機先打快照 ext3/ext4 恢復(fù) → sudo extundelete /dev/sdX1 --restore-file 相對路徑/不帶開頭斜杠 全掃 → sudo extundelete /dev/sdX1 --restore-all 結(jié)果在 RECOVERED_FILES/ 其他文件系統(tǒng)/絕望局 → photorec按文件頭掃內(nèi)容丟文件名和目錄 恢復(fù)前 → 設(shè)備只讀別在原盤裝工具、別往原盤寫任何東西 失敗三大場景 → 塊被覆寫 ext4 小文件指針已清 XFS/Btrfs 不適用 帶 * 的 rm → 先跑一遍同參數(shù)的 ls 命令行回收站 → trash-clitrash-put / trash-list / trash-restore 成功率排序 → 備份 100% 快照 恢復(fù)工具概率 祈禱