Cloned OS onto 3TB storage instead of USB stick

[v&n]

Both d_l_n and v&n are among the few folks around here whose advice/input/guidance I'd trust without question.

Thanks for the confidence dasein. I wish I had more time to devote to learning so I could be really worth the trust you seem to bestow upon me. Yes, I'm still clueless about the 'new changes' they have recently introduced in Linux systems. :/

..it's been ages since I've had to resort to photorec, which means that my information may be dated. That said, the last time I used it, it could recover a file, but not the name.

It's still true about photorec, as far as I know from a 5-6 month old experience. Don't know if it has improved in that area in the meanwhile. And that's why photorec should be last option, when testdisk or any other tools the OP might try have failed.

Since the damaged drive is a Windows disk, you might solicit advice from folks more expert in Windows; there may be other tools/options/etc. that folks here simply do not know about.

Agree. Although the last time (in 2014, if I remember correctly) I used a highly rated commercial windows-specific tool, called "Get Data Back" by runtime software, it took 24+ hours to recover less than half of the lost data (photos and videos of a studio) from a crashed hard drive that was physically healthy (let me admit that the drive was attached to my laptop via a cheap USB adapter, so that might be a factor in the ridiculously long time). Then just for giggles, I tried photorec on the same arrangement, and it recovered 100% data in less than an hour (yes the naming was a problem, but it didn't matter for the studio guy I was helping). Since then, I've never looked back at windows specific tools. But that may be partly because I've never needed to.

In one very specific hopeless case in 2009-10, where the drive was so bad that it wouldn't let any system boot that I tried connecting it to, I got unexpected success with the network edition of "Rtools", an old windows software, by booting the system with its 'rescue boot environment CD'. It was specially designed boot environment to handle such cases by ignoring drive errors during boot, then recover whatever was recoverable over network onto another system running its 'Agent' version. Other than that, I've never had any great success with windows tools that I couldn't have more efficiently with testdisk/photorec.

That said, software evolve all the time, and MS is trying harder than ever to cage their users within their commercial eco-system by introducing new 'features' that open software don't always work very well with. So yes, getting a second, third opinion from 'current' windows experts may be worth it.

[phenest]

Please tell me at least some of the data will.be recoverable?

This would depend on how full the HDD was before you messed it up. If it's 3TB, then you'll need something equally as big to copy over the recovered files. It also depends on how fragmented the Windows partition was. The more it was fragmented, the harder it will be to recover whole files.

[v&n]

It also depends on how fragmented the Windows partition was. The more it was fragmented, the harder it will be to recover whole files.

If testdisk or any other tool succeeds in restoring the previous filesystem, the recovered files that have not been overwritten will be intact, even if fragmented. The broken file problem due to fragmentation is a concern only if the OP has to resort to photorec or a similar tool that does the recovery using 'forensics' mode.

Also, 3TB or larger empty drive is needed only for creating image of the drive in question, and work on that instead of the drive itself. The space required for storing the recovered files will obviously be equal to the size of 'recoverable' data on the drive.

[phenest]

If the drive is fragmented enough, the OP may have over-written some of the fragments, making recovery of whole files impossible.

If the HDD is 3TB and there is little free space, it's stands to reason that a lot of the data will be the users personal data. Therefore a large drive will be needed.

Until the OP responds, we can only guess as to the extent of the damage and drive usage, etc.

[dasein]

I'm still clueless about the 'new changes' they have recently introduced in Linux systems. :/

You and me both! (And it's an ignorance I have every intention of cultivating actively. )

...the last time I used [photorec], it could recover a file, but not the name.

It's still true about photorec, as far as I know from a 5-6 month old experience. Don't know if it has improved in that area in the meanwhile.

Given how photorec works, it'd be moderately surprising if it had. But I felt obliged to offer the caveat, just in case.

So yes, getting a second, third opinion from 'current' windows experts may be worth it.

Ya never know. And it couldn't hurt to ask.

[I messed up bad]

Drive was never filled so fragmentation should be minimal? My biggest concern is that something important was among the first 2.5gb ever transferred o to the drive.

Sure enough it has a 2.4gb partition and the rest is unallocated. Once I satisfied gnu ddrescue with the correct command, it began copying from one desktop usb drive to another at almost exactly one gig per minute so about a fifty hour job as yet unfinished.


Here is the advice cgrenier of testdisk has given me:

Use testdisk 7.1-WIP, EFI GPT, Analyse, Quick Search and if necessary Deeper Search.
TestDisk should find your NTFS partition using its NTFS backup boot sector.
When the partition is listed set it to P(rimary). On next screen, choose Write, confirm, BackupBS, confirm, Quit

[dilberts_left_nut]

Sounds reasonable, although if it was originally mbr that might complicate things if testdisk rewrites it as efi - never had need to try that so good luck

As long as you're working on a copy you can try stuff and see (albeit with a 50hr reset if it all goes titsup - but probably just blanking the first 2048 sectors will 'reset' it - all recoverable data is well down the drive from there anyway).

I would think regular dd (as opposed to gddrescue) should work ok as well, as you're not dealing with any physical defects, just messed up data.

The end result should be a visible NTFS filesystem from which you can extract anything that isn't in first few GB.

[v&n]

Once I satisfied gnu ddrescue with the correct command, it began copying from one desktop usb drive to another at almost exactly one gig per minute so about a fifty hour job as yet unfinished.

Are both the drives USB3 connected to USB 3 ports? I wonder if the USB2 speed is the bottleneck here.

I just tested with my external USB3 WD Elements 2TB drive connected to the only USB3 port of my laptop, to copy its initial 4GBs to my internal Intel SSD (NTFS partition, so that itself is most likely another bottleneck here for the ntfs-3g driver), and the average speed I got was 41500 kB/s. That is, about 2.4 times the speed you are getting.

[dasein]

My biggest concern is that something important was among the first 2.5gb ever transferred o to the drive.

A valid concern, but not something you can fix. (See object lesson regarding backups, above.)

Regarding time... think of it this way: whatever time is required to clone the drive and recover the data is vanishingly small compared to the time required to recreate the data. (Bonus: it's time in which you can do other things.)

Good luck.

[I messed up bad]

Sounds reasonable, although if it was originally mbr that might complicate things if testdisk rewrites it as efi - never had need to try that so good luck

As long as you're working on a copy you can try stuff and see (albeit with a 50hr reset if it all goes titsup - but probably just blanking the first 2048 sectors will 'reset' it - all recoverable data is well down the drive from there anyway).

I would think regular dd (as opposed to gddrescue) should work ok as well, as you're not dealing with any physical defects, just messed up data.

The end result should be a visible NTFS filesystem from which you can extract anything that isn't in first few GB.

That confused me aswell. Im going to see what testdisk sniffs up first anyway but I wonder if cgrenier hasnt taken my statement about "tails writes a 2.5GB partition with gpt" and applied that to the entire drive. I would ask but he seems to only give the breifest possible assistance (which I completely understand, its more than nothing)

Yes the transfer is usb 2

[I messed up bad]

Also he told me to use the beta, 7.1

[dilberts_left_nut]

Being a 3TB drive, it could well have been gpt to start with (sorry I conflated that with efi above) - might pay to try finding out with a search for the drive model specs or such.
His advice is probably better than mine.

You might also want to try blanking the start of the disk (with 'dd if=/dev/zero of=/dev/sd<whatever> bs=1M count=512') or such.
This will remove any drive/partition info from the tails install, that has nothing to do with the original layout you are trying to restore, and could potentially confuse testdisk.

[dasein]

You might also want to try blanking the start of the disk (with 'dd if=/dev/zero of=/dev/sd<whatever> bs=1M count=512') or such.

But be extra careful to specify the correct "whatever"

@d_l_n -> I'm still running MBR, and barely know how to spell GPT, so please forgive my ignorance: why blank a half a gig?

[dilberts_left_nut]

why blank a half a gig?

No idea if Tails sets up an efi partition or has a multi-partition layout etc.

That seemed like a big enough guess to clobber any of that and is still well short of what has been overwritten anyway ... maybe just 2048 sectors would do, or maybe it doesn't help anyway.
But if it's blank, testdisk won't have the tails install as one of the things it's offering to fix/recover.

@OP - I'm really just guessing based on my past (fairly limited but mostly successful in appropriate circumstances) uses of testdisk - please do your own research before taking any of my advice

[v&n]

You might also want to try blanking the start of the disk (with 'dd if=/dev/zero of=/dev/sd<whatever> bs=1M count=512') or such.

But be extra careful to specify the correct "whatever"

I would replace 'extra' with 'extreme', as that was the starting point of the mess we are dealing with here.

Also, just to emphasize, do whatever you have to on the 'image', nothing on the physical drive unless you plan to preserve the image in its original form.

[I messed up bad]

Lads im stuck and hopefully get a quick answer whike I have access to the hardware (meanwhile im looking for answer)

Ive made a *.img and need to mount it such that it is selectable by testdisk!

Ive tried using furius iso mount which mounts it, but not such that testdisk lists it as a selectable media

[dilberts_left_nut]

https://www.cgsecurity.org/wiki/TestDisk_FAQ

[I messed up bad]

Its mounted in a folder in my home

[dilberts_left_nut]

Tried just adding the path to the image.as an argument to testdisk?

https://www.cgsecurity.org/wiki/Media_Image

[I messed up bad]

Thanks I found the answer there.

Here goes!

Im not using the beta because I had trouble compiling with:
./configure