Linux、macOS 或 Windows 上的意外 rm -rf 或 Shift-Delete：立即只讀重新掛載¶

目睹一場意外 rm -rf, find -delete, git clean -fdx，或Windows Shift+Delete 清除關鍵的生產資料庫、原始程式碼或個人檔案而不將其發送到回收站或垃圾資料夾會立即引發恐慌。然而，兩者都沒有 rm -rf 也不 Shift+Delete 實際上在命令完成時將底層存儲扇區清零：相反，操作系統只是取消目錄條目的鏈接，更新其元數據日誌，並標記那些 inode 指針或主文件表（MFT）記錄和區塊位圖可供重複使用。永久破壞已刪除檔案的是每一秒檔案系統都以讀寫方式掛載（rw) 模式 刪除後，作為後台系統記錄器(systemd-journald, rsyslog)、瀏覽器快取、交換活動和 SSD TRIM / discard 命令快速覆蓋新釋放的區塊。如果您的系統出現實體點擊、壞磁區或死控制器的問題，請停止並切換到我們的指南 硬碟故障和資料恢復，或者如果您的固態硬碟因控制器磨損而自行鎖定，請參閱 SSD和NVMe突然只讀模式和TRIM禁用救援;對於更廣泛的格式錯誤或相機卡問題，請諮詢 意外檔案刪除、格式化磁碟機和照片恢復。如果此事件涉及犯罪破壞、勒索或生命安全系統中斷，請撥打您當地的緊急電話號碼（911 在美國和加拿大， 112 整個歐盟， 999 在英國）或查看我們的國際目錄 緊急號碼。

現在就這樣做¶

