WD500LMVW USB 3.0 clicking

[castiman]

Hello all,
I have a WD Elements 10A8, inside there is a WD500LMVW with USB 3.0 connection.
The drive, spins up, makes the clicking noise... then after a few minutes makes it again... then after a few more minutes makes it again... and sometimes becomes visible to the computer.
Dmesg:

Code:

[ 1757.982331] usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd
[ 1757.999191] usb 4-1: New USB device found, idVendor=1058, idProduct=10a8
[ 1757.999196] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1757.999198] usb 4-1: Product: Elements 10A8
[ 1757.999200] usb 4-1: Manufacturer: Western Digital
[ 1757.999201] usb 4-1: SerialNumber: 575833314135333132313438
[ 1758.539737] usb-storage 4-1:1.0: USB Mass Storage device detected
[ 1758.540224] scsi host6: usb-storage 4-1:1.0
[ 1758.540545] usbcore: registered new interface driver usb-storage
[ 1758.544855] usbcore: registered new interface driver uas
[ 1759.539432] scsi 6:0:0:0: Direct-Access     WD       Elements 10A8    1042 PQ: 0 ANSI: 6
[ 1759.539955] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 1759.540674] sd 6:0:0:0: [sdc] Spinning up disk...


As soon as it became visible I tried with ddrescue to create a disk image and I think I was able to recover some of the data from the created image.
Here is a video of the drive spinning up: https://vimeo.com/user10359060/review/2 ... 8c79fdab67


So I'm wondering, does this repeating clicking mean:
1. likely a problem with the USB insufficient power supply (physical connection problems with the flimsy USB connectors)
2. likely a problem on the PCB (replacing the PCB with a donor PCB may help).
3. likely a problem with damaged heads or media (replacing the PCB probably will NOT help.)
4. not possible to say one way or the other.

Thanks in advance for any advice!

[digisupport]

3. likely a problem with damaged heads or media (replacing the PCB will NOT help.)

[abolibibelot]

Have you tried to check SMART data ? (It would be wise not to plug the drive just for that purpose... each time you plug it could be the last time it works.)
How complete is the ddrescue image ? How hard have you tried with ddrescue ? Could you post a ddrescueview screenshot ?

Of course, if you have important data on it, the best course of action would be to stop doing anything by yourself and bring it to a professional, but if data is not-so-important, or you have at least partial backups of the important stuff, or you absolutely can't afford a professional service, you may be able to recover what you need by insisting with the ddrescue imaging, or trying HDDSuperClone which is supposed to be more efficient in some circumstances. The author of that tool is a member here (@maximus) and could provide you with some further insight or guidance.

[castiman]

3. likely a problem with damaged heads or media (replacing the PCB will NOT help.)

I was hoping for more in a power supply problem, but thanks anyway for the sad news.

Have you tried to check SMART data ?

No, maybe it's the first think to do... but I have thought to create immediately a image of the disk.

How complete is the ddrescue image ? How hard have you tried with ddrescue ? Could you post a ddrescueview screenshot ?

If I am honest I think I made a mistake with ddrescue options, the first time I connected the disk it was recognized almost immediately, but unconsciously I used the following option "-r 3".
In doing so I think I've speeded up the degradation of the drive. :/
Here the ddrescueview screenshot: https://image.ibb.co/fKGZ3o/ddrescueview.png

The data was important, in the end only personal photos, but honestly now I do not remember how much space I had occupied, so I can't even define if from the partial image has recovered everything.
My mistake is that I didn't do these checks before.
I sincerely hoped that if I did the imaging right away, I would be able to do it after these checks, without thinking I'd damaged the disc more.

Anyway of the 265.31 Gb rescued, only 50 Gb are of actual files.
Do you think I was lucky and I managed to recover all the files? (Usually Windows with ntfs partitions, does it fill from the beginning of the disk or not?)

Thank you very much for your advice!

[Rling]

So I'm wondering, does this repeating clicking mean:
1. likely a problem with the USB insufficient power supply (physical connection problems with the flimsy USB connectors)
2. likely a problem on the PCB (replacing the PCB with a donor PCB may help).
3. likely a problem with damaged heads or media (replacing the PCB probably will NOT help.)
4. not possible to say one way or the other.

Thanks in advance for any advice!

