Rescuing NTFS data with live CDs -- cautionary tale

By sheer coincidence I was asked five times last week by windows users to rescue their NTFS data from hard drives.

Preprocessing in windows:

  • Where possible I boot their computer with an XP installation CD and run “chkdsk X: /p” in the rescue mode to correct any filesystem errors before I rescue the data using Linux.
  • If I can’t do that I try to attach the drive in a USB cradle to a working NTFS computer and run "chkdsk X: /f "instead.

Don’t use a windows computer and copy/paste to rescue the NTFS data, it missed too many files and can have permissions hiccups. It can trick you into thinking the drive is damaged when it’s not, particularly if you didn’t run chkdsk first. You can use xcopy in windows 2000/xp (which is not so good in vista) but Linux is much easier IMO.

Next use Linux
Where possible I boot their computer with a live CD like Ubuntu or Partition Magic (don’t like the Suse live KDE CD much, too resource hungry, but Suse Gnome live is good). And if I can’t boot the computer I take out the hard drive and attach it via a USB cradle to my lappy running openSUSE 11.2 KDE which is great for rescuing data.

Then I use the GUI tools in Ubuntu / Parted Magic / Lappy openSUSE to mount the cranky NTFS drive. I also have a target USB drive to store the rescued data on and I attach that too and mount it. The driver is ntfs-3g and now a days that works by default pretty much without asking.

Then I use the good old cp command to rescue the data. Suppose there’s a folder on the ntfs drive that contains files you want e.g. /path_to/ntfs_folder and a target location for that folder and the contained files e.g. /path_to/target, then I use this command:

cp -a -u -v /path_to/ntfs_folder/. /path_to/target/

Cautions:

  • see the full stop at the end of …/ntfs_folder/. It’s real and I recommend you use it. It’s like an instruction to get hidden files too. I’ve run across some windows directories starting with a period and the full stop thingy seems to get those.
  • use Parted Magic as a last resort for cp because it throws up I/O errors and skips files
  • run the commands twice if you’re using a live CD, you’ll be surprised when a couple of extra files pop across that were missed by the Live CD, don’t know why.
  • best use of cp is in openSUSE fully installed in a computer, it never missed files. Perhaps there are memory restrictions with Live CDs, don’t know why or if really.

So you can use Linux with confidence and have grateful clients (or friends).

Nice one, John. I do things like this once in a while, never took the time to write something like this.

To avoid the .WINDOWS file problem, I use the ‘-r’ option to copy the files to the target folder, but that’s about all:


cp -r -v /path_to/ntfs_folder /path_to/target

-a includes -R :wink:

Don’t you actually mean:

cp -a -u -v /path_to/ntfs_folder/. /path_to/target/

?

Yes I do – half asleep I think. Edited / fixed, thanks.

Learned something: never too old to learn.

Knurpht wrote:
> Learned something: never too old to learn.

i’m getting there…but, luckily i’ve already learned all there is to
know, so . . . bring ON the age, i’m ready Teddy…


palladium

I have no experience in rescuing data … but just a curiosity.
cp -u
speeds up the process the second time you issue the command … but can rsync be useful too?
For example:

rsync -a -vv /path_to/ntfs_folder/ /path_to/target/

Or maybe rsync is less useful in a (maybe corrupted) windows filesystem?

TNX in advance.

Bye.

I really don’t know. I will try that out of curiosity, thanks for the suggestion.

I can give some input on liveCD dropping files. With Live CD you are using a compressed kernel dynamically expanded in memory instead of loading resources from HDD as needed. You have limited file cache available, and you have time lag as the programs are expanded and compacted again in memory. A newer system with lots of RAM will perform faster and with more efficiency than an older one. My solution was to do special build live CD with almost nothing in it and then test it on a system with challenged hardware resources against a normal live CD and the special build worked faster, and recovered virtually all files on just 2 passes including the hidden’s.

Very interesting techwiz03, thanks for the info.