"Blank" or "Empty" Media files after HDD data recovery

[Glauco]

After this, i tried with 3, 4, 5, 6 and 7000000000. Nothing...

might be translator

OK, now, what is the best procedure to solve this situation?

Thank you

[maximus]

Hi @maximus i did it again...

Really, after LBA 2930277248 it lost comunication.

I tried starting in 2930000000 hddsuperclone read at 2930277248 and finished the process. After this, i tried with 3, 4, 5, 6 and 7000000000. Nothing...

I am not happy with the output of hddsuperclone. Please try the following:

1) If you have not already, update hddsuperclone to the testing version 1.5.2.

2) Add --ata to your command. Example: hddsuperclone -s /dev/sda -t /dev/sdc -f testata --ata -i 30000000000

This will hopefully give me more information about why hddsuperclone is exiting like it is, and may indicate better if it is for sure a translator issue.

Hddsuperclone is currently not providing the proper output for a definite answer like it should be. Please help me with this so I can improve the program. If it is still unclear after this, then you will need to use something like MHDD or Victoria to know more.

[rogfanther]

Just one thing, that Glauco didn´t make clear.

Try to run the -i 30000000... when the disk is being detected. So, you run it first thing, not after hddsuperclone has already errored out in the "problem sector".

[maximus]

Just one thing, that Glauco didn´t make clear.

Try to run the -i 30000000... when the disk is being detected. So, you run it first thing, not after hddsuperclone has already errored out in the "problem sector".

Yes, exactly! If the drive has already hit an error and become unresponsive, then it will not read again until power cycled.

Another test for this is that after it fails to read and hddsuperclone exits suddenly, try again to read from a known good value. You must use a different log file so it does not think it already read that section of the drive. So after it fails, try something like -i 2800000000. If it fails right away and does not read any data, the drive is locked up, indicating a bad spot. But if it reads good data again, then it is not locked up, indicating a translator issue.

[maximus]

A 10 seconds test with MHDD/Victoria would have shown if it's a translator problem or not already ....

From a previous post MHDD was tried but could not see the drive. And the OP did not have a windows OS that could run Victoria. So instruct the OP on how to run and use those tools to perform the tests. I have asked for my final hddsuperclone attempts. After that, it is all up to you...

[Glauco]

Just one thing, that Glauco didn´t make clear.

Try to run the -i 30000000... when the disk is being detected. So, you run it first thing, not after hddsuperclone has already errored out in the "problem sector".

Yes, exactly! If the drive has already hit an error and become unresponsive, then it will not read again until power cycled.

Another test for this is that after it fails to read and hddsuperclone exits suddenly, try again to read from a known good value. You must use a different log file so it does not think it already read that section of the drive. So after it fails, try something like -i 2800000000. If it fails right away and does not read any data, the drive is locked up, indicating a bad spot. But if it reads good data again, then it is not locked up, indicating a translator issue.

The third drive is connected in a USB port (Expansion desk, is the only one i have at this moment to make tests)

@maximus, I did it:

I started in a "good" area, near to failing LBA (2930000000) (last printscreen)
Then, i made the test again in a good area even earlier (2900000000)
And, in a "Bad" area (3000000000)
and back to a "good" area, hddsuperclone read it perfectly again (2930000000)

This is it.

Waiting feedback.

Thank you all!

Attachments

[maximus]

The current issue is with the DESTINATION (target) drive, NOT the source. That is why it seemed so odd. Is the destination drive large enough? You are trying to copy a 4TB drive, and it is failing at about 1.5TB.

You can test further commands using /dev/null as the destination, but that will not copy any data and is only for testing. You need to figure out why the destination is having issues if you want to clone the drive.

[maximus]

Translator problem ....

Partial Access Problem ....

(As expected ...)

I bet you did not see the destination drive as the possible issue. I did, but there was an issue with the code that did not show this, and I needed this to see it. I did extensive testing with issues with the input device, but not the output. So then the question will be, will there be a physical issue found with the source later on when a full recovery can be attempted, or is it a logical issue with the data on the drive?

[Glauco]

The current issue is with the DESTINATION (target) drive, NOT the source. That is why it seemed so odd. Is the destination drive large enough? You are trying to copy a 4TB drive, and it is failing at about 1.5TB.

You can test further commands using /dev/null as the destination, but that will not copy any data and is only for testing. You need to figure out why the destination is having issues if you want to clone the drive.

I will format the target drive and try it again...

Thank you so much for the help!

[maximus]

Normally i just do a very fast test on the start, middle and end with a verify command ...

I'm not used to start by imaging without checking with a verify first so i never tought about a problem with a destination drive....

And both of us could analyze the drive with the tools that we are familiar with and come to a conclusion very quickly. But we are helping someone else and we don't have the drive, nor do we have control over the operation. That can make things difficult to diagnose, and this drive has still not been fully diagnosed. We have all made our assumptions based on the earlier posts where files were recovered as empty, and ddrescue could not read one of the partitions.

[rogfanther]

The current issue is with the DESTINATION (target) drive, NOT the source. That is why it seemed so odd. Is the destination drive large enough? You are trying to copy a 4TB drive, and it is failing at about 1.5TB.

You can test further commands using /dev/null as the destination, but that will not copy any data and is only for testing. You need to figure out why the destination is having issues if you want to clone the drive.