Just wanted to say, that I am a big fan of recycling for environmental reasons.
Including recycling other users' posts

I hope you can get what you are looking for and get your data back.
Good luck
Rling

[abolibibelot]

If I am honest I think I made a mistake with ddrescue options, the first time I connected the disk it was recognized almost immediately, but unconsciously I used the following option "-r 3".
In doing so I think I've speeded up the degradation of the drive. :/

Disclaimer : I am not (yet) a bona fide data recovery professional, I'm still learning (as everybody should be actually ! ).
Watching the ddrescueview screenshot, my first thought was : this is a one platter / two heads drive, and one head has failed, so an entire platter side could not be read at all – BUT then I remembered that the data is never written in a linear manner on a hard disk drive, but rather with a “serpentine” pattern, as explained here :
“The drive traverses the user area in serpentine fashion. For example, it might read 100 tracks on head 0, followed by 100 tracks on head 1, then 100 on head 2, and so on until it returns to head 0.”
So, it would rather seem like the drive stopped responding altogether after hitting a bad area. Have you tried turning it off then on again (after a few seconds) when it appeared that no data was read anymore ? Or have you let it run unattended until the end ? You should use the -P switch to get a preview : if the preview is empty, no actual data is transfered, something is wrong. Apparently there are two bad spots, one at the begining and one in the middle, it may have been caused by a single shock, with the heads hitting both sides of the platter at the same relative location. You may have more luck trying to complete the image in reverse with the -R switch (from the very end to the bad spot in the middle). If the heads are still functional, my guess is that a good portion of the second half can be imaged like the first half. Don't use the -r switch as it indeed can stress the heads to no avail (sectors which can't be read at the first try are unlikely to be read at the 3rd) and it defeats the very purpose of ddrescue which is to bypass the bad areas and get the good ones ASAP.
But again do that at your own risk, as it may further damage the platters' surface and/or heads, and lower the recovery rate if you finally decide to bring the drive to a professional.

The data was important, in the end only personal photos, but honestly now I do not remember how much space I had occupied, so I can't even define if from the partial image has recovered everything.
My mistake is that I didn't do these checks before.
I sincerely hoped that if I did the imaging right away, I would be able to do it after these checks, without thinking I'd damaged the disc more.

Attempting to image the drive right away is a rather good idea, short of not attempting anything and going directly to a pro when it appears that the failure is a serious one – at least it's way better than scanning the drive with 10 data recovery softwares you never used before (and without actually extracting a single bit from the failing drive), or running CHKDSK, or some magic snake oil regenerator program... At least you did manage to recover something.
Checking SMART data (which is quick and can be done while ddrescue is running) can help with the diagnosis, but in this case the failure seems to be more serious than the kind that SMART is designed to assess.

Anyway of the 265.31 Gb rescued, only 50 Gb are of actual files.

How do you know that ? What have you tried to extract files out of that image ? Mounting it directly ? Scanning it with a data recovery software ? Which one(s), with what options ?
The problem in this case is that one of the bad spots is located at the begining of the drive, and it's usually where important system files are located, including the file allocation information and metadata, which are contained in the $MFT file on an NTFS volume. If the file allocation information is partially corrupted you might be able to get more files by raw file carving, with a complete data recovery software like R-Studio (commercial but excellent functionality / price ratio), or with Photorec (freeware) which is designed specifically for that purpose (be sure to check/uncheck file types according to what the drive is supposed to contain, to reduce false positives or file truncation by random false file headers ; the problem with Photorec is that it's kind of a black box, it extracts files on the fly, puts them in folders of 500 regardless of their types, so you need a lot of storage space, and a lot of time afterwards to sort out that mess ; but it's efficient, and the naming scheme is convenient as files are named after their first sector number).
If the filesystem is indeed NTFS, you can use ddru_ntfsbitmap from ddr_utilities to create a domain mapfile for ddrescue, restricted to the actually allocated sectors, which are determined by analyzing the $Bitmap file ; the $Bitmap file has to be complete for it to work properly. You could first test ddru_ntfsbitmap on your partial image file instead of the source drive, to see if it does work, meaning, if the $Bitmap is complete. There's an option to extract a second domain mapfile restricted to the $MFT file only, which allows to copy that very important file first (but if it contains bad sectors it's not a good idea to insist too much on them).
You could also open the partial image with WinHex to see if it can find the complete directory tree, or if the MFT is corrupted (right-click on the $MFT and left-click on Open, then scroll down and see if there are large chunks of empty sectors).

Do you think I was lucky and I managed to recover all the files? (Usually Windows with ntfs partitions, does it fill from the beginning of the disk or not?)

Depends what is called “the begining of the disk”. Apart from what I quoted above about the “serpentine” pattern, yes, the drive is normally filled from the “begining”, which corresponds to the outer edge of the platters, the area where the data throughput is the highest. If the drive was only half full, then yes you probably recovered most of the files' contents, BUT if the $MFT (again if the volume was NTFS) is incomplete (because of that bad area at the begining) you won't be able to get some of them directly, with their name, location in the directory tree, timestamps, attributes and other metadata, and fragmented files will be very difficult to recover properly.

[castiman]

You are based in Italy, correct ?
Maybe you should contact forum member @michael chiklis - memberlist.php?mode=viewprofile&u=21477
If your drive does have some bad blocks + firmware issues but if all heads are still working more or less ok then maybe it should still be possible to image the drive using hardware based tools like MRT (after applying firmware patches) and extract the data without the need of (very expensive) clean room work ...
Regards and good luck.

Correct!
Thank you for your advice!
I will remember the contact in other cases, this time I will hope I have solved for myself.

So I'm wondering, does this repeating clicking mean:
1. likely a problem with the USB insufficient power supply (physical connection problems with the flimsy USB connectors)
2. likely a problem on the PCB (replacing the PCB with a donor PCB may help).
3. likely a problem with damaged heads or media (replacing the PCB probably will NOT help.)
4. not possible to say one way or the other.

Thanks in advance for any advice!

Just wanted to say, that I am a big fan of recycling for environmental reasons.
Including recycling other users' posts

I hope you can get what you are looking for and get your data back.
Good luck
Rling

All right, you got me. XD
Sorry if I did that...but when I read your post, I immediately thought: Oh, but it's what I want to say...just change chattering to clicking!
I'm not a best in english...so when I can, I find the fast way to write correctly, thank you!

Have you tried turning it off then on again (after a few seconds) when it appeared that no data was read anymore ? Or have you let it run unattended until the end ?

Ok I have to be honest, I have not explained in detail all the steps I have taken.
I hope in the future not to repeat the same mistakes and think before doing something :/
Even if I step by noob, I explain the disaster I have combined (don't ask me why, because I don't even know why I was so superficial).
The only positive thing I thought was also ruined by my actions.
Disclaimer: I'm just a computer science student, that try to breaking everything.
After this off topic..

My friend give me his hard drive and ask me to try to recover the files. (I just to learn I'm always kindly and I accept to help everyone, at own risk XD)
Firstly I connected the hard drive to my notebook and I only tried to run ddrescue. After 14.18 Gb rescued, I realized that I would needed 500gb and time to finish the process, that I did not have on my pc and I have stopped the process.
https://ibb.co/nLr6zT
So I thought used another disk (with 500gb free? No..I would have been too smart).
I have run ddrescue (same options: -r3 -d and without using the previous log ) unattended until the end of space of recipient disk.
https://ibb.co/hvYE4T
After I have done this stupid steps, finally I used a virgin hard disk (with 500gb free).
So I copied the previous image and log file to the new hard disk and I have run again the ddresceu (same options).
But from this moment on I noticed that there were more errors that increased than the rescued.
https://ibb.co/dOX7Oo

Don't try to understand why of all this and now that I think about it, I could answer my initial question myself.

3. likely a problem with damaged heads or media (replacing the PCB probably will NOT help.)

I wanted to explain everything, because you were very kind in trying to suppose the possible causes and give me all these tips!

You may have more luck trying to complete the image in reverse with the -R switch (from the very end to the bad spot in the middle). If the heads are still functional, my guess is that a good portion of the second half can be imaged like the first half. Don't use the -r switch as it indeed can stress the heads to no avail (sectors which can't be read at the first try are unlikely to be read at the 3rd) and it defeats the very purpose of ddrescue which is to bypass the bad areas and get the good ones ASAP.

Now I'll try to run ddrescue with the -R option, but I honestly think I've completely damaged the hard disk.

How do you know that ? What have you tried to extract files out of that image ? Mounting it directly ? Scanning it with a data recovery software ? Which one(s), with what options ?

On Windows, I have used OSFMount to mount the img file and "Starus NTFS" to try to recover the files. This software show me all directory and files named correctly.
So I think the $MFT file is safe (right?)

If the filesystem is indeed NTFS, you can use ddru_ntfsbitmap from ddr_utilities to create a domain mapfile for ddrescue, restricted to the actually allocated sectors, which are determined by analyzing the $Bitmap file ; the $Bitmap file has to be complete for it to work properly. You could first test ddru_ntfsbitmap on your partial image file instead of the source drive, to see if it does work, meaning, if the $Bitmap is complete. There's an option to extract a second domain mapfile restricted to the $MFT file only, which allows to copy that very important file first (but if it contains bad sectors it's not a good idea to insist too much on them).
You could also open the partial image with WinHex to see if it can find the complete directory tree, or if the MFT is corrupted (right-click on the $MFT and left-click on Open, then scroll down and see if there are large chunks of empty sectors).

Yes it is formatted in ntfs so now I'll try what you've written to me, even just to learn how to use this utility and to know how can I recoved file in this situation.

This time I think I was very lucky..
Thank you very much for explaining everything to me in a precise way, you made the whole situation much clearer!

P.S.

But again do that at your own risk, as it may further damage the platters' surface and/or heads, and lower the recovery rate if you finally decide to bring the drive to a professional.

Thank you for your continued recommendation. If I had to be honest if the files had been much more important, I wouldn't even have allowed myself to do all these tests, but I would have advised my friend to contact a professional. Also because I know that they have more professional equipment than I do not have.

[abolibibelot]

My friend give me his hard drive and ask me to try to recover the files. (I just to learn I'm always kindly and I accept to help everyone, at own risk XD)
Firstly I connected the hard drive to my notebook and I only tried to run ddrescue. After 14.18 Gb rescued, I realized that I would needed 500gb and time to finish the process, that I did not have on my pc and I have stopped the process.
https://ibb.co/nLr6zT

Indeed it was quite careless not to have planned to have enough space right away... The thing to keep in mind when working on a failing drive (especially without the means to perform advanced procedures like replacing the HSA = head stack assembly or patching the ROM or whatnot, when you can only rely on cloning/imaging with software tools and hoping for the best) is that each time you turn it on can be the last time it ever functions and is able to extract data. But from that screenshot it would seem like only 2.36MB are corrupted at the begining, and the bad area appears in yellow / light green rather than red as on the first screenshot you sent. Apparently for the next step you started all over again, with a worse result, meaning, more bad sectors. Did you keep that first (very partial) image ? If you did keep it, you could merge it with the more complete image to hopefully get a higher percentage of the MFT, and a better recovery efficiency (you won't have much more of the actual files contents, which are mostly in the green area, or unrecoverable if the drive is indeed too damaged now, but you might have more metadata to be able to access them right away and extract them properly, with their native names / timestamps / attributes, and in one piece if they were fragmented). You can do that with ddrescue itself. Be sure to backup the image files before attempting this. (I'm writing this from memory, do verify each command and run some tests before doing it for real.)
First run ddrescue with the larger image file as output with the -G switch which stands for “generate” : this will only create a mapfile/logfile marking all empty sectors as non-tried. Normally you have to set the source drive as input, but in order to not stress it any further I suggest that you instead create a dummy copy of the recovered image (you should still have a complete copy of it just in case something goes wrong), using the -s and -x switch (-s means that you only image a defined size of the input, -x means that you extend the output file size to a defined value) :

Code:

ddrescue -s 1048576 -x [exact size of source drive in bytes] bigimagefile bigimagefiledummycopy dummmycopy.log

This will create (very quickly) a file occupying only 1MB on the working drive but with the same apparent size as the whole source drive (~500GB).
Then use the dummy copy as input, the big image file as output (this should not modify it, but if you use a wrong switch and it does modify it in an unwanted way, you have a copy) :

Code:

ddrescue [-P] -G bigimagefiledummycopy bigimagefile generate.log

Then run ddrescue with the small image file you obtained at the first step as input, the big image file you obtained later on as output (keep a copy!), and the logfile/mapfile obtained at the above step.

Code:

ddrescue [-P] smallimagefile bigimagefile generate.log

This should be very quick and complete only the red area at the begining. There will still be empty sectors, probably some in the MFT, but it should be a great improvement when you try to mount the image or scan it with recovery softwares.

So I thought used another disk (with 500gb free? No..I would have been too smart).
I have run ddrescue (same options: -r3 -d and without using the previous log ) unattended until the end of space of recipient disk.
https://ibb.co/hvYE4T

Well, on that second screenshot it also appears that only a few MB are corrupted at the begining. Are you sure that you copied the partial image and did not start all over again at the 3rd step rather than the 2nd ? What I suggested above still stands, but you should probably use the partial image obtained at the 2nd step, as it appears to contain some extra sectors which are neither on the 1st nor in the 3rd (the two yellow blocks on the 2nd line). But if the image from step 2 has been modified to produce the result from step 3, then I don't understand how sectors which were apparently recovered could now appear as bad. Maybe providing the logfiles themselves could be helpful in trying to understand what went on. With ddrescueview you can set the grid size to a lower value to get a more accurate visualization of the good/bad areas.

After I have done this stupid steps, finally I used a virgin hard disk (with 500gb free).
So I copied the previous image and log file to the new hard disk and I have run again the ddresceu (same options).
But from this moment on I noticed that there were more errors that increased than the rescued.
https://ibb.co/dOX7Oo

Indeed, the drive's state seems to have deteriorated at that point, but still, what was already recovered should still be there on the image if you did copy the image file and the log file and started from there. (That's the whole point of the log file in ddrescue.)

