Нобудкунии тасодуфии файл, корти SD форматшуда ва барқарорсозии акс¶

Realizing that you just formatted the wrong camera SD card, emptied the Recycle Bin or Trash on an external work drive, or accidentally wiped an entire partition of irreplaceable family photos is an acute technical crisis. When a file is deleted or a storage medium is quick-formatted, the operating system rarely erases the raw binary data inside the memory cells right away. Instead, it removes the file system directory pointer and marks those logical block addresses as "free space" available to be overwritten. Whether you recover 100 percent of your data or lose it forever depends entirely on what happens during the first 60 seconds after deletion. Every single second the drive remains mounted in read-write mode, background operating system indexing, swap files, browser caches, and Solid State Drive (SSD) garbage collection routines (TRIM / UNMAP) can permanently zero out the underlying sectors.

If the accidental deletion or formatting involves medical telemetry, legal evidence in an active crime, or a life-safety system failure, call your local emergency number (911 дар Иёлоти Муттаҳида ва Канада, 112 дар саросари Иттиҳоди Аврупо, 999 дар Британияи Кабир) ё ба феҳристи байналмилалии мо муроҷиат кунед рақамҳои фавқулодда before touching the hardware. For all consumer, photographic, academic, and enterprise data loss incidents, halt all disk activity immediately and follow the forensic recovery workflow below.

Ҳоло ин корро кунед¶

1. Pull out the removable SD card, CFexpress card, or USB drive immediately: If you just formatted a camera memory card or deleted files on an external USB drive, turn off the camera power switch immediately or unplug the external USB cable from the computer. Do not take "one test photo" to see if the card works, and do not allow Windows (chkdsk) or macOS (fsck_apfs) to "scan and repair" the drive.
2. If you deleted files from your computer's internal system drive (C: drive or macOS Macintosh HD), yank the power or force an hard power-off: Do not close apps normally, do not download data recovery software onto the affected computer, and do not click "Shut Down" (which writes gigabytes of hibernation files, registry hives, and session logs over your deleted blocks). Hold the physical power button for 5 to 10 seconds until the machine powers off completely, or unplug the desktop power cord if it is a non-battery system.
3. Slide the physical write-protect switch on full-size SDHC/SDXC cards to the LOCK position: Look at the left edge of a standard 32 millimeter by 24 millimeter (1.26 inch by 0.94 inch) SD card and push the tiny plastic tab down toward the bottom edge (away from the gold contact pins) so no reader can accidentally write .DS_Store, System Volume Information, or Spotlight index files when you plug it in later.
4. Understand the SSD TRIM trap before powering an internal SSD back on: Modern NVMe and SATA Solid State Drives execute hardware-level TRIM (ATA) or Deallocate (NVMe) commands within seconds to minutes of file deletion or formatting. Once the SSD controller runs background garbage collection on trimmed pages, raw carving software will read only zeros (0x00). Keeping power off stops the internal SSD microprocessor from finishing background garbage collection.
5. Prepare a separate, clean secondary computer and a larger destination drive: Never install recovery tools onto the drive that lost data, and never restore recovered files back onto the same source drive during the scan. Use a second computer (or boot the affected PC from an external Ubuntu Linux Live USB flash drive) and attach a blank external hard drive with at least twice the storage capacity of the affected drive.
6. Create a sector-by-sector raw binary image (.img ё .dd) before running any file recovery parser: Before running PhotoRec, R-Studio, DMDE, or UFS Explorer, use ddrescue or HDDSuperClone to clone every sector of the SD card or drive into a single image file on your backup drive. You can then run multiple recovery algorithms safely against the image file without ever risking further wear or accidental writes on the original media.

Decision tree: choosing the right recovery strategy by storage media and file system¶

Use this forensic triage flowchart to determine whether your deleted data can be recovered via logical file-table reconstruction, raw file signature carving, or specialized chip-off analysis:

flowchart TD
    A["Accidental File Deletion or Drive Format Detected"] --> B["Immediately Power Off Device or Eject Removable Media"]
    B --> C{"What type of physical storage hardware is affected?"}
    C -->|"Camera SD / MicroSD / CFexpress / USB Flash"| D["Engage Physical Write-Protect Switch or Use Read-Only USB Blocker"]
    C -->|"External or Internal Mechanical Hard Drive (HDD)"| E["Хавфи TRIM вуҷуд надорад: Эҳтимолияти баланди барқароршавӣ дар сурати рух додани навиштаҷоти нав"]
    C -->|"SSD дохилӣ ё беруна / NVMe / Mac / Смартфон"| F{"Кадом системаи файлӣ ва пайвасти ОС истифода мешуд?"}
    F -->|"NTFS, APFS ё ext4 дар NVMe/SATA SSD дохилӣ"| G["Хатари баланди TRIM: Боркунӣ тавассути Linux Live USB бо libata.force=noncqtrim"]
    F -->|"exFAT ё FAT32 аз нигоҳдории оммавии стандартии USB"| H["Хатари TRIM-и мӯътадил/кам: Бисёр пулҳои USB аз TRIM дар exFAT намегузаранд"]
    F -->|"Захираи дохилии iOS / Android"| I["Рамзгузории сахтафзор дар асоси файл (FBE): Калидҳо ҳангоми ҳазф нобуд карда шудаанд, захираҳои абрӣ/маҳаллиро фавран санҷед"]
    D --> J["Эҷоди пурраи Bitstream Clone (.img) Бо истифода аз GNU ddrescue дар диски алоҳида"]
    E --> J
    G --> J
    H --> J
    J --> K{"Оё файлҳо ба таври алоҳида нест карда шуданд ё диск формат карда шудааст?"}
    K -->|"Несткунии инфиродӣ / Формати зуд (Метамаълумот бетаъсир)"| L["Таҷдиди метамаълумоти мантиқиро иҷро кунед (DMDE, R-Studio, UFS Explorer, TestDisk)"]
    K -->|"Ҷадвали файли аз нав навишташуда / Формати камера дар бадан"| M["Иҷроиши кандакории имзои файли хом + барқароркунандаи видеои фрагменталӣ (таъмири PhotoRec, GoPro/MP4)"]

Физикаи ҳазф: лавҳаҳои магнитии HDD бар зидди Flash SSD NAND ва кортҳои камераи SD¶

Барои пешгирӣ кардани нобуд кардани маълумоти барқароршаванда, шумо бояд фаҳмед, ки чӣ гуна меъмории гуногуни нигаҳдорӣ ҳазф ва форматкуниро дар зери сарпӯш идора мекунад.

1. Дискҳои сахти механикӣ (HDD) ва сабти магнитӣ (SMR)¶

Дар сабти анъанавии магнитии анъанавӣ (CMR) чарх задани диски сахт, нест кардани файл ё иҷро кардани "Формати зуд" камтар аз ду сонияро мегирад, зеро сарлавҳаҳои хондан/навишт танҳо индекси директорияи асосӣро тағир медиҳанд, масалан $MFT (Ҷадвали асосии файл) дар NTFS, Bitmap тақсимот ва каталоги B-tree дар HFS+/APFS ё Ҷадвали тақсимоти файлҳо дар FAT32/exFAT. Тағйирёбии воқеии ҷараёнҳои магнитӣ, ки JPEG, PDF ва ҷадвалҳои электронии шуморо муаррифӣ мекунанд, дар табақҳои кобальти хӯлаи шумо то он даме, ки системаи пардозандаро дар ин суроғаҳои дақиқи Блоки Мантиқӣ (LBAs) навиштани файли нав интихоб накунад, бетараф мемонанд.

Бо вуҷуди ин, бисёре аз дискҳои сахти берунии истеъмолии дорои иқтидори баландсифат (одатан аз 2 терабайт то 5 терабайт дар корпусҳои сайёри 2,5 дюймӣ) Сабти магнитии Shingled (SMR)-ро дар баробари қабати тарҷумаи нармафзори дохилӣ бо номи Кэши медиа истифода мебаранд. Баъзе дискҳои сахти муосири SMR воқеан дастгирӣ мекунанд TRIM фармон ба мисли SSD. Агар шумо папкаи калонро дар диски сахти SMR-и бо TRIM фаъолшударо нест кунед ва онро дар васлаки 20 дақиқа дар ҳолати корношоям гузоред, нармафзори дохилии гардонанда метавонад тасмаҳои шинонидашудаи худро аз нав ташкил кунад ва бахшҳои ҷудонашударо дар замина ба таври доимӣ сифр кунад. Хомӯш кардани диск фавран ин давраи нигоҳдории дохилиро пешгирӣ мекунад.

2. Дискҳои сахти давлатӣ (SSD), NVMe ва TRIM / Deallocate Равзанаи иҷро¶

Хотираи флеши NAND дар дохили SSDҳо наметавонад маълумоти мавҷударо мустақиман дар ҷои худ баргардонад. Пеш аз он ки ячейкаи флеши NAND маълумоти навро қабул кунад, тамоми блоки флешдор (одатан аз 4 мегабайт то 16 мегабайт андозаи) бояд аввал аз як давраи сусти барқии Барнома/Тозакунии (P/E) гузарад. Агар SSD мунтазир шавад, ки шумо файли навро барои нест кардани блокҳои кӯҳна захира кунед, суръати навиштан якбора паст мешавад.

Барои зуд нигоҳ доштани SSD-ҳо, системаҳои оператсионии муосир (Windows 7 то Windows 11, macOS 10.10+ ва ядроҳои Linux бо fstrim ё discard) фавран фиристед TRIM (SATA) ё Dataset Management: Deallocate Фармони (NVMe) ба контролери SSD лаҳзае, ки шумо қуттии партовро холӣ мекунед ё Формати зудро иҷро мекунед:

1. Хондани сифр пас аз TRIM (DZAT / DRAT): Тақрибан ҳама NVMe истеъмолкунанда ва SATA SSD-ҳои замонавӣ сифркунии детерминистиро пас аз TRIM татбиқ мекунанд. Миллисонияи дақиқ контроллери SSD мегирад TRIM фармон барои як қатор бахшҳо, қабати дохилии Flash Translation (FTL) он суроғаҳои мантиқиро аз саҳифаҳои физикии NAND хориҷ мекунад.
2. Бозгашти фаврии сифр: Ҳатто пеш аз нест кардани заряди физикии барқ ​​аз ҳуҷайраҳои кремний, агар ягон нармафзор (аз ҷумла ddrescue, PhotoRec, ё R-Studio) аз SSD хоҳиш мекунад, ки ин бахшҳои буридашударо тавассути фармонҳои стандартии SATA ё NVMe хонад, контролери SSD дархостро боздошта ва сифрҳои шонздаҳӣ баргардонад (00 00 00 00) бидуни тафтиши чипҳои физикии NAND.
3. Вақте ки барқароркунии SSD ҳанӯз имконпазир аст:
   • Бастҳои USB-и берунӣ бидуни гузариши UASP/TRIM: Чипҳои пулии кӯҳнаи USB 3.0 бо истифода аз протоколи BOT (танҳо барои интиқол), на UASP (Protocol ба USB замимашуда) системаи амалиётиро тарҷума карда наметавонанд. TRIM фармонҳо тавассути сими USB.
   • ** Ҳаҷмҳои FAT32 ва exFAT дар версияҳои муайяни ОС**: Таърихан, якчанд системаи амалиётӣ танҳо дар вақти воқеӣ фиристода мешаванд TRIM фармонҳо дар системаҳои файлии журнали маҳаллӣ (NTFS, APFS, ext4) ва дар вақти воқеӣ фавран нашр накардааст TRIM оид ба ҷудошаванда FAT32 ё exFAT қисмҳо.
   • ** Тозакунии ҷадвали тақсимот (diskpart clean ё ҳазфи тасодуфии бахш) бе Форматкунӣ**: Тоза кардани вуруди қисмат аз Ҷадвали Қисмҳои GUID (GPT) ё Сабти Master Boot (MBR) баъзан бахшҳои асосиро то формат кардани системаи нави файлӣ дар болои он бурида намемонад.

