Hi,

one old IDE RAID 1 (mirroring) system (NTFS) crashed. One disc is gone completely and I am trying to rescue the data from the other one. It sums up to about (estimated) 20 GB in 1500000 files in 60000 folders.
The disc is shown in Linux and Windows. It works connected to the mainboard directly and with IDE USB adapter (Digitus). I can browse the folders and open files. But when I want to copy everything (xcopy, 7zip, unstoppable copier) Windows unmounts the disc in between and Linux just reboots. I ran chkdsk multiple times, it always finds some errors and corrects them, but this does not seem to suffice.
Do you have any idea how I can save the data?

Greetings
KT5Cbp55pJqnHcGd

Suggest to do in the following order:
1. Stop running checkdisk. It makes things worse, if not too late already.
2. Power drive off completely and do not mess with it until you have a clear plan of action.
3. Need a solid diagnostic to determine the exact problem.
Would you like me to take a guess? Would say bad sectors and/or a weak head(s) causing more problems. But this is not certain as it is just a guess. Need more details about all of the drive's hardware and most likely, especially if the data is important, the best course of action is to inquire with a reputable professional.

_________________
Hard Disk Drive (HDD), Solid State Drive (SSD, SATA, NVMe, etc), USB Flash Drive and RAID Data Recovery Specialist in Massachusetts

The hardware is:
Maxtor DiamondMax Plus 9
80 GB ATA/133 HDD

The data is important enough for me to invest some time trying to get it, but not important enough to pay a professional.
Before you posted I ran a recursive directory/file listing, so I now have the exact filenames and locations.

abstracted example:

I have written a perl script that converts this listing into a batch file that can recreate the directory structure on my NAS and than copy the files one by one.

Do you think I should run this batch file or should I try something else first to not make things worse with this approach?

Suggest to check if there are hardware problems one by one, beginning with PCB, then internal read/write mechanism (any clicks of any kind even if it is silent clicks), then if these pass, then check SMART, then check for bad sectors. Do this until you narrow it down to the issue(s).

Can pretty much do all of this with MHDD. Search MHDD.

Generally speaking, if the drive IDs fine, then PCB should be fine.

_________________
Hard Disk Drive (HDD), Solid State Drive (SSD, SATA, NVMe, etc), USB Flash Drive and RAID Data Recovery Specialist in Massachusetts

@KT5Cbp55pJqnHcGd,

In addition to the helpful suggestions from labtech, my (deliberately brief) comments are:

- More details needed about the disk which is "gone completely". Sometimes people (understandably) ignore what seems to be the harder recovery, but it later turns out that this would have been the easier one.

If you accept all the risks of DIY recovery attempts (remember you could make things much worse, which matters if you later change your mind about using professional recovery):

- Clone the raw drive, using suitable tools designed to cope with failing disks now. Even if you had previous problems doing this, this is the best plan IMHO.

- Stop trying to access through the filesystem on this failing disk and, as already mentioned, stop running ckdsk or similar, which is always a bad plan on any failing disk (in fact it's a bad plan at many other times too ).

All IMHO, of course.

The free version of Copyr.dma should handle this kind of job.
You can find it on any Hirens disk.

So boot from cd, select dos tools, backup tools, copyr.dma

Clone the drive to a suitable target drive then you can recover your files from the cloned drive.

Also if you are lucky the cloned drive might even mount and boot to the OS!

I kinda have a guilty conscience, because despite your warnings, I just tried to run my batch script. I was too lazy to deal with the hardware issues and associated software you suggested. With pure luck, I guess, it worked error free. I don't know why, because I thought listing and copying one by one should be the same as letting an operating system do this by copying the whole content. Nevertheless, I have copied your recommendations into a text file, to which I will come back if I get into the same situation again with more important data.
Thanks for your time and sorry for my naughtiness.

Congratulations It's odd that it did work, because you originally said:


Therefore something has clearly changed, if your batch script equivalent of xcopy really did work...


No, they're not the same. Different use of APIs, different error recovery control, different access patterns to the disk LBAs etc. are involved in the techniques recommended to you. Anyway, glad you were successful

Yes, I also was surprised. This time Windows did not unmount the disk but just skip the broken files. I piped the output into a log file and in the result there were about 24000 error messages. With about 1.5 Mio overall files this gives a file loss of 1.6%, which is completely OK for me.
I was also amazed, that windows is able to run 300MB large batch files.