1. 按 Ctrl+C 如果刪除命令仍在運行，請立即執行，並且不要關閉任何開啟的終端視窗、文字編輯器、媒體播放器或資料庫守護程式：如果有任何正在運行的程式（nginx, postgres, mysqld, vim, code, python, tail或視訊播放器）仍在記憶體中開啟已刪除的文件，Linux 或 macOS 核心會在磁碟上完整保留檔案的資料區塊，直到該進程關閉其檔案描述符。現在關閉應用程式或重新啟動機器將立即釋放引用計數（i_nlink == 0）並觸發實際的區塊釋放。
2. 在 Linux 上重新安裝或關閉電源之前，請檢查 /proc/<pid>/fd/ 現在要挽救正在運行的進程仍保持打開狀態的任何已刪除檔案：運行 sudo lsof +L1 （其中列出了連結計數小於 1 的所有開啟文件，這意味著它們被取消連結 rm 仍然打開）並立即將其原始內容從 RAM/核心快取複製到單獨的驅動器或 /dev/shm （tmpfs RAM 磁碟）使用 cp /proc/<pid>/fd/<fd_number> /dev/shm/rescued_file。
3. 以唯讀方式重新掛載受影響的分割區（ro）立即，這樣作業系統核心就無法將另一個位元組的日誌日誌或臨時檔案寫入未分配的區塊：
4. 在 Linux 上（ext4, XFS, Btrfs)：運行 sudo mount -o remount,ro /path/to/mountpoint （例如， sudo mount -o remount,ro /home 或 sudo mount -o remount,ro /）。
5. 如果 mount -o remount,ro 失敗了 mount point is busy 在你的根上（/) 分區：透過執行Magic SysRq觸發核心的立即緊急只讀重新掛載 echo u | sudo tee /proc/sysrq-trigger （這會強制所有已掛載的檔案系統立即以唯讀方式重新掛載，而無需終止進程或等待開啟的鎖）。
6. 在 macOS 上（APFS / HFS+)：運行 sudo diskutil mount readOnly /Volumes/TargetVolume 對於非啟動卷，或文件位於您的主卷上 Data 體積（/System/Volumes/Data），按住 Touch ID/電源按鈕 10 秒鐘以停止背景聚光燈，立即強制關閉電源（mds_stores）和 fseventsd 寫道。
7. 在 Windows 上（NTFS / ReFS)：如果刪除的檔案位於輔助磁碟機上 (D:, E:），開啟管理員命令提示字元並將磁碟區鎖定為唯讀 diskpart （select volume D, attributes volume set readonly）。如果文件已開啟 C:\，不要正常關閉 Windows（正常關閉會在釋放的記憶體上寫入數百兆位元組的登錄配置單元、事件日誌和頁面檔案更新） MFT 簇）；相反，拉動桌上型電腦電源線或按住筆記型電腦電源按鈕 10 秒鐘即可立即切斷電源。
8. 防止SSD TRIM （discard / UNMAP）將未指派的快閃記憶體頁面歸零：如果磁碟機是 NVMe 或 SATA SSD 並且安裝了連續 discard （或者如果 Windows/macOS 運行預定的 TRIM 文件刪除後立即）、切斷電源或重新安裝 ro 立即停止操作系統排隊額外的 NVME_DSM_ATTR_DEALLOCATE 命令，並將 SSD 放入未通過的 USB 轉 NVMe 橋接適配器 TRIM 在復原期間防止控制器的背景垃圾收集擦除可恢復的區塊。
9. 從外部 Live USB 啟動（Ubuntu Live, SystemRescue, 或 WinPE）並使用以下命令將分區逐位複製到外部儲存磁碟機 ddrescue 在運行任何取消刪除工具之前：從不運行 ext4magic, extundelete, testdisk, photorec, 或 ntfsundelete 直接以寫入模式針對受害磁碟機；始終對區塊裝置進行映像（sudo ddrescue -d -r0 /dev/nvme0n1p2 /mnt/external/disk_image.raw /mnt/external/rescue.map）並從映像中雕刻檔案或將復原的檔案嚴格寫入第二個實體磁碟。
10. 檢查隱藏的本機檔案系統快照（Btrfs, ZFS, LVM、macOS APFS 時間機器本地快照和 Windows 陰影副本），然後再花費數小時雕刻原始扇區：許多系統悄悄地保留原子時間點塊引用（tmutil listlocalsnapshots / 在 macOS 上， vssadmin list shadows 在 Windows 上， zfs list -t snapshot, 或 btrfs subvolume list -s /）允許即時 100% 恢復 rm -rf 或 Shift+Delete 目錄而不觸及原始未分配的集群。

決策樹：意外事故後立即分類 rm -rf 或 Shift+Delete¶

在發現刪除後的前 60 秒內遵循此決策樹，以保留盡可能高百分比的未連結資料區塊：

flowchart TD
    Start["意外執行 rm -rf、find -delete 或 Shift+Delete"] --> OpenCheck{"任何正在運行的進程（DB、編輯器、伺服器、Tail）是否仍然可以開啟已刪除的檔案？"}

    OpenCheck -->|"是（Linux / macOS 仍在運行）"| ProcRescue["步驟 1：立即執行 sudo lsof +L1 並將開啟的檔案描述子從 /proc/PID/fd/N 複製到 RAM 磁碟 (/dev/shm) 或外部 USB"]
    OpenCheck -->|"否（或所有文件均已關閉）"| SnapCheck{"該磁碟區是否使用 ZFS、Btrfs、APFS 本機快照或 Windows 磁碟區副本？"}

    ProcRescue --> FreezeOS["步驟 2： 立即凍結所有磁碟寫入"]
    SnapCheck -->|"是：CoW 快照存在"| FreezeOS
    SnapCheck -->|"否：標準 ext4、XFS 或 NTFS，不含快照"| FreezeOS

    FreezeOS --> OSBranch{"哪個作業系統和分割區受到攻擊？"}

    OSBranch -->|"Linux 非根目錄（/home、/data）"| RemountRO["運行： sudo mount -o remount,ro /掛載點"]
    OSBranch -->|"Linux 根 (/) 分區"| SysRqRO["運行： echo u | sudo tee /proc/sysrq-trigger（核心緊急只讀重新掛載）"]
    OSBranch -->|"Windows C：驅動器或 macOS 啟動 APFS"| HardPower["請勿正常關機：按住電源按鈕 10 秒或拉動電源線以防止關機日誌/頁面檔案寫入"]
    OSBranch -->|"輔助外部或數據驅動器"| UnmountSec["立即卸載/將磁碟區設定為唯讀並斷開驅動器連接"]

    RemountRO --> LiveBoot["步驟 3：啟動外部 SystemRescue Live USB 並使用 ddrescue 複製分割區到外部磁碟機"]
    SysRqRO --> LiveBoot
    HardPower --> LiveBoot
    UnmountSec --> LiveBoot

    LiveBoot --> FSRecovery{"按檔案系統選擇恢復方法"}
    FSRecovery -->|"外部4/外部3"| ExtRec["日誌索引節點復原：ext4magic / extundelete / debugfs"]
    FSRecovery -->|"XFS / APFS / 無日誌"| CarveRec["簽名和頁首/頁尾雕刻：photorec/scalpel/mostly/xfs_irecover"]
    FSRecovery -->|"NTFS（Windows）"| NtfsRec["MFT記錄解析：ntfsundelete / TestDisk / UFS Explorer / DMDE"]

為什麼每秒安裝讀寫（rw) 銷毀已刪除的文件¶

要了解為什麼立即只讀重新安裝或硬斷電對您的資料來說是生死攸關的決定，請檢查每個現代檔案系統在運行時實際修改的內容 unlink() （rm）或 DeleteFileW() （Shift+Delete）：

1. 內部發生了什麼 ext4, XFS, APFS， 和 NTFS 刪除期間¶

當檔案被刪除時，消費者作業系統不會花費磁碟 I/O 頻寬在 10 GB（107 億位元組）的資料庫或視訊檔案上寫入零。相反，檔案系統驅動程式僅改變微小的元資料結構：

2.固態硬碟 TRIM （Discard / Deallocate) 定時炸彈¶

在旋轉的硬碟上（HDD），扇區在被覆蓋之前保持可讀。在 SSD 上（SATA 或 NVMe），當檔案系統發出 TRIM 或 Deallocate 命令： - 大多數 NVMe 控制器在 TRIM 後實現確定性讀零（DRAT / DZAT)，返回 0x00000000 （全零）來自快閃記憶體轉換層（FTL) 收到後立即 TRIM，甚至在實體 NAND 垃圾收集運行之前。 - 為什麼 Linux 系統常常能夠存活下來 TRIM：大多數 Linux 發行版（Ubuntu, Debian, Fedora, RHEL) 不啟用連續安裝時間 discard 預設；他們每週運行一個計時器（fstrim.timer）。如果您以唯讀方式重新掛載（ro) 之前 fstrim.timer 運行，SSD 尚未取消映射這些區塊。

第 1 階段：拯救正在運行的進程仍保持開啟的已刪除檔案（/proc/<pid>/fd/）¶

在 Linux 或 macOS 上重新啟動、卸載或關閉單一視窗之前，檢查開啟的檔案描述符。在 POSIX 系統中， rm 來電 unlink()。核心追蹤每個 inode 的兩個計數器： 1. i_nlink：指向 inode 的磁碟目錄條目。 2. i_count：活動進程在記憶體中保持索引節點開啟。

POSIX 黃金規則：核心 永遠不會釋放 inode 或釋放磁碟區塊，直到兩者都釋放 i_nlink == 0 和 i_count == 0。如果已刪除的資料庫、日誌、影片或程式碼檔案在任何進程中仍處於開啟狀態，則該檔案 100% 在磁碟上保持完整。

一步一步 /proc/<pid>/fd/ Linux 上的提取¶

1. 查找任何進程仍保持開啟的每個已刪除檔案：

   sudo lsof +L1
   

   （或依檔案名稱過濾： sudo lsof | grep -i "(deleted)" | grep -i "filename")