3. Camera In-Body Formatting and the Sony / Canon / Nikon SD_ERASE Trap¶

Photographers and videographers frequently assume that formatting an SD, microSD, or CFexpress card inside a digital camera is identical to a "Quick Format" on a desktop computer. While that was true ten years ago, modern mirrorless cameras behave very differently depending on the manufacturer:

Phase 1: Immediate OS containment and blocking automatic writes¶

Before you try to recover files from an internal drive or attach an external drive to a computer, you must neutralize the operating system mechanisms that silently overwrite deleted space.

1. Recovering from an Internal Windows Drive (C: Drive)¶

If you deleted an important folder from your Windows Desktop, Documents, or Downloads folder and emptied the Recycle Bin:

1. Do NOT keep using Windows on that drive: Even leaving Windows sitting idle at the Desktop allows SearchIndexer.exe, Windows Defender background scans, Chrome/Edge cache updates, Volume Shadow Copy rotation, and the Windows Pagefile (pagefile.sys) to write hundreds of megabytes per minute directly over your newly freed clusters.
2. If you cannot power off immediately (for example, on a remote workstation with no physical access), disable TRIM фавран тавассути сатри фармони администратор:
   • пахш кунед Win + X, Терминал (Админ) ё Садои Фармонро (Админ) клик кунед ва иҷро кунед:

     fsutil behavior set DisableDeleteNotify 1
     

   • Ин Windows-ро аз фиристодани ҳама гуна *минбаъд * бозмедорад TRIM огоҳиномаҳо барои ҳаҷми NTFS ва ReFS, гарчанде ки он наметавонад бекор карда шавад TRIM фармонҳое, ки сония пештар фиристода шудаанд.
3. ** Санҷед, ки оё нусхаи сояи ҳаҷм (Previous Versions) пеш аз хомӯш шудан мавҷуд аст (15 сония вақт мегирад)**:
   • Папкаи волидайне, ки файлҳои ҳазфшудаи шуморо нигоҳ медорад, бо тугмаи рости муш клик кунед, Хусусиятҳо -> Версияҳои қаблӣ-ро клик кунед.
   • Ё давидан vssadmin list shadows дар сатри фармони маъмур. Агар акси соя аз имрӯз ё дирӯз вуҷуд дошта бошад, шумо метавонед он нусхаи сояро барои хондан насб кунед (mklink /d C:\ShadowRestore \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\) ва файлҳои солими худро мустақиман ба диски берунии USB нусхабардорӣ кунед.
4. Агар нусхаи соя вуҷуд надошта бошад, онро сахт хомӯш кунед ва аз USB-и Linux Live пурбор кунед: Диски флеши USB-и Ubuntu ё SystemRescue дар компютери дигар созед, компютери зарардидаро аз он диски USB дар Ubuntu (режими Live RAM) оғоз кунед бе насб кардани диски дохилии rw ва тасвир ё истихроҷи файлҳоро аз берун аз Windows.

2. Барқароркунӣ аз диски системаи macOS (Apple Silicon M1/M2/M3/M4 & T2 Mac)¶

Компютерҳои муосири Apple бо macOS дар APFS (Apple File System) ду монеаи сахти меъмориро пешниҳод мекунанд:

1. ** APFS TRIM-и хашмгин**: macOS мефиристад TRIM фармонҳо фавран ҳангоми холӣ кардани партов дар SSD-ҳои дохилии Apple.
2. ** Hardware FileVault / Enclave Enclave Encryption**: Дар ҳама Mac-ҳо бо чипи Apple T2 ё Apple Silicon (M1, M2, M3, M4), SSD-и дохилӣ бо нобаёнӣ бо истифода аз калидҳои ба Анклави Амн алоқаманд сахтафзор рамзгузорӣ карда мешавад, ҳатто агар FileVault дар Танзимоти система "хомӯш" бошад.
   • ** Санҷиши фаврӣ 1: Суратҳои мошини вақти маҳаллӣ (tmutil)**: Ҳатто агар диски эҳтиётии Time Machine-и берунии шумо ҳангоми ҳазф ҷудо карда шуда бошад ҳам, macOS ба таври худкор дар SSD-и дохилӣ ҳарсоата APFS Snapshots Local-и пинҳоншударо эҷод мекунад, агар Time Machine танзим шуда бошад. Терминалро фавран кушоед ва иҷро кунед:

     tmutil listlocalsnapshots /
     

     Агар шумо аксҳои дар рӯйхат овардашударо бинед (масалан com.apple.TimeMachine.2026-10-31-091522.local), ҷузвдонеро, ки дар он файл зиндагӣ мекард, кушоед ва барномаи Time Machine-ро аз Барномаҳо оғоз кунед, то файлро дар сонияҳо барқарор кунед.
   • Тафтиши фаврӣ 2: Қуттиҳои партовҳои абрии синхронизатсия (iCloud Drive, OneDrive, Dropbox, Google Drive): Азбаски ҷузвдонҳои macOS Desktop ва Documents зуд-зуд бо iCloud Drive ҳамоҳанг карда мешаванд, нест кардани файл аз мизи кории Mac-и шумо онро на тавассути ҳамоҳангсозии iCloud нест мекунад, на танҳо ба таври маҳаллӣ. Дар телефони худ ё компютери дигар браузерро кушоед, ворид шавед icloud.com -> Драйв -> Ба наздикӣ нест карда шуд (кунҷи рости поён), ки дар он файлҳои ҳазфшуда барои 30 рӯз нигоҳ дошта мешаванд, ки аз ҷониби SSD-и маҳаллӣ комилан дастнорасанд TRIM.

3. Маҳдуд кардани macOS ва Windows аз ифлос кардани корти SD-и васлшуда ё диски беруна¶

Вақте ки шумо корти SD-и камера ё диски USB-ро ба компютер барои барқарор кардани файлҳо пайваст мекунед, системаи оператсионии мизбон фавран мекӯшад, ки файлҳои метамаълумоти пинҳониро ба решаи диск нависад (.DS_Store, .Spotlight-V100, .fseventsd, .Trashes дар macOS; System Volume Information ва $Recycle.Bin дар Windows). Он хурдтарин навиштаҷот дар ибтидои харитаи фазои озод ҷойгир шуда, аксар вақт сарлавҳаҳои дақиқи директорияро, ки шумо барқарор кардан мехоҳед, вайрон мекунад.

• Дар Linux (Усули бехатарии криминалистӣ): Linux ҷузвдонҳои индекси пинҳониро ба таври худкор наменависад, агар шумо насби худкорро хомӯш кунед ё дастгоҳи блокро танҳо барои хондан васл кунед (ro,noload).
• Дар Windows (Атрибути танҳо барои хондан дискро тавассути DiskPart пеш аз ворид кардани диск фаъол созед ё Registry WriteBlocker-ро истифода баред):
  • Кушода regedit.exe ҳамчун Administrator, мурур кунед HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies (созед StorageDevicePolicies калид, агар он вуҷуд надошта бошад) ва эҷод кунед DWORD (32-bit) арзиши ном WriteProtect гузоштан 1. Пас аз он корти хонандаи USB-и худро васл кунед ва Windows ҳама нигаҳдории USB-и ҷудошавандаро ҳамчун сахтафзор аз навиштан муҳофизат мекунад.
• Дар macOS (Mount тавассути Disk Arbitrator): Пеш аз васл кардани корти хонандаи SD ё диски берунии худ утилитаи кушодаи Disk Arbitrator-ро зеркашӣ ва оғоз кунед. Arbitrator Disk-ро ба Блоки васлкунӣ ё Танҳо барои хондан насб кунед, то macOS навишта наметавонад .DS_Store ё индексҳои Spotlight ба қисмати вайроншуда.

Марҳилаи 2: Эҷоди клони бахшҳои криминалистӣ (ddrescue)¶

Ҳеҷ гоҳ сканҳои барқарорсозии файлро мустақиман дар диски сахти корношоям, корти microSD-и фарсуда ё нусхаи ягонаи қисмати форматшуда иҷро накунед. Эҷоди файли тасвири хоми дуӣ (.img ё .dd) кафолат медиҳад, ки шумо тасвири яхкардашуда ва каме ба бит доред, зеро он лаҳзае, ки шумо дискро ҷудо мекунед, вуҷуд дошт.

Қадам ба қадам клонкунӣ бо GNU ddrescue (Linux / macOS) ё HDDSuperClone¶

1. Identify the exact device identifier of your source card or drive:
   • On Linux, run lsblk -o NAME,SIZE,MODEL,RO,FSTYPE,MOUNTPOINT before and after plugging in the card reader. Suppose your 64 gigabyte (59.6 gibibyte) camera SD card appears as /dev/sdc (make sure it is not mounted; if mounted, run sudo umount /dev/sdc1).
   • On macOS, run diskutil list барои ёфтани рақами диск (масалан, /dev/disk4), then unmount its volumes without ejecting the hardware: diskutil unmountDisk /dev/disk4.
2. Mount your large destination storage drive: Suppose your external 2 terabyte backup drive is mounted at /mnt/backup (or /Volumes/BackupDrive on macOS). Verify it has enough free space to hold the entire raw capacity of the source drive (a 64 gigabyte SD card produces a 64 gigabyte .img file, even if only 10 gigabytes of photos were on it).
3. Execute ddrescue with a mapfile (log file):

   sudo ddrescue -d -r3 /dev/sdc /mnt/backup/sdcard_raw_clone.img /mnt/backup/sdcard_rescue.map
   

   • -d uses direct disk access (bypassing the operating system kernel page cache for accurate sector reads; on macOS use /dev/rdisk4 instead of -d).
   • -r3 tells ddrescue to copy all healthy sectors across the entire drive on the first fast pass, skip over any slow or damaged flash blocks immediately so the card does not overheat or lock up, and then retry bad sectors up to 3 times at the end.
   • sdcard_rescue.map saves your exact progress every few seconds. If the USB reader disconnects or the power goes out, running the exact same command resumes seamlessly from where it stopped without re-reading already rescued sectors.
