Случаен 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 устройство се е заключило поради износване на контролера, вижте 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 на вашия корен (/) 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 / Power за 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 Volume Shadow Copies), преди да прекарате часове в изрязване на необработени сектори: Много системи тихо запазват препратки към атомарни блокове в даден момент (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, редактор, сървър, опашка) все още да има отворен изтрит файл?"}

    OpenCheck -->|"Да (Linux / macOS все още работи)"| ProcRescue["СТЪПКА 1: Стартирайте незабавно sudo lsof +L1 и копирайте отворените файлови дескриптори от /proc/PID/fd/N на RAM диск (/dev/shm) или външен USB"]
    OpenCheck -->|"Не (или всички файлове бяха затворени)"| SnapCheck{"Томът използва ли ZFS, Btrfs, APFS Local Snapshots или Windows Shadow Copies?"}

    ProcRescue --> FreezeOS["СТЪПКА 2: Незабавно замразете всички записи на диск"]
    SnapCheck -->|"Да: CoW Snapshot съществува"| FreezeOS
    SnapCheck -->|"Не: Стандартен ext4, XFS или NTFS без моментни снимки"| FreezeOS

    FreezeOS --> OSBranch{"Коя операционна система и дял са засегнати?"}

    OSBranch -->|"Linux Non-Root (/home, /data)"| RemountRO["Стартирайте: sudo mount -o remount,ro /mountpoint"]
    OSBranch -->|"Основен (/) дял на Linux"| SysRqRO["Пусни: echo u | sudo tee /proc/sysrq-тригер (Спешно премонтиране на ядрото само за четене)"]
    OSBranch -->|"Windows C: Drive или macOS Boot APFS"| HardPower["НЕ изключвайте нормално: Задръжте бутона за захранване за 10 секунди или издърпайте захранващия кабел, за да предотвратите записите в журнал на изключване/файл на страница"]
    OSBranch -->|"Вторично външно устройство или устройство за данни"| UnmountSec["Незабавно демонтирайте/задайте обем само за четене и изключете устройството"]

    RemountRO --> LiveBoot["СТЪПКА 3: Стартирайте External SystemRescue Live USB и клонирайте дял с ddrescue на външно устройство"]
    SysRqRO --> LiveBoot
    HardPower --> LiveBoot
    UnmountSec --> LiveBoot

    LiveBoot --> FSRecovery{"Изберете метод за възстановяване по файлова система"}
    FSRecovery -->|"ext4 / ext3"| ExtRec["Възстановяване на Inode на журнала: ext4magic / extundelete / debugfs"]
    FSRecovery -->|"XFS / APFS / Нерегистриран"| CarveRec["Изрязване на подпис и горен/долен колонтитул: photorec / scalpel / foremost / xfs_irecover"]
    FSRecovery -->|"NTFS (Windows)"| NtfsRec["Разбор на MFT запис: ntfsundelete / TestDisk / UFS Explorer / DMDE"]

Защо всеки втори монтиран Read-Write (rw) унищожава изтритите файлове¶

За да разберете защо незабавното повторно монтиране само за четене или твърдото прекъсване на захранването е решение на живот или смърт за вашите данни, разгледайте какво всъщност променя всяка съвременна файлова система, когато стартирате unlink() (rm) или DeleteFileW() (Shift+Delete):

1. Какво се случва вътре ext4, XFS, APFS, и NTFS по време на изтриване¶

Когато файл бъде изтрит, никоя потребителска операционна система не изразходва дискова I/O честотна лента за запис на нули върху 10 гигабайта (10,7 милиарда байта) база данни или видео файл. Вместо това драйверът на файловата система променя само малки структури на метаданни:

2. SSD TRIM (Discard / Deallocate) Бомба със закъснител¶