On Windows, I have used OSFMount to mount the img file and "Starus NTFS" to try to recover the files. This software show me all directory and files named correctly.
So I think the $MFT file is safe (right?)

I don't know this Starus NTFS software. It can show a directory structure if the MFT is not completely corrupted, but it might be (very) incomplete depending on how many file/folders records are mising. An advanced software like R-Studio will both attempt to reconstruct the directory structure and find all files that have intact MFT records, and also detect “raw” files according to their signarure (header), which will be listed in a separate “Extra found files” directory, sorted by type, with a random name. Depending on how badly the MFT is corrupted, there might be many extra files there. If they were not fragmented, they will be normally readable, but with a random name and none of their native attributes.
With ddru_ntfsfindbad from ddr_utilities, you can get a list of the damaged files on an NTFS volume, obtained from the analysis of ddrescue's logfile. If the MFT itself is corrupted the results won't be accurate, but it may be able to assess the amount of corrupted data in the MFT itself.

[maximus]

Disclaimer: If the data is really important, seek professional data recovery.

With the disclaimer our of the way, I am going to admit that I have not completely read every word in this thread. But I did look at the ddrescueview screenshots. And it looks to me that when the drive hits a spot about in the middle, the drive goes into some sort of fault condition. Unfortunately ddrescue is unable to detect this kind of condition, and all reads from that point on are reported as bad. While there are ways of resetting the log after events like that, there is likely a better way. And that is to use HDDSuperClone to clone the drive. It can detect when the drive is no longer responding properly, and will stop with a message indicating such. You would then power cycle the drive, and resume the recovery. If you have any questions about HDDSuperClone or how to use it, feel free to ask me.

[castiman]

Indeed it was quite careless not to have planned to have enough space right away... The thing to keep in mind when working on a failing drive (especially without the means to perform advanced procedures like replacing the HSA = head stack assembly or patching the ROM or whatnot, when you can only rely on cloning/imaging with software tools and hoping for the best) is that each time you turn it on can be the last time it ever functions and is able to extract data. But from that screenshot it would seem like only 2.36MB are corrupted at the begining, and the bad area appears in yellow / light green rather than red as on the first screenshot you sent. Apparently for the next step you started all over again, with a worse result, meaning, more bad sectors. Did you keep that first (very partial) image ? If you did keep it, you could merge it with the more complete image to hopefully get a higher percentage of the MFT, and a better recovery efficiency (you won't have much more of the actual files contents, which are mostly in the green area, or unrecoverable if the drive is indeed too damaged now, but you might have more metadata to be able to access them right away and extract them properly, with their native names / timestamps / attributes, and in one piece if they were fragmented). You can do that with ddrescue itself. Be sure to backup the image files before attempting this. (I'm writing this from memory, do verify each command and run some tests before doing it for real.)
First run ddrescue with the larger image file as output with the -G switch which stands for “generate” : this will only create a mapfile/logfile marking all empty sectors as non-tried. Normally you have to set the source drive as input, but in order to not stress it any further I suggest that you instead create a dummy copy of the recovered image (you should still have a complete copy of it just in case something goes wrong), using the -s and -x switch (-s means that you only image a defined size of the input, -x means that you extend the output file size to a defined value) :