4. Make a working copy or mount the .img file read-only: Once sdcard_raw_clone.img finishes at 100.00% rescued, eject your physical SD card and store it in a safe drawer. You will perform 100 percent of your recovery work on sdcard_raw_clone.img.

Phase 3: Executing file recovery (Logical Metadata Reconstruction vs. Raw Carving)¶

Once you have a safe .img file (or a hardware write-blocked drive), there are two completely different technical methods to extract your deleted data. You should always attempt Method A (Logical File System Reconstruction) first before falling back to Method B (Raw Signature Carving).

Step-by-Step 1: Restoring a Deleted Partition or Corrupted Boot Sector with TestDisk¶

If your external drive or SD card suddenly asks "You need to format the disk in drive E: before you can use it" or shows up as RAW / Unallocated in Disk Management after being unplugged without safely ejecting, your files were not deleted at all. Instead, the Master Boot Record (MBR), GUID Partition Table (GPT), or Boot Sector (BPB) was corrupted.

1. Run TestDisk against your cloned image file:

   testdisk /mnt/backup/sdcard_raw_clone.img
   

2. Select Proceed -> confirm the partition table type (Intel/PC for MBR SD cards under 2 terabytes, or EFI GPT for modern large drives).
3. Select Analyse -> Quick Search.
4. TestDisk will scan for backup partition headers (such as the automatic backup NTFS boot sector stored at the very last sector of an NTFS volume, or the backup FAT32 boot sector at sector 6).
5. Highlight the discovered partition and press P (List Files). If you immediately see all your folders and files listed intact inside the terminal window:
   • Do not even bother rewriting the partition table if you only want the files. Simply press C on the folders you want and copy them directly out to your healthy destination drive with 100 percent original filenames and folder structures.

Step-by-Step 2: Logical Metadata Scan Using DMDE, R-Studio, or UFS Explorer¶

When files were deleted via Shift + Delete, emptied from the Recycle Bin, or wiped via a standard Quick Format:

1. Open your .img file inside DMDE (free edition recovers up to 4,000 files per directory action; full license is inexpensive), R-Studio, or UFS Explorer Standard Recovery.
2. Check the Existing Virtual File System Tree First:
   • On NTFS drives, each file has a 1,024-byte (1 kilobyte) record in the Master File Table ($MFT). Even when a file is deleted, its $MFT слот бо парчами ғайрифаъол боқӣ мемонад (0x00 instead of 0x01) дорои номи дақиқи файл, ID директорияи волидайн ва кластери дақиқи оғозёбӣ ва давомнокии иҷро, то он даме ки файли нав онро дубора истифода накунад $MFT ковокии. Ғайр аз он, файлҳои хурдтар аз ~700 байт (ба монанди ёддоштҳои матнии мухтасар, калидҳои крипто ё скриптҳои хурд) дар резидент пурра дар дохили файл нигоҳ дошта мешаванд. $MFT худаш сабт мекунад ва ба зудӣ хеле кам навишта мешавад.
   • Ба ** нигаред$Root** ё Deleted / Found ҷузвдони маҷозӣ дар давоми 5 сонияи аввали кушодани қисм тавлид шудааст. Агар файлҳои шумо бо ранги сурх пайдо шаванд x ё тасвири партовгоҳ ва андозаи солимро нишон диҳед, онҳоро интихоб кунед ва фавран Барқароркуниро ба диски таъиноти алоҳидаи худ клик кунед.
3. Скани пурраи ҳаҷмиро иҷро кунед, агар сарлавҳаи директория аз нав навишта шуда бошад:
   • Агар Формати зуд феҳристи решавӣ ё чанд мегабайти аввали $MFT, Скани Ҳаҷми пурра-ро иҷро кунед. Нармафзор тамоми тасвирро барои зинда мондани гиреҳҳои индекси зеркаталог скан мекунад (INDX буферҳо дар NTFS, занҷирҳои кластери зеркаталогӣ дар FAT32/exFAT ё нуқтаҳои гузариши кӯҳна дар APFS/ext4) ва метамаълумоти мантиқӣ бо кашфи имзои хоми файлро муттаҳид мекунанд.

Қадам ба қадам 3: кандакории файли хом бо PhotoRec (Вақте ки метамаълумот комилан нест карда мешавад)¶

Вақте ки Ҷадвали тақсимоти файл (FAT) ё $MFT бо формат комилан сифр шудааст, нишондиҳандаҳои феҳристи мантиқӣ нест шуда, танҳо мундариҷаи файли хом дар кластерҳои додаҳои тақсимнашуда мемонанд. PhotoRec (дар баробари TestDisk маҷмӯа шудааст, комилан ройгон, сарчашмаи кушода ва барои Windows, macOS ва Linux дастрас аст) дар кандакории зиёда аз 480 формати файл (аз ҷумла Canon) бартарӣ дорад .CR2/.CR3, Sony .ARW, Nikon .NEF, Adobe .DNG/.PSD, .JPG, .PNG, .PDF, .DOCX/.XLSX контейнерҳои почта ва .SQLITE пойгоҳи додаҳо):

1. PhotoRec-ро бар зидди тасвири диски худ оғоз кунед:

   photorec /mnt/backup/sdcard_raw_clone.img
   

