HDD GURU FORUMS

Hello everyone,

I could use some assistance on how to solve my scenario. I've posted a lot more information here (link below) with screenshots.

Link: https://www.tenforums.com/drivers-hardw ... ost2508748

SSD Specifications:
Samsung 2.5" EVO 970 1TB
Partition 1 on letter X:\ with 512,001 MB as NTFS on MBR. Formatted with 4096 cluster size. Approximately, 280 GB was used and written to. Note that this SSD has no physical damage and is in excellent health. Samsung software disk quality checks, firmware updates and full format were ran before putting into use.

Scenario:
Running robocopy.exe from the SSD to cloud storage overnight. Awoken in morning to find SSD in 'corrupt' state and unable to access data via Windows Explorer. USB C ports were intact, no removal of wires or loss of power and unknown why this has occurred.

jamanji is a fantastic user on those forums. In my scenario, I want to fully understand that running command chkdsk.exe F: /f /v /x will not result in the generation of folder found.000. Can we be certain of this?

Appreciate the help.

That entire thread is full of generally horrible data protection and recovery advice.

Stop trying to do an in situ fix and stay away from chkdsk if you want your data back in one piece. Clone or image the drive onto know good hardware and then use a decent data recovery tool to recover the files onto another drive. Something like r-studio or getdataback should do or DMDE if you're cheap.

I would clone your drive with HDDSuperClone, then run data recovery software against the clone.

Avoid running CHKDSK in repair mode, as there is a risk that this will worsen the problem. Even in read-only mode, CHKDSK has the potential to exacerbate the situation, so I would avoid it altogether.

In any case, you should not be writing to the source drive.

Can you show us the SMART report with a tool such as GSmartControl or CrystalDiskInfo?

fzabkar wrote:I would clone your drive with HDDSuperClone, then run data recovery software against the clone.

Avoid running CHKDSK in repair mode, as there is a risk that this will worsen the problem. Even in read-only mode, CHKDSK has the potential to exacerbate the situation, so I would avoid it altogether.

In any case, you should not be writing to the source drive.

Can you show us the SMART report with a tool such as GSmartControl or CrystalDiskInfo?

Thank you for the reply.

Apologies for asking but I need to have as minimum up-time on the SSD as fears of data being written. What's the steps to provide a SMART report that doesn't write data to SSD during the process? Running Windows 10 (2016).

Since Windows is seeing your drive as "RAW", it won't be able to write to it. Retrieving the SMART attributes entails reading a few sectors from the drive's firmware area. Don't run any of the SMART tests (ie no short or extended tests).

BTW, you haven't said whether Robocopy was able to save your data.

As for your USB enclosure, many people are reporting stability problems over USB. One user cured his problem by downgrading from USB-C to USB 3.0. It seems that the connection loses sync at the higher link rates.

https://forums.anandtech.com/threads/stable-nvme-usb-adapter.2572973/

fzabkar wrote:Since Windows is seeing your drive as "RAW", it won't be able to write to it. Retrieving the SMART attributes entails reading a few sectors from the drive's firmware area. Don't run any of the SMART tests (ie no short or extended tests).

BTW, you haven't said whether Robocopy was able to save your data.

As for your USB enclosure, many people are reporting stability problems over USB. One user cured his problem by downgrading from USB-C to USB 3.0. It seems that the connection loses sync at the higher link rates.

https://forums.anandtech.com/threads/stable-nvme-usb-adapter.2572973/

robocopy.exe was running transferring data from SSD to computer (read only on SSD, write to PC) then computer to cloud storage. Normally, the robocopy console is left open for me to inspect at the end but in the morning no console was present (process had closed). Normally, when errors arise the robocopy it will state this in console and wait a few seconds before attempting the same file on SSD another couple of times (set with flags). So, this is really bizarre that this situation has happened to me and I cannot pin-point what's happened other than suspect somehow the drive was disconnected, but that doesn't explain why robocopy console was not present during morning inspection.

1. What details do you require as recommended to now not run a SMART report?
2. Whats the best software to use for full bit-bit clone from one SSD to another?

--- Update on Feb 21st 2023 ---

I've updated the forum here (https://www.tenforums.com/drivers-hardw ... tfs-2.html).

I have cloned the corrupt drive to an image using DMDE. Then, I have cloned this image to another SSD drive to simulate the 'broken corrupted drive'.

Now, I'm asking for solutions on how to 'fix' this drive and return RAW to NTFS. As per forum linked above (with screenshots) I have attempted 'convert', 'chkdsk', and MiniTool Partition Wizard.

Current progress, I've cloned the first 2048 sectors of a working drive then will clone to first 2048 sectors of the 'cloned broken drive' using DMDE. First attempt didn't work, so I shall try again with identical device (as I have x2 Samsung EVO 870, one is the original corrupt, another can be used).

Once I find a solution on how to fix the NTFS RAW corruption (return RAW back to NTFS), I can then compare the original drive to backup drive to ensure DMDE has successfully extracted a minimum of 100.00% of the data (can go over this i.e. deleted or 'lost' files).

If you're aware of a hex-edit solution, cloning MBR sectors solution or and other ideas to return NTFS to RAW. Please let me know.

Appreciate all the help and support.

Why are you still messing about trying to fix the file system ? If you've purchased dmde fire it up , extract the files you need from your clone onto another formatted working drive - job done.

Nobody knows what state the file system is in after all that you've done to it and as it's little more than a container for the actual files which you can access still it really doesn't matter either.

Lardman wrote:Why are you still messing about trying to fix the file system ? If you've purchased dmde fire it up , extract the files you need from your clone onto another formatted working drive - job done.

Nobody knows what state the file system is in after all that you've done to it and as it's little more than a container for the actual files which you can access still it really doesn't matter either.

I would like to find a solution that I can then apply to future problems if this occurs again.

Moreover, if I can fix the 'clone of original drive', then I can compare this to the DMDE extracted files for data verification.

Any ideas on a potential fix send them my way! Thanks in advance.