2. 閱讀 lsof 輸出列：

   COMMAND    PID     USER   FD   TYPE DEVICE  SIZE/OFF   NLINK    NODE NAME
   postgres  4182 postgres   14u   REG  259,2 524288000       0 1839204 /var/lib/postgresql/16/main/base/16384/16399 (deleted)
   

   注意PID（4182) 並取下尾隨字母 (u, r, w）來自FD（14u -> 14）。
3. 將原始文件複製出來 /proc/<pid>/fd/<fd_num> 進入內存（/dev/shm）或外部驅動器： 切勿將已挽救的文件寫回受影響的分割區。寫信給 /dev/shm （RAM 磁碟）或外部 USB 隨身碟：

   mkdir -p /dev/shm/rescued_files
   sudo cp /proc/4182/fd/14 /dev/shm/rescued_files/16399_recovered
   

4. 從資料庫或容器中拯救多個已開啟的已刪除檔案（PID=4182) 在一個循環中：

   sudo mkdir -p /dev/shm/rescued_db
   for fd in /proc/4182/fd/*; do
     target=$(sudo readlink "$fd")
     if echo "$target" | grep -q "(deleted)"; then
       fd_num=$(basename "$fd")
       clean_name=$(echo "$target" | sed 's/ (deleted)//; s/\//_/g')
       sudo cp "$fd" "/dev/shm/rescued_db/fd_${fd_num}${clean_name}"
     fi
   done
   

5. 救援緩衝區和 IDE 本地歷史記錄 (vim, VS Code, Cursor, JetBrains）：
6. 不要關閉開啟的編輯器標籤：將開啟的緩衝區直接儲存到 /dev/shm 或拇指驅動器。
7. VS Code / Cursor / VSCodium Local History：儲存每個已儲存檔案的自動時間戳副本 -/.config/Code/User/History/ （Linux）， -/Library/Application Support/Code/User/History/ (macOS)，或 %APPDATA%\Code\User\History\ (Windows)，完全在您的專案資料夾之外。即使之後 rm -rf -/my-project 或 git clean -fdx，你的程式碼檔案在裡面保持完整 User/History/ 與一個 entries.json 清單將每個文件映射回其原始路徑。
8. JetBrains IDE (IntelliJ, PyCharm, WebStorm)：內部儲存自動歷史記錄 -/.cache/JetBrains/<IDE>/LocalHistory/。
9. 吉特（git reset --hard 或 git branch -D 與 .git/ 完好無損）：運行 git reflog 或 git fsck --lost-found 立即恢復內部懸掛的斑點 .git/objects/。

第 2 階段：將檔案系統凍結為唯讀 (ro) 不覆蓋未分配的區塊¶

一旦您從以下位置提取了所有開啟的文件描述符 /proc （或驗證不存在），您的當務之急是阻止作業系統向分割區寫入單一附加磁區。

1. Linux：重新掛載資料分割區與根分割區（/) 分區唯讀¶

• 場景 A：刪除的檔案位於單獨的分割區上（/home, /var, /data, /mnt/storage）：
• 立即嘗試乾淨的唯讀重新安裝：

  sudo mount -o remount,ro /home
  

• 如果 mount 說 mount point is busy，識別並停止寫入進程（sudo fuser -vm /home 隨後 sudo fuser -km -TERM /home），然後立即重新運行 sudo mount -o remount,ro /home。
• 場景 B：刪除的檔案位於根目錄（/) 分區（否則無法殺死繁忙的進程）： 不要跑 sudo reboot 或 sudo shutdown -h now，因為一個正常的 systemd shutdown 寫入兆位元組 journald 關閉日誌、隨機種子和服務狀態檔案直接儲存到 /。相反，觸發 Linux Kernel Magic SysRq Emergency Read-Only Remount：

  echo 1 | sudo tee /proc/sys/kernel/sysrq
  echo s | sudo tee /proc/sysrq-trigger
  echo u | sudo tee /proc/sysrq-trigger
  

• s （Emergency Sync)：刷新待處理的記憶體中檔案系統元數據，以便超級區塊保持一致。
• u （Emergency Remount Read-Only)：強制將機器上每個已安裝的檔案系統重新安裝為唯讀（ro）在核心內部，即使進程仍然有開啟的檔案可供寫入。 驗證一下 / 現在是唯讀的 grep " / " /proc/mounts。

2. 對凍結的遠端雲端伺服器進行映像（AWS EC2, GCP, DigitalOcean, Hetzner) 透過 SSH¶

如果你不小心跑了 rm -rf 在無法插入 USB 隨身碟的遠端雲端伺服器上： 1. 執行 Magic SysRq 只讀重新掛載 (echo s > /proc/sysrq-trigger && echo u > /proc/sysrq-trigger）。您現有的 SSH 會話將保持活動狀態，因為 SSH 在 RAM 中運行並且 /dev/pts （devpts）是一個虛擬RAM偽終端檔案系統。 2. 在雲端平台（AWS EC2、GCP、Azure、DigitalOcean）上，立即從雲端控制台取得原子 EBS/區塊磁碟機快照，或停止執行個體、分離根磁碟區並將其附加為唯讀（/dev/xvdf）到乾淨的救援虛擬機器。 3. 在裸機遠端伺服器上，將凍結唯讀分割區的壓縮原始映像直接透過 SSH 傳送到本機工作站：

ssh root@remote-server-ip "dd if=/dev/nvme0n1p2 bs=4M status=progress | zstd -1" > ~/rescued_partition.img.zst

第 3 階段：檢查隱藏的寫入時複製 (CoW) 雕刻前的快照和卷影副本¶

在掃描 TB 的未分配磁區之前，請檢查您的作業系統是否自動建立了隱藏的時間點快照：

1. macOS：本機時間機器 APFS 快照（tmutil）¶

即使您的外部 Time Machine 驅動器已斷開連接數週，macOS 也會自動在您的內部 SSD 上記錄每小時本地 APFS 寫入時複製快照（com.apple.TimeMachine.YYYY-MM-DD-HHMMSS.local) 只要配置了 Time Machine 或在 macOS 更新之前： 1. 列出終端機中的所有本機快照：

tmutil listlocalsnapshots /
tmutil listlocalsnapshots /System/Volumes/Data

mkdir -p /tmp/apfs_rescue
sudo mount_apfs -o ro -s com.apple.TimeMachine.2026-10-31-140000.local /System/Volumes/Data /tmp/apfs_rescue
ls -la /tmp/apfs_rescue/Users/yourname/

2. Windows 10 / 11 / Server：磁碟區副本（VSS）¶

1. 開啟 管理員命令提示字元 並執行：

   vssadmin list shadows
   

2. 如果影集副本 (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1）早於你的 Shift+Delete，將其連結到資料夾並將檔案複製到 USB 隨身碟：

   mklink /d C:\ShadowRescue \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\
   

3.Linux： Btrfs, ZFS， 和 LVM 快照¶

• 開 Btrfs （Fedora、openSUSE、Synology、Timeshift/Snapper 系統）：運行 sudo btrfs subvolume list -s / 並檢查 /.snapshots/ 或 /run/timeshift/backup/timeshift-btrfs/snapshots/。
• 開 ZFS （Ubuntu ZFS、Proxmox、TrueNAS）：運行 zfs list -t snapshot 並直接從複製文件 /path/to/dataset/.zfs/snapshot/。

第 4 階段：依檔案系統逐步復原 Inode、Journal 和 MFT¶

如果沒有開啟的檔案描述符（/proc/<pid>/fd/）且不存在快照，從 SystemRescue 或 Ubuntu Live USB 啟動，連接外部 USB 硬碟 (/mnt/external），並建立已卸載的受害者分區的逐位克隆（/dev/nvme0n1p2）首先：

sudo ddrescue -f -n /dev/nvme0n1p2 /mnt/external/victim_partition.img /mnt/external/ddrescue.log

1. 從中恢復 ext4 / ext3 在 Linux 上（ext4magic 和 extundelete）¶

當 rm -rf 刪除文件 ext4，核心將主 inode 表內的範圍樹指標清除。然而，ext4的 jbd2 日誌（大小通常為 128 兆位元組到 1,024 兆位元組）儲存最近修改的索引節點區塊的歷史副本。只要你重新上馬 ro 在大量磁碟活動包裹日誌環形緩衝區之前， ext4magic 從日誌中提取刪除前的 inode，並使用完整的原始檔案名稱和目錄樹重建檔案。

1. 運行 ext4magic 恢復過去 2 小時內刪除的所有檔案 (-a）在相對路徑（-f）： （省略安裝點的前導斜線 -f：對於 /home/kmyers/project 在根上 / 分區、通過 -f home/kmyers/project;如果 /home 是自己的分區，pass -f kmyers/project.)

   mkdir -p /mnt/external/recovered_ext4
   sudo ext4magic /mnt/external/victim_partition.img \
     -a $(date -d "2 hours ago" +%s) \
     -f home/kmyers/project \
     -R -d /mnt/external/recovered_ext4
   

2. 替代方案：跑步 extundelete 對照圖像：

   cd /mnt/external
   sudo extundelete /mnt/external/victim_partition.img --restore-directory home/kmyers/project
   

2. 從 Windows 恢復 NTFS 之後 Shift+Delete （TestDisk 和 ntfsundelete）¶

不像 ext4, Windows NTFS 不會將區塊範圍指標歸零（Data Runs）在主文件表（$MFT) 記錄檔案被刪除的時間。當您按下 Shift+Delete 在 NTFS 上，1,024 位元組 $MFT 條目只是翻轉其標頭標誌 0x01 （使用中）至 0x00 （已刪除）。其 $FILE_NAME 屬性和 $DATA 叢集運行列表保持 100% 完整，直到另一個檔案重複使用該運行列表 $MFT 插槽：

1. 使用 TestDisk 用於即時 NTFS $MFT 使用完整資料夾路徑取消刪除：

   sudo testdisk /mnt/external/victim_partition.img
   

   選擇[ Proceed ] -> [ EFI GPT ] -> [ Advanced ] -> 反白顯示 NTFS 分割區 -> [ Undelete ]。導航到您的資料夾，按 a 選擇已刪除的文件，然後按 C（大寫 C）將它們複製到 /mnt/external/recovered_ntfs/。
2. 使用 ntfsundelete （ntfs-3g）：

   sudo ntfsundelete /mnt/external/victim_partition.img -t 2d
   sudo ntfsundelete /mnt/external/victim_partition.img -u -m "*" -d /mnt/external/recovered_ntfs
   

3. 從中恢復 XFS, APFS，或透過原始塊雕刻覆蓋日誌（PhotoRec 和 grep -a -b）¶

當 inode 指標消失時（例如 XFS, APFS，或ext4 日誌被包裹的分割區），透過掃描未指派的 4,096 位元組（4 KB）區塊中的檔案頁首/頁尾或唯一文字字串來還原資料：

如何使用 grep -a -b + dd 挽救已刪除的原始程式碼或 .env 2 分鐘內即可完成文件¶

如果你刪除了原始碼， .env 大小小於 32 KB 的秘密或註釋： 1. 在已刪除的檔案中搜尋唯一字串並列印其確切的位元組偏移量（-b）：

LC_ALL=C grep -a -b -o "def calculate_invoice_tax" /mnt/external/victim_partition.img

dd if=/mnt/external/victim_partition.img bs=4096 skip=11789795 count=30 status=none > /mnt/external/rescued_code_block.txt

第五階段：預防未來的災難 rm -rf 和 Shift+Delete 意外事故¶

• 取代互動 rm 與 trash-cli 和 rm -I --preserve-root=all：安裝 trash-cli （trash-put, trash-list, trash-restore) 和別名 rm 到 rm -I --preserve-root=all 在 /etc/bash.bashrc 和 -/.zshrc 因此，在取消連結 inode 之前會提示一次意外的遞歸刪除。
• 使用 Linux 不可變屬性保護關鍵生產目錄 (chattr +i)：偶數 root （sudo rm -rf) 無法刪除或修改標記的目錄或文件 sudo chattr +i /path/to/critical_config 直到管理員執行 sudo chattr -i。
• 啟用自動本機寫入時複製 (CoW) 快照 (Btrfs / ZFS / APFS / Windows Shadow Copies)：使用 Snapper 或 Timeshift 上 Btrfs, sanoid 上 ZFS，或 Windows 上每天兩次的捲影副本 (SystemPropertiesProtection.exe）。
• 使用不可變的異地儲存維護自動 3-2-1 備份：按照我們的指南進行操作 電腦備份、3-2-1 策略與災難復原 使用 restic 或 borgbackup 具有僅附加遠端存儲庫。

地區緊急電話號碼和機構協議¶

雖然個人電腦上的意外文件刪除是技術緊急情況而不是警察問題，但影響醫療保健系統、市政基礎設施、法院保全令下的法律證據或受監管個人資料的意外或惡意刪除可能會觸發強制事件報告：

• 美國和加拿大：
• 緊急生命安全/關鍵基礎設施中斷：撥打911 如果系統擦拭影響醫院病患照護、緊急調度或工業物理安全控制。
• 網路安全與基礎設施安全局（CISA)（美國）：報告關鍵基礎設施資料破壞或可疑的內部破壞行為，網址為1-844-Say-CISA （1-844-729-2472) 或 cisa.gov/report。
• 加拿大網路安全中心：聯絡方式1-833-CYBER-88 （1-833-292-3788) 對於關鍵基礎設施事件。
• 英國：
• 緊急服務：撥打999（或101 對於非緊急警方報告，如果刪除涉及《1990 年電腦濫用法》規定的未經授權的電腦濫用）。
• 資訊專員辦公室（ICO)：如果意外刪除永久破壞了個人資料且沒有備份恢復（構成英國 GDPR 規定的可用性違規），請評估是否向 ICO 發出通知（0303 123 1113) 需要在 72 小時內。
• 歐盟：
• 緊急服務：撥打112 所有歐盟成員國。
• GDPR 第 33 條可用性違規報告：根據歐洲資料保護委員會 (EDPB）準則，在沒有可恢復備份的情況下意外永久破壞個人資料被歸類為個人資料外洩（可用性喪失），並且可能需要向您所在國家的資料保護機構報告（DPA）72小時內。
• 澳洲和紐西蘭：
• 緊急服務：撥打000 在澳洲或 111 在新西蘭。
• 澳洲網路安全中心（ACSC)：致電1300 CYBER1 （1300 292 371) 用於企業或基礎設施援助。
• 印度和亞太地區：
• 印度（CERT-In / 全國網路犯罪求助專線）：撥打 112 用於緊急應變或 1930 網路犯罪事件； CERT-In 指令涵蓋的企業事件必須在 6 小時內通報給 incident@cert-in.org.in。

常見問題¶

為什麼沒有 extundelete 或 ext4magic 找到我的檔名 ext4 即使我很快就不再使用電腦了？¶

當文件被刪除時 外部4，Linux 核心立即將磁碟 inode 表內的磁碟區樹指標清零，以便檔案系統知道該 inode 沒有分配磁碟區。類似的工具 ext4magic 和 擴充刪除 依賴在 inode 中尋找該 inode 的較舊的、刪除前的副本 外部4 期刊（傑巴德2）。如果建立並刪除檔案時其 inode 最近沒有通過日誌，或者在您重新以唯讀方式重新掛載之前，大量後台寫入佔用了 128 MB 到 1 GB 的日誌環形緩衝區，則日誌副本將消失。在這種情況下，您必須切換到原始塊簽名雕刻（攝影記錄) 或純文字位元組搜尋 (grep -a -b），直接掃描未分配的資料塊，不需要inode元資料。

是否有SSD TRIM 總是破壞 rm -rf 或 Shift+Delete 立即歸檔？¶

並非總是如此，尤其是在 Linux 和外部硬碟上。在具有內部 NVMe SSD 的 Windows 10/11 和 macOS 上，作業系統通常會發送內聯 修剪 / 解除分配 在永久刪除後幾秒內向 SSD 控制器發出命令，這會導致 SSD 的快閃記憶體轉換層 (超光速) 返回零 (德札特）對於這些塊。然而，大多數 Linux 發行版（Ubuntu、Debian、Fedora、RHEL）都這樣做 不 啟用連續安裝時間 丟棄 預設；相反，他們跑 fstrim定時器 每週一次。此外，許多 USB 轉 SATA 和 USB 轉 NVMe 外部外殼不通過 修剪 透過 USB 大容量儲存的命令（建設銀行），且軟體 RAID/LVM/LUKS 層經常阻塞 丟棄 預設直通，除非明確配置（`issue_discards = 1` 或 `allow-discards`）。

如果我的 Linux 分割區被加密怎麼辦 LUKS （dm-crypt) 或我的 Windows 磁碟機使用 BitLocker: 我還能雕刻已刪除的檔案嗎？¶

是的，前提是您有加密密碼或恢復金鑰並以唯讀模式解鎖容器。永遠不要跑 攝影, ext4magic, 或 測試磁碟 針對原始加密實體分割區（/dev/nvme0n1p2），因為加密的密文看起來像隨機噪音。相反，從 Live USB 啟動，解鎖容器 唯讀模式 （對於盧克斯： sudo cryptsetup open --readonly /dev/nvme0n1p2 crypt_rescue;對於 Linux 上的 BitLocker： 解鎖器-r 或在 WinPE 中解鎖唯讀），並對解密的虛擬映射器裝置進行映像或掃描（/dev/mapper/crypt_rescue）。

為什麼 Windows 上要拔電源線 C:\ 意外發生後更安全 Shift+Delete 而不是點擊“關閉”？¶

當您點擊 開始 > 關閉 在 Windows 上，作業系統在關閉電源之前執行數百兆位元組的磁碟寫入：它會刷新註冊表配置單元，將關閉事件寫入 .evtx 記錄，更新 USN 日誌（$UsnJrnl)、清除或調整大小 頁面檔案系統，並在快速啟動系統上寫入一個多千兆位元組的休眠檔案（休眠系統）直接跨未分配的 NTFS 群集。這些關閉寫入頻繁地覆蓋確切的未分配的 $MFT 您釋放的記錄和資料簇 Shift+刪除。強制立即斷電（按住電源按鈕 10 秒或拔掉插頭）會立即停止所有寫入；從只讀 Linux 或 WinPE 救援 USB 啟動時，NTFS 將保持完全可讀。

如何恢復已刪除的 .env 文件、SSH 金鑰或原始碼文件 PhotoRec 被忽視？¶

攝影記錄 尋找二進制魔術位元組頭（例如 %PDF, 巴布亞紐幾內亞, 或 PK 對於 ZIP/Office 檔案），因此它經常會跳過或將短的純文字檔案混在一起，例如 .env 配置、Python/JavaScript 原始碼、Markdown 註解和 SSH 金鑰。若要從磁碟映像或唯讀分割區還原任何純文字文件，請執行 LC_ALL=C grep -a -b -C 100 "UNIQUE_TEXT_FROM_FILE" /dev/nvme0n1p2 > /dev/shm/found.txt。如果您知道任何變數名稱（例如 條紋_秘密_密鑰= 或 開始使用 OpenSSH 私鑰), grep -a -b 以每秒幾千兆位元組的速度掃描原始磁區並列印精確的周圍磁碟區塊。

如果我不小心跑了 rm -rf / 或刪除 /usr 或 /lib 在 Linux 上，現在甚至沒有 ls, cp, 或 sudo 有效，如何在打開的終端機中運行命令？¶

如果你擦了 /bin 或 /lib 而現有的 巴什 或 桀騁 終端在 RAM 中仍然打開，外部二進位檔案如 /bin/ls 或 /bin/cp 將會失敗 沒有這樣的檔案或目錄, 但 shell 內建程式仍然完全在 RAM 內工作。您可以使用 迴聲* 而不是 LS, printf "%s\n" "$( /dev/shm/rescued 而不是 CP， 和 echo u > /proc/sysrq-trigger （如果您的 shell 已經是 root）在關閉電源並啟動 SystemRescue Live USB 之前觸發只讀核心重新安裝。

相關指南¶

• 意外檔案刪除、格式化磁碟機和照片恢復
• SSD和NVMe突然只讀模式、0%備用區塊和TRIM禁用救援
• 硬碟故障和資料恢復
• NAS RAID 陣列降級、多個磁碟機故障和 ZFS/Btrfs 恢復
• 電腦備份、3-2-1 策略與災難復原
• 按國家/地區劃分的緊急電話號碼

來源和官方指導¶

• 美國國家標準技術研究院（NIST）（美國）：特別出版物 800-86：將取證技術整合到事件回應中的指南和 SP 800-88 Rev. 1：媒體清理指南（ATA TRIM / NVMe 解除分配行為）。
• Linux 核心組織 (kernel.org): Ext4 檔案系統文件（區塊和索引節點分配， jbd2 寫日記，以及 procfs /proc/<pid>/fd/ 檔案描述符語意）和 Linux Magic 系統請求金鑰（sysrq.txt）。
• CG安全（TestDisk & PhotoRec 官方文件）和 ext4magic 上游參考手冊：ext3/ext4 和 NTFS 磁碟區上的日誌索引節點擷取和未指派盤區雕刻。
• 網路安全和基礎設施安全局（CISA）（美國）：事件回應和法醫揮發性/非揮發性證據保存最佳實踐。
• 歐盟網路安全局（ENISA)：數位取證和儲存媒體保存良好實踐指南。