Випадкове rm -rf або Shift-Delete в Linux, macOS або Windows: негайне перемонтування лише для читання¶

Перегляд випадкового 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 поки вони ще відкриті) і негайно скопіювати їхній необроблений вміст із оперативної пам’яті/кешу ядра на окремий диск або /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 на своєму корені (/) partition: Викликайте негайне аварійне перемонтування ядра лише для читання через 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 Time Machine і тіньові копії томів 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{"Чи може будь-який запущений процес (БД, редактор, сервер, хвіст) все ще мати відкритий видалений файл?"}

    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 Non-Root (/home, /data)"| RemountRO["Run: sudo mount -o remount,ro /mountpoint"]
    OSBranch -->|"Linux Root (/) Partition"| SysRqRO["Run: echo u | sudo tee /proc/sysrq-trigger (Kernel Emergency Read-Only Remount)"]
    OSBranch -->|"Windows C: Drive or macOS Boot APFS"| HardPower["DO NOT Shut Down Normally: Hold Power Button 10 Seconds or Pull Power Cord to Prevent Shutdown Log/Pagefile Writes"]
    OSBranch -->|"Secondary External or Data Drive"| UnmountSec["Unmount / Set Volume Read-Only Immediately and Disconnect Drive"]

    RemountRO --> LiveBoot["STEP 3: Boot External SystemRescue Live USB and Clone Partition with ddrescue to External Drive"]
    SysRqRO --> LiveBoot
    HardPower --> LiveBoot
    UnmountSec --> LiveBoot

    LiveBoot --> FSRecovery{"Select Recovery Method by Filesystem"}
    FSRecovery -->|"ext4 / ext3"| ExtRec["Journal Inode Recovery: ext4magic / extundelete / debugfs"]
    FSRecovery -->|"XFS / APFS / Unjournaled"| CarveRec["Signature and Header/Footer Carving: photorec / scalpel / foremost / xfs_irecover"]
    FSRecovery -->|"NTFS (Windows)"| NtfsRec["MFT Record Parsing: ntfsundelete / TestDisk / UFS Explorer / DMDE"]

Why every second mounted Read-Write (rw) destroys deleted files¶

To understand why immediate read-only remounting or hard power cutoff is a life-or-death decision for your data, examine what each modern filesystem actually modifies when you run unlink() (rm) or DeleteFileW() (Shift+Delete):

1. What happens inside ext4, XFS, APFS, і NTFS during deletion¶

When a file is deleted, no consumer operating system spends disk I/O bandwidth writing zeroes over a 10 gigabyte (10.7 billion byte) database or video file. Instead, the filesystem driver only mutates tiny metadata structures:

2. SSD TRIM (Discard / Deallocate) Бомба уповільненої дії¶

