How to clone Windows on filelevel

I've an old laptop (WinXP) which I wanted to clone via Linux's dd (Ubuntu live CD) onto a second HDD. Unfortunately dd fails due to read I/O errors. The Windows Installation itself is still able to read all files from its drive, so I think NTFS marked some sectors as unusable. That's why I want to clone the installation on a file level. At first I dd'ed the MBR to the second HDD, so the partition layout is the same on source and destination HDD. The next step was to clone the actual files. I connected the two HDD's to a thirdparty Windows machine (Windows 7) and used robocopy to clone the files including the permissions:

ROBOCOPY E:\ F:\ /e /efsraw /copyall /dcopy:t /r:0

So even as I ran the commandline for robocopy "as Administrator", some directories gave me "Access denied", e.g. the users %appdata%. Is there a way to ship around this problem? I don't want to mess with the permissions on the source volume, so how can I copy the user profiles correctly?

Current state is, that the file-cloned Windows installation boots, but the user profiles are missing data.

Oliver R.

Posted 2015-11-23T14:55:32.230

Reputation: 188

What about dd conv=noerror? – Run CMD – 2015-11-23T15:00:04.967

@ClassStacker - That should be dd noerror ... (omit conv=), but it is a good suggestion. What I don't know is how dd handles read errors: does it write an empty buffer, or does it skip writing? I can't easily test which, but it would need to work in the first way for the copy to be useful. – AFH – 2015-11-23T15:15:09.030

It will pad with zeroes. See here. Everything else would be pretty useless for an image processing tool? Actually, it should be dd conv=noerror,sync according to that link. Sorry for the mistake.

– Run CMD – 2015-11-23T15:22:26.007

I tried this "noerror" statement as well, but it was not successful. dd only produced errors at and after the 1.4GB mark and was not able to read anything more beyond. To use the hdd again, I have to replug it. Please see my comment under the answer to this question. – Oliver R. – 2015-11-25T09:34:51.280

Answers

You should stick to the block-level copy, but use a fault-tolerant tool like ddrescue - this will just write zeroes for unreadable block and move on.

I have quite successfully rescued a lot of Windows installations from failing HDDs with this method.

Eugen Rieck

Posted 2015-11-23T14:55:32.230

Reputation: 15 128

1-1 He said file copy. If you want to suggest byte by byte copy, you're not answering the question, and you could ask him in comment why he says file copy(though he has already been asked in comment). – barlop – 2015-11-23T15:14:05.583

1@barlop - he did actually say, that he had to fall back to file level copying, because the block-level copy wouldn't work. – Eugen Rieck – 2015-11-23T15:15:21.657

1ok fine.. BTW I agree ddrescue is a good idea. I have used ddrescue it's pretty good.. it shows progress which dd doesn't. – barlop – 2015-11-23T15:16:14.777

Thank you for the hint to ddrescue I was not aware of that tool! Using this I was able to copy the HDD. At the beginning ddrescue ran into the same issue as a clean dd dit (also even with "conv=noerror"): As soon as both tools reached the 1,4GB mark, they do not copy even a single byte from the disk. But thanks to the transaction log of ddrescue I was able to interrupt the process, replug the hdd and it starts automatically after the faulty section. – Oliver R. – 2015-11-25T09:32:59.027

I did a copy of old HDD (HDD was made approximately in 2007) and then restored HDD from this copy using software "Acronis True Image". You can use a trial version of this software.

Schullz

Posted 2015-11-23T14:55:32.230

Reputation: 169

A trial version of Acronis won't result in a bootale system installation on dissimilar hardware. – Ramhound – 2015-11-23T15:08:49.590

1@Ramhound it wasn't mentioned in a question that installation on dissimilar hardware is the goal. – Schullz – 2015-11-23T15:10:55.097

2AT Ramhound You write "A trial version of Acronis won't result in a bootale system installation on dissimilar hardware. " <-- A file copy which is what the OP asks about, is also not going to work on different hardware, unless perhaps certain preparations are done beforehand. – barlop – 2015-11-23T15:11:31.443

@barlop - I presume by the fact he connected it to a "third party Windows machine" that was an end goal. – Ramhound – 2015-11-23T15:13:47.340