I do not recognize the (y). Do not respond yet.

Normally when dd completes it gives you a full stanza of data that tells you it completed, the # of blocks read and written, the bytes copied, time taken, data transfer rate, etc.

I suggest you wait longer to see if it completes normally. If not then we can try something different. You can also run the df command to see how much space is remaining in the partition you are copying to. Another thing that will tell you if it is still running would be to do "ls -l /mnt" which should display the file being created and if you do that a few time and the size is still changing then dd is still doing its job. Do all that from another terminal window, and you do not need to use sudo for those commands.

If I understood your intent, it was to recover the partition table, and testdisk had given you some usable info to recreate that. You will not actually be able to use the disk until the partition table is recreated, and that will require using the data from testdisk to manually recreate it. The backup using dd is to make certain all is not lost if a mistake is made in recreating the table.

Sorry, duplicate.

20 hrs now - no change in status display in terminal .

I can only conceive that the (y) is a confirmatory prompt to execute the dd task (?) .

Time to 'Enter' , in dd terminal ... ? (if it was 'gauging' <if> and <of> disk space for the task , it shouldn't have taken 2 hrs )

Yes , intent is to restore partition table ; all 4 partitions (with TestDisk findings ) , ON COPIED DATA FIRST , before attempting recovery of original disk .....

Attached Thumbnails

 

Ok, at this point it is certain that dd has not done its task, and no, the (y) is not a normal prompt from any version of dd I have seen.
You did not give any info about the results of the "df" or "ls -l /mnt" commands. They would be useful to determine what went wrong.

As a last resort and to start over do the following:
End the dd task with a "ctrl+C" then expand the filesystem / partition /dev/sda1 as suggested before by using gparted.
Make certain that the file created by dd is not taking up needed space. Unless dd completed properly then any file it left behind will need to be removed.
Once the space is larger then restart dd to make the copy.

I did execute that command ; return is in the pic in my last post .

Can you see the pic ? Does the 'return' not indicate anything ?

(done nothing else since ls -l /mnt execution ... )

----------

ed.:
I can 'Control C' , to terminate the dd operation , and re-execute ... ?

------------

2 ed:
I think I know the source of the (y) ; KVM was probably on 2nd pc .

I think also I know why dd task didn't complete (or even execute (?) ) ; 3TB drive might be bad (which might also explain why when on USB channel , it did not format correctly ...

No other spare drive atm - standstill .

But again , did return of ls -l /mnt indicate anything ? ABOVE ...

The file shows as created and seems OK in the pic, but I cannot read the numbers. Possibly 184 as the first 3 digits?
If so try the ls -l command again (3 or 4 times several seconds apart) and see if the numbers are changing (the smaller ones to the right end of that long number). File size and space available are very close. What was the result of "df"?

If the "ls -l" command shows the file size is changing then continue to be patient. If the file size does not change then dd is no longer copying.

I have not seen any updates and the last you posted dd was still running. Has it finished? Is the problem fixed? Do you need more assistance?

Been busy here savvy ...

Live 16.04 still running .

dd task seems to be complete .

(I have struck through text in CLI that I accidentally entered during dd execution (KVM on wrong switch ? ) )

What do I know now here ?

Attached Thumbnails

 

Ok, that shows the copy is complete and you now have the yourfile.img file as a copy of the drive.

Now the next step would be to run testdisk on the image file and see what it can tell you. The below images should step you through the screens of testdisk to get the data needed.

You can select the image file and not the drive if you want simply by telling testdisk what you want it to look at. "testdisk /mnt/yourfile.img" should work for that.

Attached Thumbnails

       

1 members found this post helpful.

You also know that you have a drive that is spectacularly slow and probably in trouble. That 1.6MB/sec is horrible. Even USB2 should be 10X to 15X that rate, and an internally connected drive should be more like 100X. The output from "smartctl -A" on both drives should be quite interesting.

1 members found this post helpful.

Yes , I think the 3TB drive might be faulty , IIRC , and also a 2.5" 640 G drive which I earlier tried as well .

TestDisk is still running on the 3 TB - 3 hrs now .

I'm waiting delivery a new drive ...

The new hard drive will show up right after successful recovery on copied drive , and recovery of original 250 G disk ; I got no problem with that

Can you provide the make/model of the 3TB drive. I suspect from the time taken to write the image file that you have one of the (to me) terrible new tech drives. I believe that because of the time required to copy the 250G drive, which as already mentioned is outrageously slow.

It is known that one of the newer technologies for drives, specifically known as SMR, is great for reading and storage space but deadly for speed when writing to the device. Seagate has several lines of desktop drives that use that tech and Barracuda is one of them. WD drives also use the same tech for their Red series. For both brands the only sure way to know what is used is to go to their site and look at the data sheet for the series of drive you are interested in.

I will never buy a drive that uses the SMR recording technology because of the slowdown in writes to the drive caused. I only use the professional or server series unless I can verify on the data sheet that SMR is not used on that drive. I have not seen nor heard of problems with drives using CMR technology like the WD Black series.

1 members found this post helpful.

Drive label in pic .

TestDisk (of dd copy result to 3TB copy) attached also.

I presume I want now to attempt to 'restore' data / partitions on 3TB first ???

Attached Thumbnails

   

My understanding was we were working on recovery of the partition table on the 250 GB drive. That means: No, we do not want to do anything with the 3 TB drive.

My understanding of steps so far was that you had created a partition on the 3 TB drive, formatted it and mounted it at /mnt. You then used dd to copy the 250 GB drive to an image file at /mnt/yourfile.img.

I then understood you were running testdisk on the image file /mnt/yourfile.img and I expected to see the output from that here. Instead I see the testdisk results from the 3 TB drive.

The other pic you posted of the drive is a WD caviar green which WD no longer sells and the data sheet does not tell if it is SMR or CMR tech so I have no way to confirm if that was the cause of the extremely slow copy with dd.

Yes Sir . But I thought it was suggested to me to do a dd backup , and attempt recovery of the COPY first ???

Yes , I THINK I have created a partition successfully (although I think the 3TB is failing) , and I think I have a good dd result thereon .

Yes , I just completed TestDisk on the 3TB .

Yes .

The TestDisk result of the original 250 drive does not appear on screenshot .

But again , don't I want to attempt recovery of the COPY first ???