2. Қисмати мақсаднокро интихоб кунед (ё Whole disk агар ҷадвали тақсимот тоза карда шуда бошад).
3. Пеш аз оғоз, ба ** гузаред[File Opt]** дар поёни экран:
   • пахш кунед s барои бекор кардани ҳамаи 480 намуди файл, агар шумо танҳо ба файлҳои мушаххас аҳамият диҳед (масалан, танҳо тафтиш кунед jpg, cr2/cr3, tif барои аксҳои хом, mov/mp4, ва zip/docx), ки барқароркуниро ба таври назаррас суръат мебахшад ва пораҳои партовҳои бардурӯғро пешгирӣ мекунад.
4. Интихоб кунед [Options] -> нигоҳ доред Keep corrupted files : No магар он ки ҷараёнҳои видеои вайроншуда барқарор карда нашавад.
5. Интихоб кунед [Search], навъи системаи файлиро интихоб кунед [Other] (барои FAT/exFAT/NTFS/HFS+) ва -ро интихоб кунед[Free] (агар шумо танҳо файлҳоро дар қисмати фаъол нест карда бошед) ё [Whole] (агар қисмат формат карда шуда бошад).
6. Дар диски калони эҳтиётии ҷудогона ҷузвдони таъинотро интихоб кунед ва -ро пахш кунед.C ба кандакорй шуруъ кардан.
7. Мураттабсозии пас аз барқарорсозӣ барои баромади PhotoRec: Зеро PhotoRec файлҳоро ҳамчун f123456.jpg дар байни даҳҳо recup_dir ҷузвдонҳо, шумо метавонед ба таври худкор ҳамаи аксҳои барқароршударо ба тоза аз нав ташкил кунед YYYY/MM-Month/ ҷузвдонҳоро бо номи файлҳои дақиқи вақти камераашон бо истифода аз абзори ройгони сатри фармон ExifTool:

   exiftool "-Directory<DateTimeOriginal" -d "%Y/%Y-%m-%d" -r /mnt/backup/photorec_output/
   

Барқарорсозии махсус: камераи пора-пора видеоҳои MP4/MOV (GoPro, DJI Drones, Sony, Canon)¶

Яке аз ноумедиҳои зуд-зуд пас аз кор кардани PhotoRec ё нармафзори барқарорсозии файл дар корти камераи форматшуда ошкор кардани он аст, ки 100 фоизи барқароршуда .JPG ва .RAW аксҳо комилан кушода мешаванд, аммо ҳар яки онҳо барқарор карда шуданд .MP4 ё .MOV файли видео бозӣ карданро рад мекунад (давомнокии 0:00 ё экрани сиёҳ).

Чаро нармафзори барқарорсозии стандартӣ видеоҳои муосири камераро мешиканад¶

1. Сабти ҷараёнҳои байниҳамдигарӣ: Камераҳои муосири экшн (силсилаи GoPro Hero, DJI Air/Mavic/Mini drones, Insta360) ва камераҳои бе оинаи синамо як адад наменависанд. .MP4 аз аввал то ба охир пай дар пай файл кунед. Ҳангоми сабти видеои 4K ё 5.3K, камера ҳамзамон як қарори баланд менависад .MP4 ҷараён, як пешнамоиш бо ҳалли паст .LRV ҷараён, буфери аудио ва метамаълумоти телеметрӣ ба кластерҳои алтернативӣ дар корти exFAT/FAT32 (масалан: 4 мегабайт видеои баландсифат ва пас аз 512 килобайт .LRV пешнамоиш, пас аз он 4 мегабайт видеои баландсифат).
2. ** Бедарак moov Атом дар сабтҳои нотамом**: Агар бесарнишини шумо ба об бархӯрд, батареяи камераи шумо дар давоми сабт хомӯш шавад ё корти SD пеш аз пахш кардани тугмаи Қатъи Сабт ҷудо шавад, камера ҳеҷ гоҳ moov atom (ҷадвали индекси асосӣ дар охири файли MP4/MOV навишта шудааст, ки ба плеери медиа хабар медиҳад, ки ҳар як чаҳорчӯбаи видео ва порчаи аудио дар куҷо ҷойгир аст).

Чӣ гуна видеоҳои камераи бозинашаванда ё пора-пораро барқарор кардан мумкин аст¶

1. ** Ҳолати A: Видеои нотамом пас аз гум шудани батарея ё садама (Файл дар корт мавҷуд аст, андозаи бисёр ГБ-ро нишон медиҳад, бозӣ намекунад)**:
   • Кластерҳо дар системаи файлӣ солим мебошанд, танҳо moov сарлавҳаи индекс мавҷуд нест.
   • Воситаи ройгон ва кушодаасосро истифода баред untrunc (махсусан anthwlock/untrunc чангак) ё recover_mp4 (slydiman). Таъмин кунед untrunc бо як истинод солим, playable .MP4 дар он ** ҳамон камера бо ҳамон қарор ва танзимоти кадрӣ**, дар баробари шикастаатон сабт шудааст .MP4:

     untrunc reference_working_video.MP4 corrupted_unfinalized_video.MP4
     

   • untrunc параметрҳои кодекро мехонад (avcC/hvcC ва тарҳбандии треки аудио) аз видеои истинодҳои корӣ, воҳидҳои хоми H.264/H.265/HEVC NAL-ро дар файли вайроншудаи шумо скан мекунад ва навори навро синтез мекунад. moov атом дар сонияҳо.
2. ** Ҳолати B: Корти SD-и форматшуда бо видеои ҷудошуда / порашуда (GoPro, DJI, Sony, Canon)**:
   • Азбаски харитаи кластери FAT/exFAT ҳангоми форматкунӣ тоза карда шуд, кандакори стандартӣ ftyp/mdat сарлавҳаи видеои 4K-и шумо ва сипас кӯр-кӯрона нусхабардорӣ мекунад .LRV кластерҳои пешнамоиш ва кластерҳои эскизиро рост ба мобайни файли видеоии худ гузоред, ки ҳар як сонияи наворро вайрон мекунад.
   • Ба ҷои кандакорҳои стандартӣ, скан кунед sdcard_raw_clone.img бо истифода аз таҷдиди видеои аз фрагментатсия огоҳшуда, ки каденсияҳои тақсимоти кластерии камераро эътироф мекунад, ба монанди SanDisk RescuePRO Deluxe (ки алгоритмҳои махсуси васлкунии видеои ҷудошудаи GoPro/drone-ро дар бар мегирад), Klennet Carver, ё **Disk+Drill/Fragment-и махсусро дар бар мегирад **Drill/JD барқарорсозии имзои видео).

Несткунии аксҳои смартфон: воқеиятҳои рамзгузории сахтафзори iOS (iPhone) ва Android¶

Як тасаввуроти нодурусти маъмул ва хатарнок ин аст, ки шумо метавонед смартфони муосири iPhone ё Android-ро ба ноутбук тавассути USB пайваст кунед ва нармафзори анъанавии кандакории дискро (ба монанди Recuva ё PhotoRec) дар хотираи дохилии телефон иҷро кунед.

Чаро кандакории бахши анъанавӣ телефонҳои муосирро хонда наметавонад¶

Ҳар як iPhone пас аз iPhone 3GS (ва ҳама дастгоҳҳои ҳозираи iOS) Ҳифзи маълумотро (рамзгузории файл дар асоси файл)-ро истифода мебарад, ки аз ҷониби як муҳаррики сахтафзори махсуси криптографии AES байни хотираи флешдор ва хотираи асосии система кор мекунад. Ба ҳамин монанд, ҳар як дастгоҳи Android аз Android 7.0+ фиристодашуда (ва ҳатмӣ аз Android 10) Рамзгузории ба файл асосёфта (FBE)-ро истифода мебарад, ки бо чипи сахтафзори Keystore/Titan M/Knox дастгирӣ карда мешавад.

On both platforms, every single individual photo and file on the internal storage is encrypted with its own unique per-file cryptographic key. When a file is permanently purged from the phone's file system, the phone does not even need to erase the multi-megabyte photo blocks; it immediately destroys the 256-bit per-file encryption key in the metadata table. Without that key, the raw NAND blocks contain cryptographically unbreakable random noise. Even top-tier government forensic labs cannot "carve" permanently deleted photos from the internal flash of a modern iPhone or Android once the per-file key is wiped.

The Actual Recovery Paths for Deleted Smartphone Photos¶

Because hardware encryption blocks raw carving, recovering deleted photos from an iPhone or Android relies on recovering copies before retention timers expire or extracting cached thumbnail databases:

1. Check the On-Device "Recently Deleted" Album Immediately (30-Day Window):
   • iOS (iPhone / iPad): Open Photos -> scroll down to Utilities -> tap Recently Deleted (requires Face ID / Touch ID / Passcode). Photos stay here for 30 days before permanent key destruction.
   • Android (Google Photos / Samsung Gallery): Open Google Photos -> Library / Collections -> Trash / Bin (retained for 60 days if backed up, 30 days if device-only). Also check Samsung Gallery -> Menu (three lines) -> Trash (retained for 30 days), and open the Files by Google or My Files app -> Trash, which maintains a separate 30-day trash folder.
2. If You Deleted Photos from "Recently Deleted" on iPhone, Call Apple Support for an Emergency iCloud Server-Side Restore:
   • Many users do not realize that even after you manually click "Delete from All Devices" / "Empty Recently Deleted" in iCloud Photos, Apple's backend servers retain a soft-deleted server recovery buffer for a brief window (typically up to 7 to 14 days after permanent deletion).
   • Contact Apple Support immediately by phone or chat, ask to speak with a Senior Advisor, and ask them to trigger an iCloud Photo Library Server-Side Recovery on your Apple Account. They can frequently flip a server switch that dumps recently purged iCloud Photos right back into your album within 15 minutes.
3. Restore from an Older Unsynced Device or Encrypted Local Backup:
   • Airplane Mode Trick on Secondary iPad / Mac: If your iPhone synced a deletion to iCloud, grab your iPad or MacBook before it connects to Wi-Fi (turn off your home Wi-Fi router unplugging the power cord first if the iPad is asleep on your desk). Power on the iPad in total radio isolation, copy the still-present photos via USB cable or AirDrop to another device before the iPad receives the iCloud deletion push command.
   • Check iCloud Backup vs. iCloud Photos: If you had iCloud Photos turned OFF (Settings -> [Your Name] -> iCloud -> Photos -> Off), your Camera Roll is included inside your nightly iCloud Device Backup. You can wipe an old spare iPhone (or temporarily back up and reset your current iPhone) and restore the nightly iCloud Backup from before the moment you deleted the photo.
   • Check Local Finder / iTunes Backups on Your PC or Mac: Check ~/Library/Application Support/MobileSync/Backup/ on macOS or %APPDATA%\Apple Computer\MobileSync\Backup\ on Windows. You can browse and extract photos from old local backups without overwriting your phone using iMazing or iBackup Viewer.