Code:

ddrescue -s 1048576 -x [exact size of source drive in bytes] bigimagefile bigimagefiledummycopy dummmycopy.log

This will create (very quickly) a file occupying only 1MB on the working drive but with the same apparent size as the whole source drive (~500GB).
Then use the dummy copy as input, the big image file as output (this should not modify it, but if you use a wrong switch and it does modify it in an unwanted way, you have a copy) :

Code:

ddrescue [-P] -G bigimagefiledummycopy bigimagefile generate.log

Then run ddrescue with the small image file you obtained at the first step as input, the big image file you obtained later on as output (keep a copy!), and the logfile/mapfile obtained at the above step.

Code:

ddrescue [-P] smallimagefile bigimagefile generate.log

This should be very quick and complete only the red area at the begining. There will still be empty sectors, probably some in the MFT, but it should be a great improvement when you try to mount the image or scan it with recovery softwares.

I know it's a forum and not a chat, but I still want to apologize if I'm answering after more than a month, mostly because I don't want you to have written the steps in detail and I don't give you a feedback.
The real problem with this delay was due to the recommendation to make a backup of the image, I had no where to do it :/
However now I finally managed to perform the steps described by you and first of all the backup of the images.

These are the commands I executed:

Code:

ddrescue -s 1048576 -x 500073234432 test.img testdummycopy.img dummycopy.log

Code:

ddrescue -G testdummycopy.img test.img generate.log

Code:

ddrescue -C /media/root/DDRescue/Pass1/test.img test.img generate.log

The last command integrates the good parts of the first test.img in the big file (test.img) right?

Well, on that second screenshot it also appears that only a few MB are corrupted at the begining. Are you sure that you copied the partial image and did not start all over again at the 3rd step rather than the 2nd ?

I knew that ddrescue worked with the log file, so I recommended to use the same file and the same image.

Maybe providing the logfiles themselves could be helpful in trying to understand what went on.

I attached all the log files created.

An advanced software like R-Studio will both attempt to reconstruct the directory structure and find all files that have intact MFT records, and also detect “raw” files according to their signarure (header), which will be listed in a separate “Extra found files” directory, sorted by type, with a random name. Depending on how badly the MFT is corrupted, there might be many extra files there. If they were not fragmented, they will be normally readable, but with a random name and none of their native attributes.

I tried the demo version of R-Studio and by mounting the image I can then view all directories and files. (a bit like Starus)

Perhaps from the long time passed, you can understand that it was not so important to recover data, but rather to know more about these software and the possible commands to be executed and also not to make more serious errors. I see it very much as a personal study, the fact of recovering them or not is also just a personal success. But as I've already said when it comes to imported data, I don't think I'd risk it either, and I'd rely on some professional data recovery center.
@abolibibelot Thanks again for the time lost and for the suggestions

Unfortunately ddrescue is unable to detect this kind of condition, and all reads from that point on are reported as bad. While there are ways of resetting the log after events like that, there is likely a better way. And that is to use HDDSuperClone to clone the drive.

Yes, perhaps I think I understood the matter thanks for the suggestion and especially for creating the tool. From now on I will try HDDSuperClone!

Attachments

generate.log

ddrescue -C /media/root/DDRescue/Pass1/test.img test.img generate.log

(2.14 MiB) Downloaded 917 times

dummycopy.log

ddrescue -s 1048576 -x 500073234432 test.img testdummycopy.img dummycopy.log

(356 Bytes) Downloaded 918 times

test3.txt

Logfile ddrescue third execution

(32.44 KiB) Downloaded 919 times

test2.txt

Logfile ddrescue second execution

(2.31 KiB) Downloaded 924 times

test1.txt

Logfile ddrescue first execution

(2.27 KiB) Downloaded 922 times