Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.
Sign up to join this community
What steps can I take to try to recover lost or inaccessible data from any storage device?
Answers:
This applies to any computer storage device, e.g. internal/external hard drives, USB sticks, flash memory.
The most important thing is to STOP using it until you have a plan. Any type of I/O can ruin your chances of a recovery. So no formatting, no chkdsk and no 3rd-party in-place repair tools!
Hard disk failed, no backup - how to proceed with data recovery?
If you have a mechanical failure (e.g. random crashes, just stops working one day, weird "screeching"/"beeping" type noises), EVERY time you plug it in and turn on, you are making it much worse. If it is very important data , I would recommend taking it to a lab / professional data recovery service: Many labs offer free diagnostics.
However, if you want to do it yourself, you can summarize mechanical failure into two categories:
First, Media/inside problems. This is the worst thing that can happen to a physical hard drive. If it is this, it really depends how bad.
If you have decided you want to do this yourself, first step is to clone or image the drive. Some tools allow for cloning/imaging from within Windows.
An example being (not free) is R-Studio. It allows you to create an image from the drive and performs many passes*, then perform the recovery from the image.
* The idea of multiple passes is to first read data that is easy to read while skipping over bad areas. We want to skip bad areas as reading those will put stress on the drive. Once we have all easy to read data we can concentrate on bad areas. Even if the drive completely fails at this point, we have the easy to read data (often the bulk). To recover bad areas we can then do even an additional pass in which we can be more aggressive, re-read sectors multiple times etc..
An even better idea can be to use tools like ddrescue or HDDSuperClone as they run on the Linux platform which is considered safer than Windows. Windows is more persistent where it concerns trying access unstable drives which results in more stress put on the drive.
If it is a controller board problem then the most common symptom is that a drive will not spin up (use ears to determine this).
We can replace the board with an identical PCB, however on modern drives this involves 'transplanting' the 'ROM'. Some specialized websites allow you to send in original PCB and swap the ROM for you.
If drive does not spin it's worth checking out the 'TVS' which acts as a power-surge protection. This is DIY-able, if TVS failed we can remove it and run the drive without it. The drive now runs without protection so it should be imaged/cloned ASAP and then no longer be used. For more information: http://www.users.on.net/~fzabkar/HDD/TVS_diode_FAQ.html
For flash drives, again, if the data is important, go to a lab. If you want to do it yourself, the same general strategy applies: clone/image the device if possible. As a rule of thumb, if the drive is detected in Disk management with correct capacity you can potentially recover the data yourself.
If correctly detected:
If the flash drive is detected but capacity is incorrectly displayed then controller works but it is in 'safe mode'. The most common causes for that being corrupt firmware or the inability to communicate with the NAND chip(s).
If the flash drive is not detected at all then the issue is of physical nature or a controller issue.
The latter two issues I do not consider 'DIY-able'.
Pray, it will help as it calms you down. :-)
When recovering files from an external drive it's important to have the shortest connection possible.
This means that you want to get rid of any extra USB cables, USB hubs or equipment you don't need.
If you are recovering from an external hard drive, try to get it out and connect it using a SATA cable...
If you are recovering from an USB stick, try to connect it to the back of your computer, try different ports.
Most tools used in this post are all available on the Ultimate Boot CD.
Download the Ultimate Boot CD at the bottom of this page: Click on the 
icon next to a mirror.
Optionally, to ensure quality, run a checksum with this program against the checksum listed here.
Burn the ISO to a CD using ImgBurn on Windows, LiquidCD on Mac OSX or Brasero on Linux.
Optionally, to ensure quality, make sure it verifies the CD.
As we'll try to recover the file system and/or recover the data we are going to tamper with the disk, for this reason you might want to take a preliminary back-up to ensure that if things go wrong you still have a back-up available. If you suspect disk failure you might even want to consider to exercise the back-up instead so you can still send your hard drive to forensics companies if you really need the data...
Start the Ultimate Boot CD.
Go to HDD --> Cloning Tools --> EASEUS Disk Copy.
Do a disk copy to another device that has enough space free.
This will copy the data exactly at a sector-by-sector level.
Before we tamper with the drive we want to be sure we aren't making its state worse, so let's first check the state:
Start the Ultimate Boot CD.
Go to HDD --> Device Management Tools --> SMARTUDM.
Check if any of the S.M.A.R.T. attributes has a ***** that is in yellow or red, this denotes a bad state.
If the state isn't fine, try to recover in case of mechanical issues.
If the state is fine, then we'll do an error scan to be aware and get rid of issues:
Start the Ultimate Boot CD.
Go to HDD --> Diagnostic Tools --> ViVARD.
Let it perform an error scan, note how much errors are found and how many remaps are done.
Covered by How do I identify the file system used on a partition?.
Prior to doing the actual recovery, you might sometimes have the need to repair the partition(s) and file system(s) first. This is where TestDisk comes into play, I would recommend to take a look at what it does.
This is how to get to it:
Start the Ultimate Boot CD.
Go to HDD --> Data Recovery Tools --> TestDisk.
Read the documentation at the bottom of this page and try to repair your data.
Now that the preliminary stuff has been done, this is how you can start recovering:
Start the Ultimate Boot CD.
Go to HDD --> Data Recovery Tools --> PhotoRec.
Read the documentation at the bottom of this page (example: step by step) and recover your data.
gddrescue on linux to make an image of the drive first. The EaseUs Disk Copy webpage does not list it as freeware anymore (though Ultimate Boot CD reports having a freeware version) but wants $19.90 or $79, or a "Free Trial" link that immediately downloads a 50MB "dc_demo.exe" file
TestDisk is a free open source partition scanner and data recovery tool. It is very useful in recovering lost partitions. PhotoRec is another free commonly used data recovery tool. TestDisk and PhotoRec in addition to being included in the Ultimate Boot CD, as Tom Wijsman mentioned in his answer, are also included in the software repositories of many Linux distributions and on the System Rescue CD. System Rescue CD is similar to Ultimate Boot CD, but it is more lightweight, which is an advantage because it is normally run from a CD or a USB flash drive where performance is important.
TestDisk is a lot more efficient than PhotoRec. The problem with Testdisk is that it doesn't always recover all deleted files. If you accidentally reformat a partition, TestDisk can recover thousands of files without missing a single file, but if you deleted a file by sending it to the Trash and then emptying the Trash, TestDisk can't always recover it.
So use TestDisk first, and if you recovered all of the deleted files with TestDisk, then you're done. If you recovered most of the deleted files with TestDisk, you can decide whether you're done or not. If you're not done after running TestDisk, you can try recovering the deleted files using PhotoRec.
PhotoRec can't recover deleted files that have been completely overwritten (for example, with the dd program). In some cases, the filename is stored in the file itself. PhotoRec tries to recover the filename in this case, but most of the time PhotoRec can't recover the filenames.
It is preferable to boot from a Linux live DVD/USB before following these steps, in order to avoid using the operating system in which the deleted file is located.
Install TestDisk if it is not already installed in your OS. In Linux distributions, installing TestDisk will also install PhotoRec along with it.
Open a terminal and launch PhotoRec (launch from a terminal in a live CD/USB or launch as root).
Select hard disk.
Select partition type.
If your hard disk has Linux partitions, then select [Intel].
Select filetype option.
Move to [File Opt] and press Enter. Here you can disable all file types by pressing s. Use space to toggle the check button. Select filetype(s) to recover.
Select options.
PhotoRec also has a list of different options. Under normal circumstances you don't need to modify them.
Select partition.
Move the selector to the partition from which you have removed the file. Then press Enter on [Search].
Select filesystem type.
If you are using Linux, it's going to be ext2/ext3/ext4, so the default selection is ext2/ext3. Otherwise if you are recovering files from a partition formatted as FAT or NTFS select Other.
Select space for analysis.
Select Free if you didn't write to that partition after removing the particular file, otherwise select Whole.
Select a directory to recover files.
Now select the path where the recovered files will be stored. Then press Y.
PhotoRec will show how many files it has recovered.
Source: revised from How To Recover Deleted Files in Linux Using PhotoRec
This answer addresses situations where a drive and/or file system were partially overwritten. Reasons could be:
The tool used in some examples is purely to demonstrate certain points, and is not an endorsement for this particular software.
Assumption is that many file system organize meta file system structures towards the start of a volume. This is particularly true for Microsoft file system like NTFS and the various flavors of FAT.
If any specific file recovery software can partially reconstruct the file system depends on the tool's intelligence with regards to working with partial file systems. It may come as a surprise, but many file recovery tools are not particularly good at this and will quickly fall back to raw or file signature based recovery. In this case filenames, folder structure will not be recovered and also non contiguous files will be corrupt. Signature based scans are also prone to 'false positives'. For example, tool claims to have detected a JPEG file while in reality it did not.
No matter the tool you settle for, you will need to configure it for a full scan. If for example file system was (partially) formatted with a different file system than the original, a full scan may be needed to detect the previous file system. If the tool permits configure it to scan for the previous file system. So, assume a exFAT volume was accidentally (partially) formatted with NTFS file system, set the tool to scan for ex(FAT) file system or vice versa depending on your exact scenario.
Assuming approximately 1 TB FAT32 partition, start of volume overwritten, biggest determining factor is whether FATs (file allocation tables) ,or at least one copy survived. No one can tell this in advance as multiple variables are at play; how much was overwritten and size of FATs.
IF FAT survived file system based recovery is possible. This means we can reconstruct (virtually) a folder structure, recover file names, and recover fragmented files.
Without the FAT we can (partially) reconstruct folder structure and filenames but we'd have to assume all files are contiguous. So result of recovery is dictated by amount of data that was overwritten:
Ideally when dealing with data-loss scenarios you clone or image the patient drive first. So for that you'd need a destination drive with sufficient capacity.
I suggest then you scan the clone/disk image (or patient drive if you decide not to clone) using a tool like DMDE. After scan select most promising file system.
Then click 'All found / Virtual file system > Default reconstruction > Parameters to determine state of file allocation tables.
Select 2nd FAT if 1st is partially damaged.
DMDE demo allows you to test recovery by actually saving some files. You can also preview for example JPEG files. Check some larger JPEGs and see if the look okay. If not the tool may have come up with incorrect file system parameters, start of file system and clustersize being most important:
As directory entries point to start cluster, file allocation table refers to cluster, two factors that need to be 'guessed' correctly is offset from which we start counting clusters + sectors per cluster.
Tools > Reopen Volume Parameters allows you to modify these parameters but modifying these requires understanding of FAT32 file system internals (and a bit of luck?).
Assuming NTFS a similar story applies, this time however it's the MFT that is important: How much of MFT did survive?
MFT usually is towards the start of the volume, it however common the MFT is fragmented and those additional fragments have a better chance of surviving.
The more of the MFT survives, the better and more complete file system reconstruction will be. You can only find out by trying. If part of the $MFT survived, partial reconstruction of folder structure may be possible which IMO is preferred over a purely raw recovery.
However more likely is that your recovery will largely consist of files detected by their magic bytes or signature, so without original filenames and folder structure.
A very common scenario is that Windows Media Creation tool was run and wrong drive selected. If the victim/target drive contains a single NTFS partition, it's likely the bulk of MFT data gets overwritten by the media creation tool and recovery software will not detect filenames or original folder structure.
Original question, Hard disk failed, no backup - how to proceed with data recovery?
I'll address specific question and some tools (as these are commonly recommended tools) and go somewhat 'broader' so the answer may apply to other data loss scenarios too.
If your data has value, go to a pro. Most recoveries, even those requiring clean room work do not exceed say $850 but some labs are in to $300 - $500 range even if clean room is required and if no additional parts need to be sourced. - USA/EU prices!! Depending on your geographical location prices may differ.
Many failed DIY attempts may hamper recovery and add to the price. This is true if the data loss has a physical cause and if in-place repairs are attempted (partition table editing, rebuild RAID etc.).
As a rule of thumb, if the cause for the data loss is known, for example you deleted a file or partition or formatted a partition, it is safe to assume there's no physical cause.
With sudden data loss a physical cause should not be ruled out before hand, even if the damage appears to be at the logical level. For example, a RAW file system can be due to logical corruption, it is however also a common symptom for physical damage. Even just repeated read attempts can further damage a drive or cause firmware damage (g-list overflow).
If damage is obviously physical, for example after dropping a drive, a lab is always the best solution and DIY attempts are almost guaranteed to make the situation worse.
It does not hurt to use a S.M.A.R.T. utility. Although the information may be overwhelming it can be useful. Treat information as such: If the SMART tool alerts you about problems then assume there are in fact problems. However, absence of alerts does not mean the drive is okay by definition.
Check RAW values of at least following attributes:
If raw values are non zero the drive had, at some point, problems reading sectors. Large values IMO (say > 20) are alarming even if the SMART tools says they are not. An easy to use and free SMART tool is CrystalDiskInfo. In menu Function > Advanced Feature > set RAW values to 10 [DEC]. Most of the file recovery tools I'll recommend later on also can display SMART data.
It is true that SSD's are less prone to mechanical damage of moving parts. Still, sudden disappearance of data can have physical causes such as sudden loss of power. SSD's can and do suddenly fail just like conventional hard drives.
Also SSD's can experience 'bad sectors' although these are of an entirely different nature than bad sectors on spinning disks. Such bad sectors can have cascading effects and SSD's, once they start behaving odd or unstable can deteriorate rapidly. If a lab is not an option and you need more than a few files, skip to cloning.
What about TRIM?
TRIM is often misunderstood. it's is important to understand that TRIM is a command that is sent by for example the operating system to inform the SSD drive about a range of sectors that can be discarded. TRIM is not file deletion of erasure in itself.
It depends on a specific OS if and when it sends TRIM commands. One OS may send a TRIM command immediately if for example a file is deleted, the other may schedule weekly TRIM commands, or an OS may do both.
For example Windows sends a TRIM command when you format a partition or as soon as you delete a file - if it concerns a NTFS formatted volume. So, in general data recovery from a formatted partition is impossible unless: 'circumstances' (non 'supported' file system, older USB bridge not relaying TRIM commands, etc.).
If you however you can not access the partition because the file system is RAW, this is no reason for Windows to 'TRIM' that partition and in general one can assume the data can be recovered. So in general, an OS will only TRIM data that is purposely deleted.
TRIM =/= erasure, or zero-fill although it may appear that way. In short: Many controllers 'unmap' trimmed LBA addresses. Try reading such LBA addresses and the controller simply returns zeros without even ever reading the drive. A data recovery lab may be able to recover 'trimmed' data while a data recovery lab can not recover data that was truly overwritten, even if only overwritten with zeros.
Although many may associate TRIM primarily with SSD's, it (ATA TRIM) is also supported by specific SMR hard drives, and also TRIM like mechanisms are in place on for example SD Cards and CF cards.
TestDisk.
Can be used to make some in place repairs where it concerns MBR, partition tables and boot sectors. These are a tiny fraction of all things that can be wrong and prevent access to your data, and in general it's a bad idea to make in-place repairs. That said, for a knowledgeable person patching a disk can be the quickest way to recovery with only marginal risks.
Also reason for data loss plays a role: If the known cause is accidental partition deletion, and the layout of the disk is known, picking the correct partitions isn't rocket science and fairly low risk IMO. If on the other hand cause for the data loss is unknown it makes no sense to try TestDisk just for the sake of it.
Partition undelete/recovery only makes sense if partitions are not visible, not if new partitions were already created and formatted. Boot sector repair only makes sense if the issue is actually the boot sector.
TestDisk can also copy data from a volume provided damage to the file system is minor.
PhotoRec.
PhotoRec is a so called 'carver' that recovers files by scanning the drive for headers and footers. There are several drawbacks with this method:
If carving however is the only option, PhotoRec may be one of the best tools for the job. It's default 'rules' set is often more complex and accurate than even pro tools.
Recuva.
In essence a file undeleter, though if a file system was accidentally formatted with exact same file system the tool can handle that too.
It is not by any standards a serious data recovery tool that should be used on 'corrupt' drives.
Tools for logical recovery used in data recovery labs include:
For these tools and-user versions are available too. They do not have to be expensive, 'cheapest' tool is $20 for a year license.
Before a data recovery tech will even attempt any file recovery he/she will first clone or image a drive.
At DIY level best tools for cloning a drive for data recovery purposes are ddrescue and HDDSuperClone.
Even though these tools are designed for this and good at what they do (specially HDDSuperClone), if cloning/imaging is problematic (drive disappears randomly, extremely slow, noisy) it's wise to stop DIY attempts.
What if I just need a few files and I can still access the unstable drive?
I agree in such a case just going for those few files is likely to put less stress on the drive than cloning it entirely - a judgement call.
There are several places where data recovery specialists answer end-user questions. These may be more suitable than SuperUser as they allow for more interactive Q & A type conversation.
Questions or suggestions or criticism?
Please put them in the comments!
Another tool that could be very helpful is Foremost. The name of the tool is a dictionary word that might contribute to its relative obscurity as it can never get the first position in web search for its own name.
Foremost is a Linux program to recover files based on their headers and footers. The headers and footers are specified by a simple configuration file, so you can choose which headers you want to look for.
The tool has a prominent origin in the work of the United States Air Force Office of Special Investigations and The Center for Information Systems Security Studies and Research.
It has recently saved me a day when PhotoRec was unable to find any traces of sound files (ordinary RIFF WAVE format) on an FAT-formatted SD card with corrupt root directory entry.
The usage is very simple:
install foremost from your distribution repository if available or compile foremost from source. Compiling works like a charm as the tool has very few external dependencies
run foremost on the device or device image, e.g.
foremost -i /dev/hda -t wav -o /recovery/foremost
examine the /recovery/foremost directory for useful files.
Foremost does not modify the original device or device image, so it is usually safe to run it on the original device unless the device is failing. To be on the safe side, always have a backup dump.
Foremost is available for Ubuntu and is in fact the first choice for extracting individual files from a corrupt image.
If the file you want to recover is a plain text file (as Linux understands it, i.e. UTF-8) and the filesystem where the file used to be is/was neither encrypted nor compressed, in Linux use strings on the block device (partition) holding the filesystem.
For each file given, GNU
stringsprints the printable character sequences that are at least 4 characters long (or the number given with the options below) and are followed by an unprintable character.
(source: man 1 strings)
You want something like:
strings -aw -e S -n 10 /dev/sdX1 >/another/filesystem/extracted
(or pv /dev/sdX1 | strings -aw -e S -n 10 >/another/filesystem/extracted to see the progress).
Then extracted will be a text file you can view with less, search with grep etc. In my tests -e S was crucial to detect UTF-8 text with multi-byte characters.
Notes:
-n 10 tells the tool to print sequences at least 10 bytes long. The manual says "characters" but my tests with UTF-8 multi-byte characters show it's "bytes" for sure. The lower the number, the more garbage you will get. On the other hand you should not exceed the block size used by the source filesystem, which is at least 512 (the lowest common sector size for block devices). The point is your file may be fragmented and -n higher than the block size will miss a textual block, if it happens to be between non-textual data. If your file was tiny (smaller than -n you used) then you might miss it completely. Similarly you may miss the tail part of your desired file, if the part happens not to be adjacent to other text.
extracted will probably be relatively huge anyway, too big for "manual" inspection. You will probably need to use a good text editor or a pager (capable of handling large text files) to interactively search for the string you know was in the file you want to recover. Or use grep (possibly with -A, -B; see man 1 grep) to search for the string. This way you will hopefully locate the relevant fragment of extracted.
The file you're after may be fragmented, scattered, not necessarily in sequence. In extracted there may be old versions, there may be fragments of other files (garbage, including text-alike fragments of binary files); all these possibly interleaved. extracted as a whole will be a textual jigsaw puzzle. Consider using the -s (--output-separator) option of strings, but keep in mind if there are unrelated fragments strictly adjacent in the filesystem then you won't get a separator between them, as if they were one bigger chunk.
If the filesystem you're trying to recover data from is on SSD and TRIM was performed after the mishap in which you lost the file, then there's a risk the content of the file is gone. This is a bad scenario.
On the other hand, if the filesystem is on SSD and TRIM was performed before the mishap, and there was no TRIM later, then the TRIM may have wiped out unrelated old data, old versions of files etc., but not the content of the file you're after. In effect you will get less garbage from strings. This is a good scenario.
As you can see, SSD may be a disadvantage or an advantage. For HDD these scenarios do not apply. Virtual disks may support something similar to TRIM.
In the beginning I wrote "the filesystem […] neither encrypted nor compressed". An encrypted or compressed filesystem would store textual data not in its plain form, so strings would be useless. I guess some other features of some filesystems may lower your chances or cause some extra garbage.
If you have enough RAM, consider copying extracted to /dev/shm (or use vmtouch -l) to speed up your work with grep or something.
The whole idea requires a string you know was in the file. Using the name of the file as a known string won't help you locate the content because in general filenames and actual data are stored separately, not necessarily near each other. This observation leads us to a preemptive strategy (i.e. in advance, before any mishap) that can make your important text files more prone to be recovered by our method after a future mishap.
Let's suppose you want to store a SerialKey for VeryImportantSoftware in a text file. The key is J7f9e7sc. Do not store the key only, build the text file like this:
SerialKey for VeryImportantSoftware
J7f9e7sc
In case you ever need to recover this file and you decide to use our method with strings, search for SerialKey and/or VeryImportantSoftware, or even for SerialKey for VeryImportantSoftware if you remember this is the exact string.
Recover data from NAND flash based drives, SD, USB pendrive, SSD, etc..
In general same procedures as with data recovery from magnetic drives. So:
There are also differences, for example for diagnostics we can not rely on our hearing to 'detect' mechanical damage because there are no moving mechanical parts. Since we have to do without this powerful aid, after all scratching and ticking noises are a very strong signal to stop moving a device, step 2 is even more vital.
What I am trying to say is, even if you still have access to the device, it may fail at any moment without audible warning.
1. Assess / diagnose the situation
First question you should always ask yourself is, 'what's the value of the data?'. If the answer is I can not live without it, because of monetary or emotional reasons it's best to stop tinkering sooner rather than later.
Failing flash based drives tend to fail all at once, so a binary situation, works or doesn't work. If there are however warning signs of degradation (the device being very slow for example), NAND flash based drives tend to degrade rapidly.
The main factor that decides between recovery being DIY-able is, is the device detected with the correct capacity:
If not then 99 against 1 you're dealing with a firmware issue that is most likely the result of degraded NAND.
2. Create a clone or disk image
This a mandatory step unless you only need to recover say 1 - 100 smaller files from the drive. This is highly arbitrary: you could argue simply copying these files is less taxing than cloning the entire drive. And the less stress / tax we put on the drive, the better.
To create a disk clone (drive > drive) or image file (drive > file) you'll need a tool that:
There are several tools that meet these requirements, consider that you image based drive back up tool is most likely not one of those. So Norton Ghost type tools are best avoided even if they allow for bypassing of bad sectors, and offer a sector by sector image/copy option!
Examples of tools you can use:
The tools that tick all marks are HDDSuperCLone (open source) and DMDE (free version).
Generic imaging strategy:
Assuming we're imaging for example a USB flash drive or NVMe SSD with the help of a USB adapter, set up the imaging tool for SCSI I/O.
Use shortest time-out you can get away with specially during first pass.
3. Recover files and folders from clone or disk image
Once you have a disk image or copy of the drive, you bought yourself all the time in the World you need to find the best file recovery tool, without having to worry about the drive failing completely.
(For added security you can create a copy of the disk image file).
You can try/use any file recovery tool that can analyse dd type disk images, and any serious tool should be able to do so. Examples, are FileScavenger, R-Studio, UFS Explorer, DMDE, Klennet Data Recovery and many more.
Success of file recovery depends on the amount of sectors we couldn't copy, state of the file system, and the software used.
If file system is reasonably intact, any of the above tools should work. Advantage is that files are likely recoverable including the original file names and folder structure.
If not you're down to carving: a carver is a tool that ignores the file system and detects files based on magic bytes or signatures. PhotoRec (open source) is an example of an excellent carver. Carvers generate file names and can not recover the original folder structure.
Special carving cases:
If file system is damaged then generic carvers may not work to well for, for example MP4 video files. For example GoPro's produce fragmented files, so you'd need a tool that was specifically designed to reconstruct such videos (Klennet Carver, GoPro Recovery are example of such tools).
Specifics to NAND based drive recoveries
I mentioned before NAND flash based drive tend to fail sudden and in a binary fashion; they either work or they don't. There are tell-tale signs however the drive is approaching this point, they tend to get really slow, and read errors may increase rapidly.
Another peculiarity is the influence of the firmware/controller, more so than with spinning drives. An example is a read error or drop down in speed does not necessarily correspond with the sector you're trying to read. Often it's due to the firmware that stops responding to our requests and a reset + retry may return the sector without issues.
Therefore limiting time-outs is important and helpful to speed up the recovery.
One thing we can not ignore and that is very specific to NAND based drives is TRIM.
There are excellent answers to be found on this site with regards to the why's and how's of TRIM. From a data recovery perspective it's is important to realize TRIM often makes data recovery as good as impossible.
In general TRIM commands are executed as soon as we purposely delete data. So a modern OS will send a TRIM command if it deletes a file. Or if it formats a drive. TRIM is not a factor if we're for example dealing with file system corruption (like a RAW drive).
So upon deletion the OS sends TRIM commands to the SSD drive to 'tell' it about LBA sectors it no longer needs. The OS may do so immediately or on a schedule (Windows for example does both).
Simplified: Since the drive now 'knows' the data in these LBA addresses can be considered deleted it will return zero filled sectors when we try to recover data from these sectors. In effect the data has thus become unrecoverable. Even if we can recover files (because file system meta data itself is not trimmed), it will be zero filled sectors (demonstration).
Modern SSD's, modern SSD enclosures support TRIM. SD and CF cards support TRIM like commands, USB Flash Drives do not.
Professional data recovery
A data recovery specialist offers some advantages:
Reviving 'dead' drives
Often asked variants of the question "how to recover data from .." is , "can I somehow revive my failed SD card, USB flash drive, SSD?".
In general the answer to the question is 'no'. Often the firmware 'issue' is the result of an underlying problem which is not resolved by repairing the firmware. So the question on should really ask IMO is, "even if it were possible to repair the device, should I, if it means I end up with an unreliable drive, that has already failed me before?".
Partition RAW or DELETED/LOST
By far the safest way to regain access to data / data recovery is following standard data recovery protocol:
RAW is a 'catch all' state which basically tells you Windows can not recognize the file system, but it does not specify the exact damage. And it's the exact damage that determines if we can repair the file system.
IMO repair should only be attempted if damage is limited to
and after the drive was cloned / imaged.
For example: If boot sector is corrupt the system may be unable to determine the location of the MFT which is the primary meta data structure in the NTFS file system. In this case Windows will designate the file system as RAW. Once we repaired the bootsector Windows can find the MFT and continue parsing the file system
Again: Ideally you first clone the patient drive to have a safety net. Repairs themselves can be rolled back, but damage that may occur after the repair can not.
Again: Safest option is to extract data from the damaged volume using file recovery software.
Tool I use for this is DMDE (www.dmde.com). Analysis and repair can be done using the free version.
Okay. We need to pay attention to the indicators column. In example partition is healthy and accessible. We see EBCF are displayed, the color is green.
If anomalies are detected one of the E-B-C-F an indicator can be either absent or red. Depending on indicator we can try repair the volume. For repairs we need to enable writing to disk and tick advanced options checkbox. Enable writing Disk > Device I/O parameters > Interface TAB > Allow write.
DMDE will find most deleted / lost partitions during it's initial quick scan (no need to press anything, simply select the physical drive).
Partition found as designated 'found'. You can right click the partition(s) > Edit > Insert the partition.
Repairs option can be found by right clicking the partition > Edit .. All writes require you to click 'Apply' which if only visible after you performed one of the edit options. DMDE will display warning dialog and suggest to create a file that allows you to roll back changes.
Before committing repairs check the file system by clicking Open Volume button. If DMDE does not present a directory tree then repairs will have no effect. In that case there's no other option than running a Full Scan or use a different file recovery tool to recover data.
After applying changes reboot the system. This should be done attended as you MUST cancel all actions Windows may suggest (such as running chkdsk).
An alternative is using TestDisk.
A full guide to partition recovery can be found here: https://www.cgsecurity.org/testdisk_doc/partition_recovery.html. Steps involve: