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)：数字取证和存储介质保存良好实践指南。