Accidental rm -rf או Shift-Delete ב-Linux, macOS או Windows: התקנה מחדש מיידית לקריאה בלבד¶

צופה בשוגג rm -rf, find -delete, git clean -fdx, או Windows Shift+Delete מחיקת מסדי נתונים קריטיים של ייצור, קוד מקור או קבצים אישיים מבלי לשלוח אותם לסל המיחזור או לתיקיית האשפה מעוררת פאניקה מיידית. עם זאת, גם לא rm -rf גם לא Shift+Delete למעשה מאפסת את מגזרי האחסון הבסיסיים שלך ברגע שהפקודה הושלמה: במקום זאת, מערכת ההפעלה פשוט מנתקת את ערך הספרייה, מעדכנת את יומן המטא-נתונים שלה ומסמנת את מצביעי האינוד או טבלת הקבצים הראשית (MFT) מתעד וחוסם מפות סיביות כזמינות לשימוש חוזר. מה שהורס לצמיתות את הקבצים שנמחקו הוא בכל שנייה מערכת הקבצים נשארת רכונה בקריאה-כתיבה (rwמצב ) לאחר המחיקה, בתור יומני מערכת ברקע (systemd-journald, rsyslog), מטמון דפדפן, פעילות החלפה ו-SSD TRIM / discard פקודות מחליפות במהירות את הבלוקים החדשים ששוחררו. אם המערכת שלך במקום זאת סובלת מקליקות פיזיות, סקטורים פגומים או בקר מת, עצור ועבור למדריך שלנו כשל בכונן הקשיח ושחזור נתונים, או אם כונן המצב המוצק שלך ננעל עקב בלאי של הבקר, ראה מצב SSD ו-NVMe פתאומי לקריאה בלבד ו-TRIM משבית הצלה; לטעויות עיצוב רחבות יותר או בעיות בכרטיסי מצלמה, התייעצו מחיקת קבצים בשוגג, כונן מעוצב ושחזור תמונות. אם אירוע זה כולל חבלה פלילית, סחיטה או הפסקת מערכת בטיחות חיים, התקשר למספר החירום המקומי שלך (911 בארצות הברית ובקנדה, 112 ברחבי האיחוד האירופי, 999 בבריטניה) או עיין במדריך הבינלאומי שלנו של מספרי חירום.

תעשה את זה עכשיו¶