I will format the target drive and try it again...

Thank you so much for the help!

Glauco, you didn´t answer maximus question. To make it clearer, please describe :

How are you connecting the drives to the machine ? Is it a notebook or a desktop ?
Are the drives connected via SATA or using USB adapters ?
We know the problem drive is a 4TB one. How big and what is the model of the destination ( the drive you are cloning to ) ?

[Glauco]

The current issue is with the DESTINATION (target) drive, NOT the source. That is why it seemed so odd. Is the destination drive large enough? You are trying to copy a 4TB drive, and it is failing at about 1.5TB.

You can test further commands using /dev/null as the destination, but that will not copy any data and is only for testing. You need to figure out why the destination is having issues if you want to clone the drive.

I will format the target drive and try it again...

Thank you so much for the help!

Glauco, you didn´t answer maximus question. To make it clearer, please describe :

How are you connecting the drives to the machine ? Is it a notebook or a desktop ?
Are the drives connected via SATA or using USB adapters ?
We know the problem drive is a 4TB one. How big and what is the model of the destination ( the drive you are cloning to ) ?

Source Drive SATA 4 TB
Target Drive USB 5 TB (Expansion Desktop STBV5000100 in partitions, is there any problems with this?)

By the way, partitions can facilitate the emergence of problems in the HDD?

Thank you

[maximus]

We need to find out what is going on with the target (destination) drive. Please perform the following test:

Dot not connect the 4TB source drive.

Connect the 5TB target drive.

Perform the following command and provide the output. If it does not fit on the screen, either copy and paste, or do multiple screenshots to show all data:

fdisk -lu

[rogfanther]

Source Drive SATA 4 TB
Target Drive USB 5 TB (Expansion Desktop STBV5000100 in partitions, is there any problems with this?)

By the way, partitions can facilitate the emergence of problems in the HDD?

Thank you

Starting from the end : no, partitions will not facilitate the problems. The brand and model of the disks are the culprit here.

Now : You are cloning a 4TB disk . The disk you are cloning to (destination) must have at least 4TB of space. Is your 5TB disk partitioned in one big partition of 5TB ? Or how are the sizes of its partitions ?

Do you have data you want to keep in this 5TB disk ? Can you simply zero-fill it before the cloning ? ( yes, it will take a couple hours ) .

EDIT : maximus beat me to it. But just one thing @maximus : from the screenshots of hddsuperclone running, seems he is cloning from the full device ( /dev/sdb and /dev/sdc ) . If sdc was an external disk, partitions in it should have been erased by now. Or would that thing behave as a NAS of sorts exporting virtual devices ?

[maximus]

EDIT : maximus beat me to it. But just one thing @maximus : from the screenshots of hddsuperclone running, seems he is cloning from the full device ( /dev/sdb and /dev/sdc ) . If sdc was an external disk, partitions in it should have been erased by now. Or would that thing behave as a NAS of sorts exporting virtual devices ?

Yes, partitions should have been erased by the current process, or to be more accurate, overwritten by new ones from the source. I do not know of the format of the destination drive, that is why I ask for fdisk -lu command output. Either the drive is only showing up as a 1.5TB drive, or it is a matter of the destination being mounted by the OS and somehow the OS is blocking the write past a certain point (have never seen that before, just thinking about possibilities). It is not yet clear what the issue is with the destination drive.

EDIT: I forgot to mention that the fdisk command must be run with root privileges. If not run with root privileges, the fdisk command will have no output. Just want to make sure the OP knows that.

[maximus]

Also, can you show the SMART info of the 5TB destination drive?

[Glauco]

EDIT : maximus beat me to it. But just one thing @maximus : from the screenshots of hddsuperclone running, seems he is cloning from the full device ( /dev/sdb and /dev/sdc ) . If sdc was an external disk, partitions in it should have been erased by now. Or would that thing behave as a NAS of sorts exporting virtual devices ?

Yes, partitions should have been erased by the current process, or to be more accurate, overwritten by new ones from the source. I do not know of the format of the destination drive, that is why I ask for fdisk -lu command output. Either the drive is only showing up as a 1.5TB drive, or it is a matter of the destination being mounted by the OS and somehow the OS is blocking the write past a certain point (have never seen that before, just thinking about possibilities). It is not yet clear what the issue is with the destination drive.

EDIT: I forgot to mention that the fdisk command must be run with root privileges. If not run with root privileges, the fdisk command will have no output. Just want to make sure the OP knows that.

The drive format is NTFS. OK, I'm investigating the possibilities. Aware about fdisk as root.


I'll post the results soon.

Thank you all.

[maximus]

I found a specification document that may shed a bit of light on the "5TB" drive. The Seagate Desktop HDD ST1500DM003 is supposed to have 2,930,277,168 sectors. That is perfectly in the range where the write failed.

[rogfanther]

Then maybe Glauco doesn´t have a ST5000 but a ST1500 external unit ? Seems very possible, yes.

Glauco, please, post pictures of the labels of both your drives, the problem one and the usb one.

[Glauco]

Hi, first of all,
I could not take the tests today because it was too hard.

This 5tb HD has one of the unallocated 1.5TB partition, may have something to do with the issue being presented.

Tomorrow, I hope, I can do the tests.

Follow the HDD photos as requested.

P.S.: I tried posting the photos in every possible position. Always appear upside down in the post.

Attachments