4. Check Messaging App Local Caches (WhatsApp, iMessage, Telegram, Signal):
   • Did you ever text the deleted photo or video to a spouse, friend, or family group chat? Messaging apps store independent copies of media inside their own application sandboxes (Media/WhatsApp Images/Sent on Android, or inside chat attachments in iMessage). Even if you delete a photo from your main Camera Roll and empty the Trash, the copy inside your WhatsApp Sent folder or iMessage thread history remains completely untouched.

Cloud drive and enterprise accidental deletion recovery (Google Drive, OneDrive, Dropbox)¶

When an entire shared folder disappears or is overwritten on a cloud drive (or when ransomware or a syncing glitch deletes local files and syncs the deletion to the cloud), local disk recovery is often unnecessary because enterprise and consumer cloud platforms maintain multi-tier version histories:

1. Microsoft OneDrive & SharePoint Online:
   • First-Stage Recycle Bin (onedrive.live.com): Retains deleted files for 30 days on personal accounts and 93 days on Work/School accounts.
   • Second-Stage Site Collection Recycle Bin (Work/School): Even if an employee or hacker empties the main OneDrive Recycle Bin, click the link at the bottom of the Recycle Bin page labeled "Second-stage recycle bin", where purged files remain recoverable for the remainder of the 93-day window.
   • Restore Your OneDrive (Point-in-Time Rollback): Microsoft 365 subscribers can click Settings (gear icon) -> Options -> Restore your OneDrive, which uses a visual histogram slider to roll every single file, rename, and deletion across the entire cloud drive back to any exact minute within the last 30 days.
2. Google Drive & Google Workspace:
   • Google Drive Trash (drive.google.com/drive/trash): Retains deleted files for 30 days.
   • Барқарорсозии пас аз партови маъмури Google Workspace (Равзанаи 25-рӯзаи файз): Ҳатто пас аз он ки корбар "То абад нест кардан"-ро клик кунад ва партови Google Drive-и худро холӣ кунад, маъмури Google Workspace (ё корбари инфиродӣ, ки бо Дастгирии Google Drive дар ҳисобҳои шахсии Google One тамос мегирад) метавонад Console Admin Google-ро кушояд (admin.google.com) -> Директория -> Истифодабарандагон -> [Истифодабарандаро интихоб кунед] -> Имконоти бештар -> Барқарорсозии маълумот ва файлҳои ба таври доимӣ тозашудаи Google Drive ва паёмҳои Gmailро дар тӯли то 25 рӯзи иловагӣ пас аз холӣ кардани партов барқарор кунед.
3. Dropbox:
   • Файлҳои ҳазфшуда (dropbox.com/deleted_files): Файлҳо ва ҷузвдонҳои ҳазфшударо барои 30 рӯз дар нақшаҳои Basic/Plus/Оила ва 180 рӯз то 1 сол дар нақшаҳои касбӣ/бизнес нигоҳ медорад.
   • Dropbox Rewind (dropbox.com/rewind): Allows rolling back an entire folder or the entire account to undo mass deletions, accidental drags-and-drops, or encryption events.

Саволҳои зуд-зуд додашаванда¶

Сарчашмаҳо тафтиш карда шуданд¶

• Институти Миллии Стандартҳо ва Технология (NIST, Иёлоти Муттаҳида): Нашри махсуси 800-88 Нусхаи 1, Дастур оид ба санитаризатсияи ВАО (ATA TRIM, NVMe Deallocate ва рафтори NAND Flash Translation Layer) ва Санҷиши абзорҳои криминалистии компютерӣ (CFTT) Мушаххасоти барномаи Диски тасвирӣ (csrc.nist.gov).
• Cybersecurity and Infrastructure Security Agency (CISA, United States): Data Backup, Forensic Preservation, and Incident Handling Guidelines (cisa.gov).
• GNU Project / Antonio Diaz Diaz (International): Official GNU ddrescue Manual: Data Recovery Tool and Block Device Mapfile Algorithms (gnu.org/software/ddrescue).
• CGSecurity / Christophe Grenier (International): * Ҳуҷҷатҳои расмии TestDisk & PhotoRec: Барқарорсозии қисмҳо ва имзоҳои кандакории файл* (cgsecurity.org).
• Apple Platform Security (Иёлоти Муттаҳида): * FileVault, Синфҳои ҳифзи додаҳо, Калидҳои рамзгузории ҳар як файл ва меъмории APFS Trim дар системаҳои Apple Silicon ва T2* (support.apple.com/guide/security).
• Лоиҳаи кушодаасоси Android (AOSP, International): Рамзгузорӣ дар асоси файл (FBE) ва меъмории рамзгузории метамаълумот (source.android.com/docs/security/features/encryption).
• Ассотсиатсияи SD (Байналмилалӣ): Мушаххасоти SD Қисми 1: Мушаххасоти соддакардашудаи қабати физикӣ (Фармонҳои тозакунии CMD32, CMD33, CMD38 ва Гузаришҳои механикии навиштан аз муҳофизат) (sdcard.org).

Дастурҳои алоқаманд¶

• Hard drive failure and data recovery
• Computer backups: 3-2-1 strategy and disaster recovery
• Ransomware and malware
• Телефони шикаста ё аз об зарардида
• Нокомии пурборкунии системаи Linux ва таъмири GRUB
• Экрани кабуди Windows (BSOD) ва таъмири боркунӣ