Recover NTFS file system from a RAID 1 ATA disk

  • Thread starter Thread starter kent.mehr
  • Start date Start date
Well, I finally used the control circuit of disk 1 on disk 2. I cloned
disk 2 by means of 'dd if=/dev/hda of=/dev/hdb' on a LINUX machine.
Thereafter I re-installed the control circuit on disk 1 and connected
disk 1 and the clone to the RAID inteface. I was able to recover all my
data. The only part which was lost because of bad functionallity of
disk 2 was the WINDOWS path.

In addition I learned that lots of time can be lost by applying poorly
functioning freeware. The FINDPART did obviously NOT work on a well
defined test bench. However, I must admit that FINDPART helped me to
understand that the disk array was defined as a STRIPE and not as a
MIRROR. (this could also have been seen by means of fdisk in LINUX)
 
Well, I finally used the control circuit of disk 1 on disk 2. I cloned
disk 2 by means of 'dd if=/dev/hda of=/dev/hdb' on a LINUX machine.
Thereafter I re-installed the control circuit on disk 1 and connected
disk 1 and the clone to the RAID inteface. I was able to recover all my
data. The only part which was lost because of bad functionallity of
disk 2 was the WINDOWS path.

In addition I learned that lots of time can be lost by applying poorly
functioning freeware. The FINDPART did obviously NOT work on a well
defined test bench. However, I must admit that FINDPART helped me to
understand that the disk array was defined as a STRIPE and not as a
MIRROR. (this could also have been seen by means of fdisk in LINUX)
Click to expand...

What the user did in his test case was to create, not a 64 KB stripe
size, but a 128 KB stripe size.

It was seen that there were exe/dll file signature match for about
half of the exe/dll files. This means that the stripe size must have
been 32 KB or 128 KB, since for these sizes, half of the sectors in
the stripe set are in the same locations as with 64 KB stripe size.

It however cannot have been 32 KB stripe size, since in that case the
second half of the master file table file record (first 1024 bytes of
cluster 786432) would have been on another location than with 64 KB
stripe size.

For comparison I have for a two disk stripe set with 128 KB stripe
size:

FindNTFS, version FP 4.81 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 2006.

OS: Windows 5.1.2600 Service Pack 1

Disk: R326 Cylinders: 4868 Heads: 255 Sectors: 63 MB: 38185

CHS 0/1/1 LBA: 63

Directories: 529
Files: 9098
Trees: 280
Adjusted: 1203
Exe/dll files: 1606
Exe/dll files signature: 784
Not referenced files: 6655
Cluster KB: 4
MFT cluster no: 786432
MFT size: 10858496
MFT cluster bytes: 4096
Listed files MB: 732


And with the correct Findpart parameters for a 128 KB stripe set:


FindNTFS, version FP 4.81 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 2006.

OS: Windows 5.1.2600 Service Pack 1

Disk: R327 Cylinders: 4868 Heads: 255 Sectors: 63 MB: 38185

CHS 0/1/1 LBA: 63

Directories: 522
Files: 6250
Trees: 1
Exe/dll files: 1535
Exe/dll files signature: 1505
Cluster KB: 4
MFT cluster no: 786432
MFT size: 10858496
MFT cluster bytes: 4096
Listed files MB: 640


In the first example, we see an exe/dll signature match for about half
of the files and 280 trees, while in the second example there is a
close exe/dll match and 1 tree. It is normal in a Windows installation
that not all exe/dll files have a signature.
 
Back
Top