1. לחץ Ctrl+C מיד אם פקודת המחיקה עדיין פועלת, ואל תסגור חלונות מסוף פתוחים, עורכי טקסט, נגני מדיה או דמוני מסד נתונים: אם תוכנית פועלת כלשהי (nginx, postgres, mysqld, vim, code, python, tail, או נגן וידאו) עדיין הקובץ שנמחק פתוח בזיכרון, ליבת לינוקס או 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. על לינוקס (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 / Power למשך 10 שניות כדי לעצור את זרקור הרקע (mds_stores) ו fseventsd כותב.
7. בווינדוס (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. אתחול מ-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) לפני שמבזבזים שעות על גילוף סקטורים גולמיים: מערכות רבות שומרות בשקט הפניות בלוק אטומי של נקודת זמן (tmutil listlocalsnapshots / ב-macOS, vssadmin list shadows בווינדוס, 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, Editor, Server, Tail) עדיין יכול לפתוח את הקובץ שנמחק?"}

    OpenCheck -->|"כן (לינוקס / 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 קיימת"| FreezeOS
    SnapCheck -->|"לא: ext4, XFS או NTFS סטנדרטי ללא צילומי מצב"| FreezeOS

    FreezeOS --> OSBranch{"איזו מערכת הפעלה ומחיצה נפגעו?"}

    OSBranch -->|"לינוקס ללא שורש (/home, /data)"| RemountRO["הפעלה: sudo mount -o remount,ro /mountpoint"]
    OSBranch -->|"מחיצת שורש לינוקס (/)."| SysRqRO["ריצה: echo u | sudo tee /proc/sysrq-trigger (תכונה מחדש לקריאה בלבד)"]
    OSBranch -->|"Windows C: Drive או macOS Boot APFS"| HardPower["אל תכבה כרגיל: החזק את לחצן ההפעלה 10 שניות או משוך את כבל החשמל כדי למנוע כתיבת יומן/דף כיבוי"]
    OSBranch -->|"כונן נתונים חיצוני משני"| UnmountSec["בטל את הטעינה / הגדר את עוצמת הקול לקריאה בלבד ונתק את הכונן"]

    RemountRO --> LiveBoot["שלב 3: אתחול מערכת החיצונית Rescue 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 במהלך המחיקה¶

כאשר קובץ נמחק, אף מערכת הפעלה צרכנית לא מבזבזת רוחב פס של קלט/פלט דיסק בכתיבת אפסים מעל מסד נתונים של 10 גיגה-בייט (10.7 מיליארד בתים) או קובץ וידאו. במקום זאת, מנהל ההתקן של מערכת הקבצים משנה רק מבני מטא נתונים זעירים:

2. ה-SSD TRIM (Discard / Deallocate) פצצת זמן¶

בכונן קשיח מסתובב (HDD), סקטורים נשארים קריאים עד שיודפסו. על SSD (SATA או NVMe), כאשר מערכת קבצים מנפיקה א TRIM או Deallocate פקודה: - רוב בקרי ה-NVMe מיישמים קריאה דטרמיניסטית אפס לאחר TRIM (DRAT / DZAT), חוזר 0x00000000 (כולם אפסים) משכבת התרגום של פלאש (FTL) מיד עם קבלתו TRIM, עוד לפני הפעלת איסוף האשפה הפיזי של NAND. - למה מערכות לינוקס לרוב שורדות TRIM: רוב הפצות לינוקס (Ubuntu, Debian, Fedora, RHEL) אל תאפשר זמן הרכבה רציף discard כברירת מחדל; הם מפעילים טיימר שבועי (fstrim.timer). אם תעלה מחדש לקריאה בלבד (ro) לפני fstrim.timer פועל, ה-SSD עדיין לא ביטל את מיפוי הבלוקים האלה.

שלב 1: הצלת קבצים שנמחקו שעדיין פתוחים בתהליך פועל (/proc/<pid>/fd/)¶

לפני שאתה אתחול מחדש, מבטל את הטעינה או סוגר חלון בודד ב-Linux או macOS, בדוק אם קיימים מתארי קבצים פתוחים. במערכות POSIX, rm שיחות unlink(). הקרנל עוקב אחר שני מונים עבור כל אינוד: 1. i_nlink: ערכי ספרייה בדיסק המצביעים על האינוד. 2. i_count: תהליכים פעילים המחזיקים את האינוד פתוח בזיכרון.

כלל ה-POSIX המוזהב: הגרעין לעולם לא משחרר את האינוד או מבטל קובצי דיסק עד שניהם i_nlink == 0 ו i_count == 0. אם מסד נתונים, יומן, וידאו או קוד שנמחקו עדיין פתוחים בתהליך כלשהו, 100 אחוז מהקובץ הזה נשאר שלם בדיסק.

שלב אחר שלב /proc/<pid>/fd/ חילוץ בלינוקס¶

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/ (לינוקס), -/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 (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. לינוקס: הרכבה מחדש של מחיצת נתונים לעומת השורש (/) מחיצה לקריאה בלבד¶

• תרחיש א': הקבצים שנמחקו היו במחיצה נפרדת (/home, /var, /data, /mnt/storage):
• נסה מיד לבצע remount נקי לקריאה בלבד:

  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.
• תרחיש ב': הקבצים שנמחקו היו בשורש (/) מחיצה (או שאינך יכול להרוג תהליכים עסוקים): אל תרוץ sudo reboot או sudo shutdown -h now, כי נורמלי systemd כיבוי כותב מגה בייט של journald יומני כיבוי, זרעים אקראיים וקבצי מצב שירות ישירות אל /. במקום זאת, הפעל את Linux Kernel Magic SysRq 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: בדיקת Copy-on-Write מוסתר (CoW) צילומי מצב ועותקי צל לפני גילוף¶

לפני סריקת טרה-בייט של סקטורים לא מוקצים, בדוק אם מערכת ההפעלה שלך יצרה אוטומטית תמונת מצב נסתרת של נקודת זמן:

1. macOS: Local Time Machine APFS Snapshots (tmutil)¶

גם אם כונן Time Machine החיצוני שלך היה מנותק במשך שבועות, macOS מקליט אוטומטית תמונות APFS מקומיות של העתקה-על-כתיבה ב-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: Volume Shadow Copies (VSS)¶

1. פתח שורת פקודה של מנהל מערכת והפעל:

   vssadmin list shadows
   

2. אם עותק צל (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1) מקדימה את שלך Shift+Delete, קשר אותו לתיקיה והעתק את הקבצים שלך לכונן USB:

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

3. לינוקס: 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, יומן ו-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 בלינוקס (ext4magic ו extundelete)¶

מתי rm -rf מוחק קבצים על ext4, הגרעין מאפס את מצביעי עץ המידה בתוך טבלת האינוד הראשית. עם זאת, ext4של jbd2 יומן (בדרך כלל בגודל של 128 מגה-בייט עד 1,024 מגה-בייט) מאחסן עותקים היסטוריים של בלוקי האינוד ששונו לאחרונה. כל עוד עלית מחדש ro לפני שפעילות כבדה בדיסק עטפה את מאגר הטבעת היומן, ext4magic מחלץ את האינוד מראש המחיקה מהיומן ומשחזר את הקבצים שלך עם שמות קבצים מקוריים ועצי ספריות ללא פגע.

1. רוץ ext4magic כדי לשחזר את כל הקבצים שנמחקו במהלך השעתיים האחרונות (-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, ה-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)¶

כאשר מצביעי האינוד נעלמים (כגון ב-XFS, APFS, או ext4 מחיצה שהיומן שלה עטוף), שחזר נתונים על ידי סריקת בלוקים של 4,096 בתים (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 אז מחיקות רקורסיביות בשוגג מבקשות פעם אחת לפני ביטול הקישור לאינודים.
• הגן על ספריות ייצור קריטיות עם התכונה הבלתי ניתנת לשינוי של 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, או פעמיים ביום 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 בכל המדינות החברות באיחוד האירופי.
• ** 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 למרות שהפסקתי להשתמש במחשב די מהר?¶

כאשר קובץ נמחק ב- ext4, ליבת הלינוקס מאפסת מיד את מצביעי עץ המידה בתוך טבלת האינוד שבדיסק, כך שמערכת הקבצים יודעת שלאינודה אין היקף הוקצו. כלים כמו ext4magic ו מחק הסתמכו על מציאת עותק ישן יותר, שנמחק מראש של האינוד הזה בתוך ext4 יומן (jbd2). אם הקובץ נוצר ונמחק מבלי שה-inode שלו עבר לאחרונה ביומן, או אם כתיבת רקע כבדה עטפה את מאגר צלצול היומן של 128 מגה-בייט עד 1 ג'יגה-בייט לפני שהעלית מחדש לקריאה בלבד, עותק היומן נעלם. במקרה כזה, עליך לעבור לגילוף חתימות גולמיות (PhotoRec) או חיפוש בתים בטקסט רגיל (grep -a -b), אשר סורקים בלוקי נתונים לא מוקצים ישירות מבלי להזדקק למטא-נתונים של inode.

עושה SSD TRIM תמיד להרוס rm -rf או Shift+Delete קבצים מיד?¶

לא תמיד, במיוחד בלינוקס ובכוננים חיצוניים. ב-Windows 10/11 ו-macOS עם כונני NVMe SSD פנימיים, מערכת ההפעלה בדרך כלל שולחת הודעה מוטבעת TRIM / בטל הקצאה פקודה לבקר ה-SSD תוך שניות ממחיקה לצמיתות, מה שגורם לשכבת תרגום הפלאש של ה-SSD (FTL) כדי להחזיר אפסים (DZAT) עבור אותם בלוקים. עם זאת, רוב ההפצות של לינוקס (אובונטו, דביאן, פדורה, RHEL) כן לא לאפשר זמן הרכבה מתמשך להשליך כברירת מחדל; במקום זאת, הם רצים fstrim.timer פעם בשבוע. יתר על כן, מארזים חיצוניים רבים מסוג USB-to-SATA ו-USB-to-NVMe אינם עוברים TRIM פקודות דרך אחסון המוני USB (BOT), ושכבות תוכנה RAID / LVM / LUKS חוסמות לעתים קרובות להשליך מעבר כברירת מחדל אלא אם כן מוגדר במפורש (`issue_discards = 1` או `allow-discards`).

מה אם מחיצת הלינוקס שלי מוצפנת עם LUKS (dm-crypt) או כונן Windows שלי משתמש BitLocker: האם אני עדיין יכול לגלף קבצים שנמחקו?¶

כן, בתנאי שיש לך את משפט הסיסמה או מפתח השחזור של ההצפנה ותבטל את נעילת המכולה במצב קריאה בלבד. לעולם אל תברח photorec, ext4magic, או דיסק בדיקה כנגד המחיצה הפיזית המוצפנת הגולמית (/dev/nvme0n1p2), כי טקסט צופן מוצפן נראה כמו רעש אקראי. במקום זאת, אתחל מ-USB Live, בטל את נעילת המיכל פנימה מצב קריאה בלבד (עבור LUKS: sudo cryptsetup open --readonly /dev/nvme0n1p2 crypt_rescue; עבור BitLocker בלינוקס: dislocker -r או פתח את הנעילה לקריאה בלבד ב-WinPE), ותצלם או סרוק את התקן הממפה הווירטואלי המפוענח (/dev/mapper/crypt_rescue).

למה מושך את כבל החשמל ב-Windows C:\ בטוח יותר לאחר תאונה Shift+Delete מאשר ללחוץ על "כיבוי"?¶

כאשר אתה לוחץ התחל > כיבוי ב-Windows, מערכת ההפעלה מבצעת מאות מגה-בייט של כתיבת דיסק לפני כיבוי: היא שוטפת את כוורות הרישום, כותבת אירועי כיבוי ל-Windows. .evtx יומנים, מעדכן את יומן USN ($UsnJrnl), מנקה או משנה גודל pagefile.sys, ובמערכות הפעלה מהירה כותב קובץ שינה מרובה גיגה-בייט (hiberfil.sys) ישירות על פני אשכולות NTFS לא מוקצים. כתבי כיבוי אלה מחליפים לעתים קרובות את המדויק שלא הוקצה $MFT רשומות ואשכולות נתונים ששוחררו על ידיך Shift+Delete. אילוץ כיבוי מיידי (החזקת לחצן ההפעלה למשך 10 שניות או משיכת התקע) עוצרת את כל הכתיבה באופן מיידי; NTFS יישאר קריא לחלוטין בעת ​​אתחול מ-Linux או WinPE rescue 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= או התחל OPENSSH מפתח פרטי), grep -a -b סורק את הסקטורים הגולמיים בכמה גיגה-בייט לשנייה ומדפיס את בלוקי הדיסק שמסביב.

אם רצתי בטעות rm -rf / או נמחק /usr או /lib בלינוקס ועכשיו אפילו לא ls, cp, או sudo עובד, איך אני מפעיל פקודות בטרמינל הפתוח שלי?¶

אם ניגבת /bin או /lib בעוד קיים bash או זש המסוף עדיין פתוח ב-RAM, כמו קבצים בינאריים חיצוניים /bin/ls או /bin/cp ייכשל עם אין קובץ או ספרייה כאלה, אבל המעטפת המובנית עדיין פועלת לחלוטין בתוך זיכרון RAM. אתה יכול להשתמש הד* במקום ls, printf "%s\n" "$( /dev/shm/rescued במקום cp, ו echo u > /proc/sysrq-trigger (אם המעטפת שלך כבר שורשית) כדי להפעיל התקנה מחדש של ליבה לקריאה בלבד לפני כיבוי ואתחול של SystemRescue Live USB.

מדריכים קשורים¶

• מחיקת קבצים בשוגג, כונן מעוצב ושחזור תמונות
• מצב קריאה פתאומי של SSD ו-NVMe, 0% חסימות חילוף ו-TRIM השבתת הצלה
• כשל בכונן קשיח ושחזור נתונים
• מערך RAID של NAS פגום, כשל בכוננים מרובים ושחזור ZFS/Btrfs
• גיבוי מחשבים, אסטרטגיית 3-2-1, והתאוששות מאסון
• מספרי חירום לפי מדינה

מקורות והדרכה רשמית¶

• המכון הלאומי לתקנים וטכנולוגיה (NIST) (ארצות הברית): פרסום מיוחד 800-86: מדריך לשילוב טכניקות משפטיות בתגובת תקריות ו-SP 800-88 Rev. 1: הנחיות לניקוי מדיה (ATA TRIM / NVMe Deallocate Behavior).
• ארגון ליבת לינוקס (kernel.org): תיעוד מערכת הקבצים Ext4 (הקצאת חסימה ואינוד, jbd2 כתב יומן, ו procfs /proc/<pid>/fd/ סמנטיקה של מתאר קבצים) ומפתח בקשת מערכת הקסם של לינוקס (sysrq.txt).
• CGSecurity (TestDisk & PhotoRec תיעוד רשמי) ו ext4magic מדריך עזר במעלה הזרם: חילוץ אינודות יומן וגילוף היקף לא מוקצה בנפחי ext3/ext4 ו-NTFS.
• הסוכנות לאבטחת סייבר ותשתיות (CISA) (ארצות הברית): שיטות עבודה מומלצות לשימור עדויות נדיפות/לא נדיפות לאירועים וזיהוי פלילי.
• סוכנות האיחוד האירופי לאבטחת סייבר (ENISA): מדריך נוהג טוב לזיהוי פלילי דיגיטלי ושימור אמצעי אחסון.