GetDataBack not able to recover all files - can anything be done?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I have an issue with a WD external USB 2.0 drive I was using for
backups - the plug got yanked out and the contents of the drive
disappeared and the USB controller would no longer work.

I pulled the drive out and installed it as a SATA drive. XP recognizes
the drive but shows it as blank - no size indication, nuthin'. Using
GetDataBack I can recover some files but there are a number of files
of various types - audio, video, images, text - where GetDataBack
recognizes the name and type of file but they seem to be corrupted -
i.e. can't be viewed or what comes up is gibberish. No preview
available on .jpg files, "unable to play" messages on video files,
etc. While building the recovery tree, there were a number of "unknown
error" prompts that came up.

Can anything be done about these files or are they likely permanently


Re: GetDataBack not able to recover all files - can anything be done?

Quoted text here. Click to load it

A data recovery specialist could probably recover more than you can with the  
utils to hand - but even they might not recover all, and they're not cheap!

In the 16 bit days & before Peter Norton became Symantec, you probably could  
have sorted most of it out with Norton Utilities, I don't know what's any  
better than what you have nowadays.  

Re: GetDataBack not able to recover all files - can anything be done?

En el artículo <ef0caab4-fd6b-4f22-a6c4-7dd72134f022@p5g2000yqj.googlegr

Quoted text here. Click to load it

If anything can recover the files, TestDisk will.

it'll search for the partition table and offer to rewrite it.  Once
you've done that, your files should be visible and you can copy them off
in the normal way.

If you have allowed anything to write to the disk it will reduce the
chances of TestDisk succeeding.


Re: GetDataBack not able to recover all files - can anything be done?

Doc wrote:
Quoted text here. Click to load it

You haven't indicated whether the partitions are visible or not.

To gain access to the partitions again, you can use an application
like TestDisk. What it does, is re-compute what the MBR and primary
partition table should look like. A program like this should be used
with some care, because it can also find previously deleted partitions
and try and include them in the new partition table. Human judgment
must be used, before clicking any option to "Apply" a change.
(I had a disk with three partitions, where it tried to put back
a four partition table in the MBR. The fourth partition, was a
partition I'd deleted months ago. Two of the partition definitions
actually overlapped, which would have lead to a disaster if I'd
used that new MBR setup.) You can press control-C to get out of
this program, even if Quit is not an option on the screen. Test
that control-C works for you first, before going any further.

TestDisk also has a screen, where you can get it to list
the files at the top level of the disk. This lends confidence
that the file system is not damaged. It doesn't really have
any other practical usage.


If the partitions are visible, but the partition is corrupted,
then you might need some sort of data recovery program. Whether
the files can be recovered, might depend on how fragmented the
files are. It could be, that files which are contiguous on disk,
are easier to recover than files which are fragmented.

Before doing anything to a damaged disk, you always make a backup
of it. In this case, you would make a sector-by-sector copy. In
practice, that means you need *two* empty disks before starting
work. The first empty disk, takes the sector-by-sector backup.
(Sector-by-sector backups are preferred, because even if the file
system is scrambled, the sector-by-sector copy carefully copies
every detail. Nothing gets lost by doing that kind of backup.)

I use this freebie, for copying one disk to another, sector by sector.

The second empty disk, is the storage space for "recovered files".
If a recovery attempt that does "in-place" repairs fails (such
as running CHKDSK), then you restore from your first disk, the
one with the sector-by-sector backup on it. Always keep an
unadulterated copy of the original disk around, in case any
of the repair tools makes things worse. An example being, the
repair-in-place tool called CHKDSK.

Any tool which can use existing file system info, stands a
better chance at recovery, than a tool which "scrubs the disk
sector by sector, trying to rebuild files". When files are
contiguous and not fragmented, the scrubbing technique might
yield a good, loadable file. But using that method, you end
up with 20x as many files as you originally started with.
Which means most of the files you are evaluating, are
temporary files which have since been partially overwritten.
Normally, when you delete a file, the file system is lazy,
and doesn't rub out the old file with zeros or anything.
It means there is a large amount of "info", that a recovery
tool can find, info which is no longer relevant. A scrubber
tool, will recover both deleted and active files, and can't
tell the difference.

For example, say I use a Photo Editor. I edit my wedding
snapshot. I save intermediate copies of my edit, while
I'm working. Maybe there were ten intermediate files.
Only the last file is kept around. The others were deleted.
The file system reuses the space (eventually), but until
that happens, all those deleted files can be partially
recovered. And that's what things like a GetDataBack will
be filling the output disk with, is stuff that was
probably deleted and isn't a real file.

So all I can suggest, is use any tool which honors
the available file system metadata. Scrubbing the disk,
and ignoring all metadata, is your very last option. As
slogging through the recovered files, to find the actual
good and valid files, will take an eternity. CHKDSK is
an example of a tool which honors the metadata it finds,
at least if that metadata has some level of sanity to it.

In this example, you can see what kind of metadata the file
system has.

    $MFT         Master File Table
    $MFTMirr     Duplicate of the first vital entries of $MFT,
                 usually 4 entries (4 Kilobytes).

I'm guessing what that means is, there aren't two complete
copies of the MFT sitting there.

The hopeful part, when reading the following doc is, it's
highly unlikely that large parts of the disk are corrupted.
Only the last thing the file system was working on should
be corrupted. Meaning there should be a lot of info a
recovery routine can use to get the files back. If a
recovery program only uses the "scrubbing" method, of
looking for file headers sequentially, then that's doomed
to giving a poor quality output. Only a completely defragmented
disk would help there, and you're still faced with N copies
of intermediate files which are not real files.

This program helped at least one person, get their data off an
NTFS partition. The original site is gone. This backup site is
now gone.

