![\"A](\"\/help\/wp-content\/uploads\/2025\/06\/a-few-thoughts-on-digital-archeology.jpg\")
<\/p>\n<\/p>\n
\u201cThere are two ways that you can delete data from magnetic media, using software or by physically destroying the media.\u201d<\/b> – Peter Gutmann, \u201cSecure Deletion of Data from Magnetic and Solid-State Memory<\/a>\u201d, 1996.<\/p><\/blockquote>\n
“Perhaps it will be nano-devices that slowly eat away the magnetic surface taking measurements of flux density as they go, and perhaps this will yield amazing results. Perhaps not.”<\/b> – Fred Cohen, “The Science of Digital Forensics: Recovery of Data from Overwritten Areas of Magnetic Media<\/a>“, 2012<\/p><\/blockquote>\n
\u201cThe truth is boring and nuanced.\u201d<\/b> – Morgan McSweeny (aka Dr. Noc)<\/a>, 2025<\/p><\/blockquote>\n
Some say that recovering deleted data is easier than ever in 2025, and in order to truly destroy that data one needs to go all the way to secure multi-pass erasure and specialized low-level formatting in order to rest assured their digital data is properly eradicated and unrecoverable. We at CleverFiles have been in the data restoration industry for the last 15 years, and here\u2019s what we think on this matter.<\/p>\n
In most cases, OS developers, ATA standards architects, storage firmware engineers, and controller designers all assume stable and predictable behavior from their drives, drivers, and firmware stacks – but real-world conditions have a habit of breaking those assumptions.<\/p>\n
The simple answer to the most burning question of our users about the recoverability of their data, usually, is: It depends<\/b>.<\/p>\n
Truly so, and here\u2019s what it depends on\u2026<\/p>\n
<\/span>#1 The type of media the data was stored on<\/b><\/span><\/h2>\n
💽 Hard Disk Drives (HDD)<\/b>: the hardware technology at the heart of this type of storage devices would not affect the recoverability of one\u2019s data. Disk controllers do not implement additional timely erasure mechanisms on the firmware level.<\/p>\n
🏿 Solid State Drives (SSD)<\/b>: in short, full data erasure is almost imminent due to the TRIM command<\/a> which is issued by the system immediately after a delete or format operation. Additionally, TRIM can be triggered when a certain threshold of space is freed or modified. It may also run on a scheduled basis. The exact behavior for any given SSD, however, is a black box – only the vendor\u2019s firmware QA team truly knows how it\u2019s implemented under the hood.<\/p>\n
Here\u2019s how TRIM works in general terms:<\/b><\/p>\n
\n
- When files are deleted from an SSD, the OS identifies the physical blocks they occupied.<\/li>\n
- It sends a list of these now-unused blocks to the SSD controller via the TRIM command.<\/li>\n
- TRIM doesn\u2019t erase the data immediately – it simply gives the SSD permission to reclaim those blocks at a later time.<\/li>\n
- The SSD controller marks the corresponding NAND pages as \u201cinvalid.\u201d<\/li>\n
- During scheduled garbage collection, the controller may physically erase these invalid pages and consolidate valid ones to optimize performance and ensure balanced wear leveling.<\/li>\n<\/ul>\n
However, that\u2019s the idealized textbook version – the reality is (usually much) messier. Hundreds of variables can throw a wrench into the process: firmware quirks, controller behavior, wear-leveling strategies, OS implementation differences, background tasks, power cycles – you name it.<\/p>\n
\n
- TRIM may work unreliably when an SSD is used in a USB enclosure. If you power off a SATA-connected drive right after deletion and reconnect it via USB fast enough, there\u2019s a decent chance the data hasn\u2019t been physically wiped yet. This trick can also work with SMR drives – if you immediately start backing up and the drive is under heavy I\/O load, there\u2019s a variable time frame where TRIM or internal cleanup is deferred, regardless of whether it\u2019s via USB or SATA.<\/li>\n
- The more data is being deleted and the heavier the I\/O load on the drive, the longer the TRIM execution can be postponed. The SSD controller may deliberately delay<\/a> handling TRIM commands if it\u2019s busy, prioritizing real-time read\/write operations over background maintenance tasks like block cleanup. The same may be true for WinAPI glitches and accidental macOS low-level delays that may result in delayed TRIM execution on the drive\u2019s level.<\/li>\n
- Another scenario: Windows misidentifies the SSD as a generic disk instead of a solid-state drive. As a result, it may skip issuing TRIM commands during operations like formatting, since it doesn\u2019t recognize the drive as TRIM-capable in the first place.<\/li>\n
- Or more: overheating, bad blocks<\/a>, buggy firmware, lack of TRIM (as well as S.M.A.R.T.<\/a>, SECURITY ERASE UNIT, ENHANCED SECURITY ERASE) support in USB-to-SATA bridge chips, incompatible file systems, TRIM disabled by default on OEM-installed Windows systems.<\/li>\n<\/ul>\n
All of these and many other factors can interfere with proper TRIM execution. Additionally, if the SSD enters service (factory\/test) mode, it halts all data modification operations entirely. Hence: It depends<\/a>.<\/p>\n
🛢 HDD + Shingled Magnetic Recording (SMR)<\/b>: While TRIM is commonly associated with SSDs, it’s also supported by some SMR HDDs.<\/p>\n
🎟️ Flash Memory<\/b>: This includes SD, SDHC, SDXC, MicroSD, CF (CompactFlash), MMC – The MultiMediaCard and other memory cards. In this case we should be looking at SD ERASE (CMD38) command, which provides similar functionality to the ATA TRIM command<\/a>, although it requires that erased blocks be overwritten with either zeroes or ones. A DISCARD sub-operation is further defined in eMMC 4.5, and optionally in SDHC and SDXC cards, that more closely matches ATA TRIM in that the contents of discarded blocks can be considered indeterminate (i.e., “don’t care”).<\/p>\n
Some camera models (most notably and repeatedly confirmed with SONY A7 series) issue an SD_ERASE command during quick format of memory cards. As a result, the card\u2019s logical translator gets instantly wiped, and any recovery scan will just return zeros. However, at the physical NAND level, the data often remains intact and can be recovered – provided the card doesn\u2019t use encryption or advanced error correction layers like LDPC.<\/p>\n
Others, when deleting data from flash storage, perform a software-level zeroing – immediately overwriting the deleted files with zeros. This makes traditional recovery methods ineffective, as the data is actively erased rather than just marked as deleted.<\/p>\n
Finally, file fragmentation is often a major factor in relation to memory cards. It significantly complicates the outcomes of data recovery algorithms. Reconstructing files from non-contiguous NAND pages or disk sectors requires advanced heuristics, especially when file system metadata is missing or corrupted. The more fragmented the storage, the harder it is to reliably piece files back together. Kudos to Disk Drill 6 with its Advanced Camera Recovery (ACR)<\/a> mode.<\/p>\n
🗂 Hybrid storage devices, SSD+HDD (SHDD, Fusion Drives, etc.)<\/b>: During formatting, the system typically wipes data on an HDD by overwriting file system structures. But with SSDs, it\u2019s a different story: some portions of the data may remain recoverable in a forensic lab. This is because SSDs rely on flash translation layers (FTLs), wear-leveling, and (sometimes) deferred TRIM<\/a>, which can leave physical NAND pages intact even after a logical format.<\/p>\n
🗃️ RAID arrays<\/b>: even though, this type of storage is not anything technologically separate from the ones mentioned above, it is worth noting that the exact data deletion mechanics may be quite different on RAID arrays<\/a> depending on their type (RAID1, 2, 5, so on), on top of the fact whether a specific array used HDD, or SSD, or a mix of those technologies. If the data was only deleted (not overwritten), it may be recovered with a Quick Scan, Disk Drill includes a specialized RAID recovery (SSH) module<\/a> that can remotely connect to Linux systems and NAS devices.<\/p>\n
<\/span>#2 How much time has passed after the deletion<\/b><\/span><\/h2>\n
Again, depending on the type of storage device we are talking about here the time might be more or less important. Obviously, the faster you act after data loss, the higher the chances to recover deleted data.<\/p>\n
The longer you use the device after deletion, the higher the chance that new data has overwritten the deleted files, making recovery difficult or impossible. The same is true about fragmentation, which comes into play even more with time. Time is a major risk factor, but its impact is magnified by other technical and behavioral variables discussed in this article.<\/div>\n<\/span>#3 Encryption<\/b><\/span><\/h2>\n
Encryption dramatically affects data recoverability: if the deleted files or storage medium were encrypted and you don\u2019t have the decryption key or password, recovery is virtually impossible. Even if the raw data is recovered, the chances are high it will be unreadable.<\/p>\n
Here are some types of encryption that may get in the way of a successful data restoration session:<\/p>\n
\n
- OS-level encryption<\/b>: Implemented by the operating system itself (e.g., BitLocker, FileVault). It encrypts data transparently as it\u2019s written to disk and decrypts it on access, often tied to user credentials.<\/li>\n
- Software-based encryption<\/b>: Performed by third-party tools (like VeraCrypt or AxCrypt). Offers flexible encryption schemes, virtual encrypted volumes, or file-level protection, independent of the OS.<\/li>\n
- Hardware-based encryption<\/b>: Handled by dedicated chips – either built into the SSD, motherboard (e.g., TPM or Intel PTT), or RAID controller. It\u2019s fast and transparent to the OS but often harder to audit or bypass, especially if proprietary.<\/li>\n
- Self-Encrypting Drives (SEDs)<\/b> are storage devices (usually SSDs or HDDs) that automatically and continuously encrypt all data on the drive using built-in hardware encryption – without user intervention or system slowdown.\n
\n
- Crypto Secure Erase (CSE)<\/b> is a fast and effective data destruction method used on Self-Encrypting Drives (SEDs) and other encrypted storage devices. Instead of overwriting data, CSE instantly renders all stored data unreadable by deleting or replacing the encryption key.<\/li>\n
- PSID Revert<\/b> is a special command used to reset a Self-Encrypting Drive (SED) to its factory state by wiping all data and removing access controls – even if the drive is locked and the password is unknown.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
<\/span>#4 File system the partition was formatted into<\/b><\/span><\/h2>\n
Some file systems have better recovery success rates than others due to different ways they handle deleted files. E.g., some file systems do not support TRIM command<\/a>. Here are some basic examples:<\/p>\n
\n
- NTFS (Windows)<\/b>: more favorable to DIY file recovery.<\/li>\n
- FAT\/FAT32\/exFAT<\/b>: non-journaled, hard to recover original file structures; do not support TRIM.<\/li>\n
- HFS+\/APFS (macOS), ReFS\/BTRFS, ext3\/ext4 (Linux)<\/b>: journaled, higher chances to recover original file structures and properties.<\/li>\n<\/ul>\n
<\/span>#5 Physical vs logical damage\/recovery<\/b><\/span><\/h2>\n
Bad blocks can either help or hinder your data recovery efforts. The same is true about unstable disks. When data is deleted or the drive is formatted, the disk controller may skip or fail overwriting the contents of bad blocks. These sectors are usually (but not always) marked as unusable and excluded from normal I\/O operations, as a result their data may remain physically intact. With some forensic hardware<\/a>, it may be possible to extract residual data from these bad blocks.<\/p>\n
Firmware bugs and drive degradation can both lead to unpredictable behavior during data deletion or formatting. When you format a drive, it may not actually be zeroed out. In some cases, formatting only resets file system structures, leaving the underlying data untouched. This can be confirmed by scanning the drive with a data recovery software, files often remain recoverable until they\u2019re actively overwritten or erased at the physical level.<\/p>\n
<\/span>#6 File size and type<\/b><\/span><\/h2>\n
It may sound obvious, but smaller files are easier to recover, fragmentation is less frequent, as they are usually stored in one chunk.<\/p>\n
The file types you are after during a recovery process may directly affect the outcome. Some files store more information about their internal structure, and may contain self-healing data that helps in recovery. Signature-based recovery methods, like Disk Drill\u2019s Deep Scan, are based on the vendor\u2019s internal knowledgebase of known file signatures which helps piece them together when the partition or file system data, as well as MFT information is no longer available.<\/p>\n
<\/span>#7 Data deletion method<\/b><\/span><\/h2>\n
The most obvious factor in measuring the success of a data recovery attempt is the way the data was lost.<\/p>\n
Even a so-called \u201cfull\u201d format may not truly wipe all data. On some versions of Windows and macOS, default full format settings often just rebuild the file system structures, perform a surface scan, and mark bad blocks without actually zeroing out every data block unless explicitly instructed to do so via advanced options or command-line flags.<\/p>\n
When files are deleted from NAS or cloud-connected storage, recovery might still be possible, especially if you have physical or SSH-level access to the underlying disks. Logical deletion doesn\u2019t always imply physical erasure, so direct access opens a recovery window before the data is overwritten or TRIMmed<\/a>.<\/p>\n
<\/span>#8 Effectiveness of recovery software algorithms<\/b><\/span><\/h2>\n
This one seems pretty obvious. When choosing a reliable DIY data recovery software, consider its metadata analysis features, file carving (or deep scan) capabilities, as well as methods of intelligent data reconstruction, like Advanced Camera Recovery<\/a>.<\/p>\n
<\/span>#9 Specialized hardware<\/b><\/span><\/h2>\n