На въртящ се твърд диск (HDD), секторите остават четими, докато не бъдат презаписани. На SSD (SATA или NVMe), когато файлова система издава a TRIM или Deallocate команда: - Повечето NVMe контролери прилагат Deterministic Read Zero after TRIM (DRAT / DZAT), връщане 0x00000000 (всички нули) от Flash Translation Layer (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> в RAM (/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 код / курсор / локална история на VSCodium: Съхранява автоматично копия с клеймо за време на всеки записан файл вътре -/.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 с .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 изключването записва мегабайти от 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 / 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 / Сървър: копия на томове в сянка (VSS)¶

1. Отворете Administrator Command Prompt и изпълнете:

   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 мегабайта до 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, Windows NTFS НЕ нулира указателите на блоковия екстент (Data Runs) в основната файлова таблица ($MFT) запис при изтриване на файл. Когато натиснете Shift+Delete на NTFS, 1024-байтовият $MFT записът просто обръща своя флаг за заглавка от 0x01 (В употреба) до 0x00 (Изтрито). Това е $FILE_NAME атрибут и $DATA cluster runlist остават 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 дял, чийто дневник е обвит), възстановяване на данни чрез сканиране на неразпределени 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 с 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 Immutable Attribute (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, или два пъти дневно Volume Shadow Copies в 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 от ОРЗД: Съгласно Европейския съвет за защита на данните (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 MB до 1 GB пръстен буфер на дневника, преди да монтирате отново само за четене, копието на дневника е изчезнало. В такъв случай трябва да превключите към издълбаване на необработен блок (PhotoRec) или търсене в байтове в обикновен текст (grep -a -b), които сканират неразпределени блокове данни директно, без да се нуждаят от метаданни на inode.

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

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

Ами ако моят Linux дял е шифрован с LUKS (dm-crypt) или моето Windows устройство използва BitLocker: мога ли все още да изрязвам изтрити файлове?¶

Да, при условие че имате паролата за шифроване или ключа за възстановяване и отключите контейнера в режим само за четене. Никога не бягайте фоторец, 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 Journal ($UsnJrnl), изчиства или преоразмерява pagefile.sys, а на системи с бързо стартиране записва мултигигабайтов файл за хибернация (hiberfil.sys) директно през неразпределени NTFS клъстери. Тези записи при изключване често презаписват точния неразпределен $MFT записи и клъстери от данни, освободени от вашите Shift+Delete. Принудителното незабавно изключване (задържане на бутона за захранване за 10 секунди или издърпване на щепсела) незабавно спира всички записи; NTFS ще остане напълно четим, когато се стартира от Linux или WinPE спасителен USB само за четене.

Как мога да възстановя изтрит .env файл, SSH ключ или файл с изходен код, който PhotoRec игнориран?¶

PhotoRec търси заглавки на двоични магически байтове (като %PDF, PNG, или 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. Ако знаете някакво име на променлива (като напр STRIPE_SECRET_KEY= или ЗАПОЧНЕТЕ ОТВАРЯНЕ НА ЧАСТЕН КЛЮЧ), grep -a -b сканира необработените сектори с няколко гигабайта в секунда и отпечатва точните околни дискови блокове.

Ако случайно избягах rm -rf / или изтрити /usr или /lib на Linux и сега дори не ls, cp, или sudo работи, как да изпълнявам команди в моя отворен терминал?¶

Ако сте изтрили /bin или /lib докато съществува баш или zsh терминалът все още е отворен в RAM, външни двоични файлове като /bin/ls или /bin/cp ще се провали с Няма такъв файл или директория, но вградените shell все още работят изцяло в RAM. Можете да използвате ехо * вместо ls, printf "%s\n" "$( /dev/shm/rescued вместо cp, и echo u > /proc/sysrq-тригер (ако вашата обвивка вече е 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 Deallocate Behavior).
• Организацията на ядрото на Linux (kernel.org): Документация за файловата система Ext4 (Разпределение на блокове и Inode, jbd2 Водене на дневник и procfs /proc/<pid>/fd/ Семантика на файловия дескриптор) и Linux Magic System Request Key (sysrq.txt).
• CGSecurity (TestDisk и PhotoRec Официална документация) и ext4magic Справочно ръководство нагоре по веригата: Извличане на Inode от журнала и изрязване на неразпределен екстент на томове ext3/ext4 и NTFS.
• Агенция за киберсигурност и сигурност на инфраструктурата (CISA) (Съединени щати): Най-добри практики за реакция при инциденти и съдебномедицинско съхранение на летливи/нелетливи доказателства.
• Агенция на Европейския съюз за киберсигурност (ENISA): Ръководство за добри практики за цифрова криминалистика и съхранение на носители за съхранение.