OK, I still see a copy here. They didn't get all of them :-)   1,007,764 bytes
MD5SUM = 63b7e1e8b1701593d5f52c7927d01558

Good luck,

Re: GetDataBack not able to recover all files - can anything be done?

Paul wrote:
Quoted text here. Click to load it
Quoted text here. Click to load it
   That "dd" program looks nice, maybe even better than  
clonezilla-live-20121217-quantal.iso which displays a bunch of errors at  
startup and which also cannot copy to a smaller destination (eg: copy  
31GB from an 80GB drive to a 40GB drive).
   Is there a version that is a "stand-alone" like Clonezilla (as i have  
and use Win2K)?

Re: GetDataBack not able to recover all files - can anything be done?

Robert Baer wrote:

Quoted text here. Click to load it

It's just a simple port of "dd", and is not a replacement
of clonezilla or anything.

But it does give you access to all the crude block device
ops you could ever want.

You can severely screw up hard drive data with it, with
no trouble at all :-)

You can copy any sector and offset from one drive, to
any sector and offset on a second drive. Or, you can
image an entire drive, and store it as a file.

    dd if=\?\Device\Harddisk0\Partition0 of=Z:\wholedrive.bin

That would make a 500GB file, on my Z: drive :-)
And that is, since harddisk0 is a 500GB drive.
Z: would have to be NTFS to be able to "eat" a file that big.

I can also copy one drive to another. Here, I copy all
of Harddisk0 to Harddisk1. The copy stops, when either the
source or the dest, runs out of space. Obviously, the
destination had better be bigger than the source, for safety reasons.
If you knew for a fact, no critical info was stored near the
end of Harddisk0, you could take a chance copying to a smaller
drive. But that would be pretty dumb, most of the time.
(Only if the end of the drive had no partition located there,
would you take a chance on it. It's just easier to buy a
big enough drive for the destination.

    dd if=\?\Device\Harddisk0\Partition0 if=\?\Device\Harddisk1\Partition0

The "dd.exe" port will stop if it runs into a CRC error.
For severely damaged drives, drives throwing CRC errors
under normal circumstances, you should read the very
bottom paragraph here. Linux and ddrescue is what you use
in that case. You don't necessarily have to built it yourself,
as you can boot a Linux LiveCD, and use the package manager
(like Synaptic) to install the package in your current session
The "ddrescue" program can be used to do a two-pass copy.
The first pass, ignores the sectors showing CRc errors.
The second pass, tries to fill them in (like paving potholes).
Some log file, keeps track of how it's going. When the missing
sectors appear to be no longer accessible, you've done the
best you can with it (got as much data as is physically possible).


Re: GetDataBack not able to recover all files - can anything be done?

Quoted text here. Click to load it

That should be:

dd if=\.\Device\Harddisk0\Partition0 of=\.\Device\Harddisk1\Partition0
That will only copy the first partition and ignore any others.  

Personally, to clone one disk to another, I would do:

dd if=\.\PhysicalDrive0 of=\.\PhysicalDrive1

adding bs=1M at the end will speed things up.

Also, I think when dealing with raw disk devices, you should use \.\
instead of \?\

\?\ is for file I/O, \.\ is for device I/O.

"Win32 Device Namespaces
The '\.' prefix will access the Win32 device namespace instead of the
Win32 file namespace. This is how access to physical disks and volumes is
accomplished directly, without going through the file system"

Note the above article refers to "\.\PhysicalDiskN", which seems to be
incorrect, it should be "\.\PhysicalDriveN"


Re: GetDataBack not able to recover all files - can anything be done?

Mike Tomlinson wrote:
Quoted text here. Click to load it

Sorry about the typo. of= it is.

On the "dd" port, Partition0 refers to the whole disk.
Partition1 to PartitionN refer to individual partitions on the disk.
(That might be explained on the Chrysocome web page.)

The above syntax only applies to the Chrysocome port. YMMV.

For speedup, things are a bit complicated. The 4K disks use
different optimization than the 512 byte sector disks. On a
4K disk, bs=8192 might work OK. On a 512 byte disk, you can
use a larger transfer size (multiple of 512) and get some
improvement. So that's an area you can experiment with, to
see what works best with your gear. I initially thought that
"bigger was always better", but that's not always the case.

With no block size specified, you might see 13MB/sec transfer
rate, while with a block size specified you might see 39MB/sec.
(The difference being, the disk interface saturates once
the command rate gets to a certain level. Bigger blocks
gives fewer commands per second. The default transfer size of
one sector is just too small.) The numbers I quote there,
are just to give some idea what kind of difference that specifying
a block size can make.

Using the "factor.exe" program, you can factor the entire disk size,
work out both a block size and count, and use those as parameters.
For example, to transfer my WinXP partition (for safe-keeping), I use:

    dd if=\?\Device\Harddisk0\Partition2 of=winxp.dd bs=129024 count=604031

The output of factor.exe would look like this.
Factor makes it easier to work out some sizes.
77,934,495,744 is the size of my WinXP partition.

    factor 77934495744

    77934495744: 2 2 2 2 2 2 2 2 2 2 2 3 3 7 604031

In that example, WinXP is on the second partition of the disk, and the
block size of 129024 (252 sectors) is suited to an older disk. By
factoring the disk size, I'm ensuring the entire thing gets copied,
and no partial blocks are missed. You don't have to do it that way,
if for example, you know the end of the object you're copying, is
in fact empty. (Might happen if logical partition size is smaller
than physical partition size.)

For a copy of factor.exe, see the coreutils package.


Re: GetDataBack not able to recover all files - can anything be done?


Quoted text here. Click to load it

Noted, thanks. Typical M$ :-)


Site Timeline