На обертовому жорсткому диску (HDD), сектори залишаються читабельними, доки не будуть перезаписані. На SSD (SATA або NVMe), коли файлова система видає a TRIM або Deallocate команда: - Більшість контролерів NVMe реалізують детермінізоване читання нуля після TRIM (DRAT / DZAT), повертаючись 0x00000000 (усі нулі) із рівня перекладу Flash (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: активні процеси, які тримають inode відкритим у пам’яті.

Золоте правило 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 (git reset --hard або git branch -D with .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 працює в оперативній пам’яті та /dev/pts (devpts) , псевдотермінальна файлова система віртуальної оперативної пам’яті. 2. На хмарних платформах (AWS EC2, GCP, Azure, DigitalOcean) негайно зробіть атомарний знімок EBS/Block Volume Snapshot із хмарної консолі або зупиніть екземпляр, від’єднайте кореневий том і приєднайте його лише для читання (/dev/xvdf) до чистого порятунку VM. 3. На віддаленому сервері без використання стисненого необробленого зображення замороженого розділу лише для читання безпосередньо через SSH на локальну робочу станцію:

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

Етап 3: перевірка прихованого копіювання під час запису (CoW) знімки та тіньові копії перед різьбленням¶

Перш ніж сканувати терабайти нерозподілених секторів, перевірте, чи ваша операційна система автоматично створила прихований знімок на певний момент часу:

1. macOS: Знімки APFS локальної машини часу (tmutil)¶

Навіть якщо ваш зовнішній диск Time Machine був відключений тижнями, macOS автоматично записує щогодини локальні знімки APFS Copy-on-Write на ваш внутрішній SSD (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, link it to a folder and copy your files to a USB drive:

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

3. Linux: Btrfs, ZFS, і LVM Snapshots¶

• On Btrfs (системи Fedora, openSUSE, Synology, Timeshift/Snapper): запустити sudo btrfs subvolume list -s / і перевірити /.snapshots/ або /run/timeshift/backup/timeshift-btrfs/snapshots/.
• On 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's jbd2 журнал (зазвичай розміром від 128 мегабайт до 1024 мегабайт) зберігає історичні копії нещодавно змінених блоків inode. Поки ви перемонтувалися ro до того, як важка дискова активність загорнула кільцевий буфер журналу, ext4magic витягує inode перед видаленням із журналу та реконструює ваші файли з незмінними оригінальними іменами файлів і деревами каталогів.

1. Бігати ext4magic щоб відновити всі файли, видалені протягом останніх 2 годин (-a) у відносному шляху (-f): (Опустіть початкову косу риску точки монтування в -f: для /home/kmyers/project на корені / перегородка, пас -f home/kmyers/project; якщо /home є власна перегородка, пас -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, Вікна NTFS НЕ обнуляє покажчики екстентів блоку (Data Runs) всередині головної таблиці файлів ($MFT) запис, коли файл видалено. Коли ви натискаєте Shift+Delete на NTFS, 1024-байт $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, або перезаписані журнали за допомогою Raw Block Carving (PhotoRec і grep -a -b)¶

Коли покажчики inode зникають (наприклад, на XFS, APFS або ext4 розділ, журнал якого загорнутий), відновити дані шляхом сканування нерозподілених блоків розміром 4096 байт (4 кілобайти) на пошук заголовків/нижніх колонтитулів або унікальних текстових рядків:

Як використовувати grep -a -b + dd щоб врятувати видалений вихідний код або .env файлів менш ніж за 2 хвилини¶

Якщо ви видалили вихідний код, .env секрети або нотатки розміром до 32 кілобайт: 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

Етап 5: Запобігання майбутнім катастрофам rm -rf і Shift+Delete аварії¶

• Замінити інтерактивний rm with 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 тому випадкові рекурсивні видалення запитують один раз перед від’єднанням inodes.
• Захист критичних робочих каталогів за допомогою незмінного атрибута 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 у всіх країнах-членах ЄС.
• Повідомлення про порушення доступності, стаття 33 GDPR: відповідно до Європейської ради із захисту даних (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 навіть якщо я досить швидко перестав користуватися комп’ютером?¶

Коли файл видаляється на ext4, ядро ​​Linux негайно обнуляє покажчики дерева екстентів у таблиці inode на диску, щоб файлова система знала, що inode не має виділених екстентів. Такі інструменти, як ext4magic і extundelete покладайтеся на пошук старішої, попередньо видаленої копії цього inode всередині ext4 журнал (jbd2). Якщо файл було створено та видалено, а його inode нещодавно не проходив через журнал, або якщо інтенсивні фонові записи загорнули кільцевий буфер журналу розміром від 128 МБ до 1 ГБ до того, як ви знову підключили режим лише для читання, копія журналу зникла. У такому випадку ви повинні перейти до різьблення сирого блоку (PhotoRec) або байтовий пошук у звичайному тексті (grep -a -b), які сканують нерозподілені блоки даних безпосередньо без необхідності метаданих inode.

Є SSD TRIM завжди знищувати rm -rf або Shift+Delete файли негайно?¶

Не завжди, особливо на Linux і зовнішніх дисках. У Windows 10/11 і macOS із внутрішніми NVMe SSD операційна система зазвичай надсилає вбудований ТРИМ / Вилучити команду до контролера SSD протягом декількох секунд після остаточного видалення, що спричиняє рівень Flash Translation Layer (FTL), щоб повернути нулі (ДЗАТ) для цих блоків. Однак більшість дистрибутивів Linux (Ubuntu, Debian, Fedora, RHEL) роблять ні увімкнути безперервний час монтування відкинути за замовчуванням; замість цього вони біжать fstrim.timer раз на тиждень. Крім того, багато зовнішніх корпусів USB-SATA та USB-NVMe не проходять ТРИМ команди через накопичувач USB (БОТ), а програмні рівні RAID / LVM / LUKS часто блокують відкинути передача за замовчуванням, якщо не налаштовано явно (`issue_discards = 1` або `allow-discards`).

Що робити, якщо мій розділ Linux зашифровано LUKS (dm-crypt) або мій диск Windows використовує BitLocker: чи можу я все одно вирізати видалені файли?¶

Так, якщо ви маєте парольну фразу шифрування або ключ відновлення та розблокуєте контейнер у режимі лише для читання. Ніколи не бігайте photorec, ext4magic, або тестовий диск проти необробленого зашифрованого фізичного розділу (/dev/nvme0n1p2), оскільки зашифрований зашифрований текст виглядає як випадковий шум. Натомість завантажтеся з Live USB, розблокуйте контейнер режим тільки для читання (для LUKS: sudo cryptsetup open --readonly /dev/nvme0n1p2 crypt_rescue; для BitLocker на Linux: деблокатор -р або розблокувати лише для читання в WinPE), а також створити зображення або сканувати розшифрований пристрій віртуального відображення (/dev/mapper/crypt_rescue).

Чому тягне шнур живлення на Windows C:\ безпечніше після нещасного випадку Shift+Delete ніж натиснути «Завершити роботу»?¶

Коли ви натискаєте Пуск > Вимкнути у Windows операційна система виконує сотні мегабайт запису на диск перед вимкненням: вона очищає кущі реєстру, записує події завершення роботи в .evtx журнали, оновлює журнал USN ($UsnJrnl), очищає або змінює розмір pagefile.sys, а в системах швидкого запуску записує багатогігабайтний файл сплячого режиму (hiberfil.sys) безпосередньо через нерозподілені кластери NTFS. Ці записи про завершення роботи часто перезаписують точні нерозподілені $MFT записів і кластерів даних, звільнених вашим Shift+Delete. Примусове миттєве вимкнення живлення (утримання кнопки живлення протягом 10 секунд або витягування штекера) негайно зупиняє всі записи; NTFS залишатиметься повністю читабельним під час завантаження з аварійного USB-пристрою Linux або WinPE, доступного лише для читання.

Як я можу відновити видалений .env файл, ключ SSH або файл вихідного коду, який PhotoRec проігноровано?¶

PhotoRec шукає двійкові магічні байтові заголовки (наприклад %PDF, PNG, або ПК для файлів ZIP/Office), тому він часто пропускає або об’єднує короткі файли звичайного тексту, наприклад .env конфігурації, вихідний код Python/JavaScript, примітки Markdown і ключі SSH. Щоб відновити будь-який простий текстовий файл із образу диска або розділу лише для читання, запустіть LC_ALL=C grep -a -b -C 100 "УНІКАЛЬНИЙ_ТЕКСТ_З_ФАЙЛУ" /dev/nvme0n1p2 > /dev/shm/found.txt. Якщо ви знаєте назву будь-якої змінної (наприклад, STRIPE_SECRET_KEY= або ПОЧАТИ OPENSSH ПРИВАТНИЙ КЛЮЧ), grep -a -b сканує необроблені сектори зі швидкістю кілька гігабайт на секунду та друкує точні навколишні дискові блоки.

Якби я випадково побіг rm -rf / або видалено /usr або /lib на Linux, а зараз навіть ні ls, cp, або sudo працює, як мені запускати команди у відкритому терміналі?¶

Якщо ви витерли /bin або /lib while an existing bash або zsh terminal is still open in RAM, external binaries like /bin/ls або /bin/cp will fail with No such file or directory, but shell built-ins still work entirely inside RAM. You can use echo * замість ls, printf "%s\n" "$(</proc/1234/fd/4)" > /dev/shm/rescued замість cp, і echo u > /proc/sysrq-trigger (if your shell is already root) to trigger a read-only kernel remount before powering off and booting a SystemRescue Live USB.

Пов'язані посібники¶

• Accidental file deletion, formatted drive, and photo recovery
• SSD and NVMe sudden read-only mode, 0% spare blocks, and TRIM disabling rescue
• Збій жорсткого диска та відновлення даних
• Погіршення роботи масиву NAS RAID, збій кількох дисків і відновлення ZFS/Btrfs
• Резервне копіювання комп’ютера, стратегія 3-2-1 та аварійне відновлення
• Номери екстрених служб по країнах

Джерела та офіційне керівництво¶

• Національний інститут стандартів і технологій (NIST) (United States): Special Publication 800-86: Guide to Integrating Forensic Techniques into Incident Response & SP 800-88 Rev. 1: Guidelines for Media Sanitization (ATA TRIM / NVMe Deallocate Behavior).
• The Linux Kernel Organization (kernel.org): Ext4 Filesystem Documentation (Block and Inode Allocation, jbd2 Journaling, and procfs /proc/<pid>/fd/ File Descriptor Semantics) & Linux Magic System Request Key (sysrq.txt).
• CGSecurity (TestDisk & PhotoRec Official Documentation) and ext4magic Upstream Reference Manual: Journal Inode Extraction and Unallocated Extent Carving on ext3/ext4 and NTFS Volumes.
• Агентство з кібербезпеки та безпеки інфраструктури (CISA) (United States): Incident Response and Forensic Volatile/Non-Volatile Evidence Preservation Best Practices.
• European Union Agency for Cybersecurity (ENISA): Good Practice Guide for Digital Forensics and Storage Media Preservation.