Recover NTFS file system from a RAID 1 ATA disk

[kent.mehr]

I had a RAID 1 system which has failed. I don't want to buy new RAID
hardware so my problem is to recover my files from the harddisk.
I have tried by means of FindPart where all seemed to work fine apart
from the fact that all the files copied have a non valid format. I
simply cannot open the JPG files in the photo viewer (ACDSee).

the output from FindPart 1 is:

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

OS: Windows 5.1.2600 Service Pack 2

Disk: 1 Cylinders: 4111 Heads: 255 Sectors: 63 MB: 32247

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 07 63160826652 78528 0 1 110010 254 63 B OK?

Partitions according to partition tables on first harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*07 63160826652 78528 0 1 110010*254 63 OK OK?

No FATs found.

Using FIndPart FindNTFS 1 copy *.jpg
gives me a folder full of known files. However, they are all defective.


Any hints ?

Regards
Kent

 

[Arno Wagner]

I had a RAID 1 system which has failed. I don't want to buy new RAID
hardware so my problem is to recover my files from the harddisk.
I have tried by means of FindPart where all seemed to work fine apart
from the fact that all the files copied have a non valid format. I
simply cannot open the JPG files in the photo viewer (ACDSee).

the output from FindPart 1 is:

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

OS: Windows 5.1.2600 Service Pack 2

Disk: 1 Cylinders: 4111 Heads: 255 Sectors: 63 MB: 32247

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 07 63160826652 78528 0 1 110010 254 63 B OK?

Partitions according to partition tables on first harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*07 63160826652 78528 0 1 110010*254 63 OK OK?

No FATs found.

Using FIndPart FindNTFS 1 copy *.jpg
gives me a folder full of known files. However, they are all defective.

Any hints ?

Very strange. If the filenames are correct, then obviously
the partition was identified correctly and the files should be
addressed correctly as well, since cluster numbers should be
relative to the partition start. Or does NTFS do this differently?

Is it possible that you actually have format problem? There are some
newer JPG formats older viewers cannot display. Could ACDSee open
these files before?

Arno

 

[Svend Olaf Mikkelsen]

I had a RAID 1 system which has failed. I don't want to buy new RAID
hardware so my problem is to recover my files from the harddisk.
I have tried by means of FindPart where all seemed to work fine apart
from the fact that all the files copied have a non valid format. I
simply cannot open the JPG files in the photo viewer (ACDSee).

the output from FindPart 1 is:

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

OS: Windows 5.1.2600 Service Pack 2

Disk: 1 Cylinders: 4111 Heads: 255 Sectors: 63 MB: 32247

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 07 63160826652 78528 0 1 110010 254 63 B OK?

Partitions according to partition tables on first harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*07 63160826652 78528 0 1 110010*254 63 OK OK?

No FATs found.

Using FIndPart FindNTFS 1 copy *.jpg
gives me a folder full of known files. However, they are all defective.


Any hints ?

Regards
Kent

The findpart command to attempt to copy jpg files from this partition
is:

findpart findntfs 1 0 1 1 copy *.jpg

This is disk 1, cylinder, head, sector 0 1 1. Typically if the
location is not correct, file content will be wrong.


There is a disk size issue. The disk is reported as 32 GB, and
probably sectors after 32 GB cannot be read. Findpart by default will
not attempt to read after reported disk size.

It can be a wrong jumper setting, or the disk was set to 32 GB size
using software.

 

[kent.mehr]

There seems to be a disagreement between how the disk seems to be
manufactored and
the way it's seen by the system.
The disk is an IBM Deskstar with the folloowing values on the label:
Capacity: 41.0 GB LBA: 80418240 CHS: 16383/16/63

Originally I got the following response from FindPart:

=====Findpart, version 4.81 - for Windows 95/98/ME/NT/2000/XP.
=====Copyright Svend Olaf Mikkelsen, 1999-2006.
=====
=====OS: Windows 5.1.2600 Service Pack 2
=====
=====Disk: 1 Cylinders: 4111 Heads: 255 Sectors: 63 MB: 32247
=====
=====-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
===== 0 - 07 63160826652 78528 0 1 110010 254 63 B
OK?
=====
=====Partitions according to partition tables on first harddisk:
=====
=====-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
===== 0 1*07 63160826652 78528 0 1 110010*254 63 OK
OK?
=====
=====No FATs found.


I used the edit mode and corrected the partition table according to the

disk geometry and got the following output

=====Findpart, version 4.81 - for Windows 95/98/ME/NT/2000/XP.
=====Copyright Svend Olaf Mikkelsen, 1999-2006.
=====
=====OS: Windows 5.1.2600 Service Pack 2
=====
=====Disk: 1 Cylinders: 4111 Heads: 255 Sectors: 63 MB: 32247
=====
=====-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
===== 0 - 07 63160826652 78528 0 1 110010 254 63 B
OK?
=====
=====No FATs found.
=====
=====Partitions according to partition tables on first harddisk:
=====
=====-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
===== 0 1*07 63 66043152 32247 0 1 1 4110*254 63 NB OK

Then I looked for file records by means of

findpart findfile 1 mft fp-a.txt

and got:

=====Findfile, version FP 4.81.
=====Copyright Svend Olaf Mikkelsen, 2006.
=====
=====Searches for file records and index records. The T field
=====contains F for file records, D for directory file records,
=====or I for index records. Index records do not contain
=====information about file locations.
=====
=====OS: Windows 5.1.2600 Service Pack 2
=====
=====Disk: 1 Cylinders: 4111 Heads: 255 Sectors: 63 MB: 32247
=====
=====Mft
=====
=====Start cylinder: 0 End cylinder: 4110 Index records not shown.
=====
=====--------- CHS ----- LBA T -Record Cluster Name
===== 0 1 1 63 Boot or backup
===== Sectors per cluster: 1
===== MFT cluster: 16
===== MFT mirror cluster: 20103355
===== Partition sectors: 160826652
===== Possible MFT CHS: 0 1 17
===== Possible Mirror: 1251 96 56
===== 0 1 17 79 F 0 16 $MFT
===== Size: 149258240
===== Allocated: 149258240
===== Fragments: 2
===== Clusters: 291520
===== Cluster KB: 0.5
===== Boot CHS: 0 1 1
===== Offset MB: 0
===== Time: 2002-01-03 13:55:19
===== Access: 2006-09-06 10:08:15
===== 0 1 19 81 F 1 20103355 $MFTMirr
===== Size: 4096
===== Allocated: 4096
===== Fragments: 1
===== Clusters: 8
===== Cluster KB: 0.5
===== Time: 2002-01-03 13:55:19
===== 2500 111 22 40169514 Boot or backup
===== Sectors per cluster: 1
===== MFT cluster: 16
===== MFT mirror cluster: 20103355
===== Partition sectors: 160826652
===== 2735 15 34 43938753 F 0 16 $MFT
===== Size: 96620544
===== Allocated: 96620544
===== Fragments: 2
===== Clusters: 188712
===== Cluster KB: 0.5
===== Possible Boot CHS: 2735 15 18
===== Time: 2002-01-03 13:55:19
===== 2735 15 36 43938755 F 1 20103355 $MFTMirr
===== Size: 4096
===== Allocated: 4096
===== Fragments: 1
===== Clusters: 8
===== Cluster KB: 0.5
===== Boot CHS: 1483 174 42
===== Offset MB: 9816
===== Time: 2002-01-03 13:55:19
=====Finished.

 

[Svend Olaf Mikkelsen]

There seems to be a disagreement between how the disk seems to be
manufactored and
the way it's seen by the system.
The disk is an IBM Deskstar with the folloowing values on the label:
Capacity: 41.0 GB LBA: 80418240 CHS: 16383/16/63

If we now assume that this is one disk in a 2 disk stripe set, the
size in MB (MiB) would be 2*80418240/2/1024 = 78533 MB. From the
Findpart output we have that the boot sector partition size is 78528
MB. If that is true, you will need both disks in order to be able to
copy files correctly using Findpart.

The disk however also could be first disk in a span of 2 disks.

Originally I got the following response from FindPart:

=====Findpart, version 4.81 - for Windows 95/98/ME/NT/2000/XP.
=====Copyright Svend Olaf Mikkelsen, 1999-2006.
=====
=====OS: Windows 5.1.2600 Service Pack 2
=====
=====Disk: 1 Cylinders: 4111 Heads: 255 Sectors: 63 MB: 32247
=====
=====-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
===== 0 - 07 63160826652 78528 0 1 110010 254 63 B
OK?
=====
=====Partitions according to partition tables on first harddisk:
=====
=====-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
===== 0 1*07 63160826652 78528 0 1 110010*254 63 OK
OK?
=====
=====No FATs found.


I used the edit mode and corrected the partition table according to the

disk geometry and got the following output

=====Findpart, version 4.81 - for Windows 95/98/ME/NT/2000/XP.
=====Copyright Svend Olaf Mikkelsen, 1999-2006.
=====
=====OS: Windows 5.1.2600 Service Pack 2
=====
=====Disk: 1 Cylinders: 4111 Heads: 255 Sectors: 63 MB: 32247
=====
=====-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
===== 0 - 07 63160826652 78528 0 1 110010 254 63 B
OK?
=====
=====No FATs found.
=====
=====Partitions according to partition tables on first harddisk:
=====
=====-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
===== 0 1*07 63 66043152 32247 0 1 1 4110*254 63 NB OK

In stead of doing that edit, it would be better to hide the partition,
so the operating system will not attempt to access the partition. For
Windows XP, that can be done by changing the ID to hex 17.

Then I looked for file records by means of

findpart findfile 1 mft fp-a.txt

and got:

=====Findfile, version FP 4.81.
=====Copyright Svend Olaf Mikkelsen, 2006.
=====
=====Searches for file records and index records. The T field
=====contains F for file records, D for directory file records,
=====or I for index records. Index records do not contain
=====information about file locations.
=====
=====OS: Windows 5.1.2600 Service Pack 2
=====
=====Disk: 1 Cylinders: 4111 Heads: 255 Sectors: 63 MB: 32247
=====
=====Mft
=====
=====Start cylinder: 0 End cylinder: 4110 Index records not shown.
=====
=====--------- CHS ----- LBA T -Record Cluster Name
===== 0 1 1 63 Boot or backup
===== Sectors per cluster: 1
===== MFT cluster: 16
===== MFT mirror cluster: 20103355
===== Partition sectors: 160826652
===== Possible MFT CHS: 0 1 17
===== Possible Mirror: 1251 96 56

The boot sector for the 78528 MB NTFS partition.

===== 0 1 17 79 F 0 16 $MFT
===== Size: 149258240
===== Allocated: 149258240
===== Fragments: 2
===== Clusters: 291520
===== Cluster KB: 0.5
===== Boot CHS: 0 1 1
===== Offset MB: 0
===== Time: 2002-01-03 13:55:19
===== Access: 2006-09-06 10:08:15

This is sector number 79 numbered from 0. If this was a stripe set
with 32 KB stripe size, the sector would not be at that location.
Stripe size 64 KB would be possible.

===== 0 1 19 81 F 1 20103355 $MFTMirr
===== Size: 4096
===== Allocated: 4096
===== Fragments: 1
===== Clusters: 8
===== Cluster KB: 0.5
===== Time: 2002-01-03 13:55:19
===== 2500 111 22 40169514 Boot or backup
===== Sectors per cluster: 1
===== MFT cluster: 16
===== MFT mirror cluster: 20103355
===== Partition sectors: 160826652
===== 2735 15 34 43938753 F 0 16 $MFT
===== Size: 96620544
===== Allocated: 96620544
===== Fragments: 2
===== Clusters: 188712
===== Cluster KB: 0.5
===== Possible Boot CHS: 2735 15 18
===== Time: 2002-01-03 13:55:19
===== 2735 15 36 43938755 F 1 20103355 $MFTMirr
===== Size: 4096
===== Allocated: 4096
===== Fragments: 1
===== Clusters: 8
===== Cluster KB: 0.5
===== Boot CHS: 1483 174 42
===== Offset MB: 9816
===== Time: 2002-01-03 13:55:19

Previously we had:

===== Possible Mirror: 1251 96 56

===== Size: 149258240
===== Time: 2002-01-03 13:55:19

As far as I can see right now, the finding at cylinder 2735 is not a
current part of the file system.

=====Finished.

No NTFS backup boot sector was found at the end of the disk, but that
matches that the full disk size is not seen. Also the backup boot
sector may be on the possible other disk of a disk set.


I recommend that you hide the partition.

And then explain about the possible other disk.

And further consider the disk size issue. This disk should be seen as
about 40 GB. It can be a wrong jumper setting, or the disk size was
set using software. Hitachi Feature Tool can be used for setting the
disk size, if the size is not set using jumpers.

 

[kent.mehr]

Thanks for the many hints.
I tried to run the Hitachi utility. However, it identified 66055248 as
the LBA of the disk.
This number is significantly lower that the 80418240 reported on the
disk label.
I also tried to hide the disk by setting the type to 17.
The disk has been mounted together with a similar one as a mirror RAID
1. However, if it should
turn out that it has been mounted as a stripe RAID 0 would it than be
possible to recover files
WITHOUT the RAID interface?

Well, I tried again

findntfs 1 0 1 1 summary partlogs1.txt

and I got this logfile

===== FindNTFS, version 2.05 - for Windows 95/98/ME/NT/2000/XP.
===== Copyright Svend Olaf Mikkelsen, 2006.
=====
===== OS: Windows 5.1.2600 Service Pack 2
=====
===== Disk: 1 Cylinders: 4111 Heads: 255 Sectors: 63 MB: 32247
=====
===== CHS 0/1/1 LBA: 63
=====
===== Directories: 2148
===== Files: 22345
===== Trees: 1731
===== Adjusted: 2295
===== Exe/dll files: 2903
===== Exe/dll files signature: 1
===== Not referenced files: 20644
===== Cluster KB: 0.5

===== MFT cluster no: 16

===== MFT size: 149258240

===== MFT cluster bytes: 512

===== Listed files MB: 5031



Thereafter I tried



findntfs 1 0 1 1 copy *.jpg



and I got a large number of *.jpg files.

The files are wrong. I happen to have backup of a few of the files.

The recovered files have the right size, name and timestamp.

Comparing the files in a binary editor shows that they have exactly the
same size but all

the bytes have wrong values.

This suggests that the directories are intact but are biased so that
wrong sectors are found.

 

[Svend Olaf Mikkelsen]

Thanks for the many hints.
I tried to run the Hitachi utility. However, it identified 66055248 as
the LBA of the disk.
This number is significantly lower that the 80418240 reported on the
disk label.
I also tried to hide the disk by setting the type to 17.
The disk has been mounted together with a similar one as a mirror RAID
1. However, if it should
turn out that it has been mounted as a stripe RAID 0 would it than be
possible to recover files
WITHOUT the RAID interface?

Did you succeed in changing the ID to hex 17?

Where is the other disk? Is it currently in the system?

If as example the disks are 1 and 2 to Findpart, and the stripe size
is 64 KB, the findpart command to attempt to copy jpg files is:


findpart findntfs R126 0 1 1 copy *.jpg


The 1 and 2 are the disk numbers in correct order, and the 6 is for
stripe size 2^6 = 64 KB.


It may be possible to copy files even if the disk size issue is not
solved, for data located lower than 32 GB.

 

[Arno Wagner]

Thanks for the many hints.
I tried to run the Hitachi utility. However, it identified 66055248 as
the LBA of the disk.
This number is significantly lower that the 80418240 reported on the
disk label.
I also tried to hide the disk by setting the type to 17.
The disk has been mounted together with a similar one as a mirror RAID
1. However, if it should
turn out that it has been mounted as a stripe RAID 0 would it than be
possible to recover files
WITHOUT the RAID interface?

Well, I tried again

findntfs 1 0 1 1 summary partlogs1.txt

and I got this logfile

===== FindNTFS, version 2.05 - for Windows 95/98/ME/NT/2000/XP.
===== Copyright Svend Olaf Mikkelsen, 2006.
=====
===== OS: Windows 5.1.2600 Service Pack 2
=====
===== Disk: 1 Cylinders: 4111 Heads: 255 Sectors: 63 MB: 32247
=====
===== CHS 0/1/1 LBA: 63
=====
===== Directories: 2148
===== Files: 22345
===== Trees: 1731
===== Adjusted: 2295
===== Exe/dll files: 2903
===== Exe/dll files signature: 1
===== Not referenced files: 20644
===== Cluster KB: 0.5

===== MFT cluster no: 16

===== MFT size: 149258240

===== MFT cluster bytes: 512

===== Listed files MB: 5031


Thereafter I tried


findntfs 1 0 1 1 copy *.jpg


and I got a large number of *.jpg files.

The files are wrong. I happen to have backup of a few of the files.

The recovered files have the right size, name and timestamp.

Comparing the files in a binary editor shows that they have exactly the
same size but all

the bytes have wrong values.

This suggests that the directories are intact but are biased so that
wrong sectors are found.

Agreed.

Arno

 

[kent.mehr]

Yes, I succeeded in changing the ID to 17

I still have a few open questions:

1) the disk label says: Capacity: 41.0 GB LBA: 80418240 CHS:
16383/16/63
80418240*512=41174138880 whish is 38.2 GB (or as stated 41 GB). How
comes
that both Hitachi Tools and FastFind say there are 32247 MB which
means
LBA = 66043152 . Where have all the 14375088 sectors gone ? There
can't
be that many bad sectors ;-(

2) How does LBA: 80418240 related to CHS: 16383/16/63 ?

3) FindNTFS finds all the *jpg files. It finds the name, time stamp and
size.
however, it recovers wrong bytes from the disk. Assuming the disk
should
be part of a stripe (RAID 0) shouldn't FindNTFS complain if it's
requested
to look for sectors off the range instead of retrieving invalid
values ? Should the
disk really be so highly fragmented that all files spread over 70
GB ?

 

[kent.mehr]

PS. I forgot to tell that I retrieved a folder full of VISIBLE thumb
nail versions of the *.jpg files.
Would this indicate that an alternative data stream within the
NTFS files is sturbing
FindNTFS in a way so that only the thumb nail is found?

 

[Svend Olaf Mikkelsen]

PS. I forgot to tell that I retrieved a folder full of VISIBLE thumb
nail versions of the *.jpg files.
Would this indicate that an alternative data stream within the
NTFS files is sturbing
FindNTFS in a way so that only the thumb nail is found?

We have to focus on what may be the most important: Where is the other
disk in the possible stripe set?

If the second disk is in the system, you can do:

findpart tables fp-a.txt

 

[kent.mehr]

Well,
the problem is that believing the disks to be RAID 1 (mirror) I have
only brought disk 1 along as disk 2 could serve as backup. At present
I'm some 1500 km from the disk 2 so I think the case might pause for
a couple of weeks until I'm back to disk 2 ;-(

 

[Svend Olaf Mikkelsen]

Well,
the problem is that believing the disks to be RAID 1 (mirror) I have
only brought disk 1 along as disk 2 could serve as backup. At present
I'm some 1500 km from the disk 2 so I think the case might pause for
a couple of weeks until I'm back to disk 2 ;-(

To help figure out if this is a stripe set, you can do:


findpart findntfs 1 0 1 1 summary fp-b.txt check

findpart findntfs R116 0 1 1 summary fp-c.txt check


The idea is that if the disk is part of a 64 KB stripe set, the second
command will find more matching file signatures than the first
command.

This can be done with one disk alone.

To further examine the disk size issue, you can do using Findpart for
DOS:

findpart ide fp-d.txt

and if the disk is primary master:

set findpart=edit
findpart setsize pm native expert nonvolatile
findpart ide fp-e.txt

And explain the jumper setting of the disk, the locations of the
jumpers on the pins, not what the disk is set to.

 

[Folkert Rienstra]

Still trying to get an answer out of Svend? Good luck.

Btw, nice post.

 

[Folkert Rienstra]

There seems to be a disagreement between how the disk seems to be
manufactored and the way it's seen by the system.

There isn't. The systen sees it as 80418240,
not 16383/16/63 and not 4111/255/63 either.

16383/16/63 (8GB) is the maximum addressable space using physical CHS addressing, so the disk label is correct.

4111/255/63 is merely a theoretical logical CHS representation
of the LBA capacity by Findpart. It doesn't exist anywhere else.

As for your drives being 41 GB, they were probably shortstroked
to 32GB.

The disk is an IBM Deskstar with the folloowing values on the label:
Capacity: 41.0 GB LBA: 80418240 CHS: 16383/16/63

Originally I got the following response from FindPart:

=====Findpart, version 4.81 - for Windows 95/98/ME/NT/2000/XP.
=====Copyright Svend Olaf Mikkelsen, 1999-2006.
=====
=====OS: Windows 5.1.2600 Service Pack 2
=====
=====Disk: 1 Cylinders: 4111 Heads: 255 Sectors: 63 MB: 32247
=====

[snip]

 

[kent.mehr]

Now I got hold of the other disk and the RAID comtroller.
The RAID controller is an Iwill SIDE-RAID 100.
In contrast to what first believed it seems as the motherboard of the
PC is defective and not the RAID controller.
I've now installed the RAID controller on another PC and connected the
disks in the hope to see all my files again. However, there is now a
problem caused by the previous exercises. The FAT has been modified by
means of findpart and I would like to modify it back to the origin so
it reads:


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

OS: Windows 5.1.2600 Service Pack 2

Disk: 1 Cylinders: 5005 Heads: 255 Sectors: 63 MB: 39260

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 07 63160826652 78528 0 1 110010 254 63 B OK?

No FATs found.

Partitions according to partition tables on first harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 07 63160826652 78528 0 1 110010 254 63 B OK?

However, the partition editor does not allow me. It says wrong
cylinders.

 

[Svend Olaf Mikkelsen]

Now I got hold of the other disk and the RAID comtroller.
The RAID controller is an Iwill SIDE-RAID 100.
In contrast to what first believed it seems as the motherboard of the
PC is defective and not the RAID controller.
I've now installed the RAID controller on another PC and connected the
disks in the hope to see all my files again. However, there is now a
problem caused by the previous exercises. The FAT has been modified by
means of findpart and I would like to modify it back to the origin so
it reads:


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

OS: Windows 5.1.2600 Service Pack 2

Disk: 1 Cylinders: 5005 Heads: 255 Sectors: 63 MB: 39260

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 07 63160826652 78528 0 1 110010 254 63 B OK?

No FATs found.

Partitions according to partition tables on first harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 07 63160826652 78528 0 1 110010 254 63 B OK?

However, the partition editor does not allow me. It says wrong
cylinders.

(This is not actual Findpart output, but edited).


Previously we had:

"Yes, I succeeded in changing the ID to 17"

Keep it that way.

You need to see a single about 78528 MB disk, or two about 39260 MB
disks.

My evaluation is that the most reliable method is to get the two disks
seen as single disks in a working system, with room on other disks or
network for file copying attempts using Findpart.

Previously I suggested how to estimate the nature of the stripe set
using one disk, but since I do not know current disk numbers, I cannot
repeat it.

 

[kent.mehr]

I have now found the REAL cause for my trouble. The electronic
controller part of disk 2 is defective. Thus I'm only able to work with
one disk a time ( swapping the electronic print circuit between the
disks.) I have an extra 110 GB disk which would be able to carry both
disks.
I'm now seeing three possible solutions:

1) get another disk similar to the broken and substitute the circuit
card. This solution is difficult as the disks are off the market
already for some years.

2) clone the defective disk to another larger disk and use this larger
disk as disk 2 together with disk 1 on the RAID interface. But how ?

3) Merge disk one and disk two onto a larger third disk and see the
filesystem without the RAID interface. But how?

 

[Michael Daly]

2) clone the defective disk to another larger disk and use this larger
disk as disk 2 together with disk 1 on the RAID interface. But how ?

If you use two different size disks on a RAID 1 controller, the larger disk will
appear to be the same size as the smaller. You'll lose the extra capacity, but
since you appear to have a 60GB drive and the smallest easily available are now
80GB, you'll only lose about 20GB - at today's prices, that's not a lot.

Mike

 

[kent.mehr]

I decided to make a "clean" test without disturbing my valuable data in
order to find out where things go wrong.
Thus, I connected two disks to an Iwill RAID interface and created a
stripe with stripe size 64k.
The disks are:
1) Maxtor model 53073U6 of 30 GB
2) Seagate Barracuda ATA IV model ST320011A of 20GB

The system is running XP prof. SP2.

Hereafter I copied som 17 GB of stuff tpo the stripe. I unplugged the
disks from the Iwill interface and connected them to the IDE bus with
no jumper in the Maxtor disk (connected on the slave plug of the cable)
and the jumper in the position closest to the IDE cable of the Seagate
(connected on the master plug of the cable)

The machine was re-booted (system etc. is on SATA disks). Hereafter the
two ex-strip disks were seen as
disk 0 (the Seagate disk which was the second of the stripe)
disk1 (the Maxtor disk which was the first of the stripe)

I now started to operate Findpart as follows:

=== >findpart 1
===
=== Findpart, version 4.81 - for Windows 95/98/ME/NT/2000/XP.
=== Copyright Svend Olaf Mikkelsen, 1999-2006.
===
=== OS: Windows 5.1.2600 Service Pack 2
===
=== Disk: 1 Cylinders: 2434 Heads: 255 Sectors: 63 MB: 19092
===
=== -PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
=== 0 - 07 63 39086082 19085 0 1 1 2432 254 63 BU OK
===
=== No FATs found.
===
=== Partitions according to partition tables on first harddisk:
===
=== No signature CHS: 0 0 1
===
===
=== This was the first disk in the stripe
===
=== >findpart 2
===
=== Findpart, version 4.81 - for Windows 95/98/ME/NT/2000/XP.
=== Copyright Svend Olaf Mikkelsen, 1999-2006.
===
=== OS: Windows 5.1.2600 Service Pack 2
===
=== Disk: 2 Cylinders: 3736 Heads: 255 Sectors: 63 MB: 29306
===
=== -PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
=== 0 - 07 63 78188292 38177 0 1 1 4866 254 63 B OK?
=== Fdisk F6 sector 2475 0 1
=== Fdisk F6 sector 2475 1 1
=== 0 - 07 63 60002712 29298 0 1 1 3734 254 63 BU OK
===
=== -----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
=== 0 1 33 Second FAT not found.
===
=== -----FAT CHS ------LBA Confidence Distance Type Sig
=== 0 1 33 95 139 32 OK
===
=== Partitions according to partition tables on second harddisk:
===
=== -PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
=== 0 1 07 63 78188292 38177 0 1 1 4866*254 63 OK OK?

===
=== here I try to recover my photo files
=== >findpart findntfs R216 0 1 1 copy *.jpg
===
=== 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 2
===
=== Disk: R216 Cylinders: 4868 Heads: 255 Sectors: 63 MB: 38185
===
=== CHS 0/1/1 LBA: 63
===
=== Copy
===
=== Searching ... ........
=== ...
=== ...
=== 1999-09-21 08:38:42 1529 00000020 template_text.htm
=== 1999-09-07 08:29:36 1565 00000020 Windflow analysis.htm
=== 2007-01-11 12:17:51 10992 00000020 change.log
=== 1999-09-15 16:03:08 14588 00000020 grtblt990501_4.jpg
Saved
=== 1999-09-07 15:06:26 65530 00000020 rotationvstime01.jpg
Saved
=== 1999-09-08 10:50:54 64338 00000020 rotationvstime02.jpg
Saved
=== 1999-09-08 15:16:48 44954 00000020 rotationvstime03.jpg
Saved
=== 1999-09-17 08:48:07 32655 00000020 SS_Bridge00.gif
=== ...
=== ...
=== Directories: 3483
=== Files: 39106
=== Trees: 2097
=== Adjusted: 7037
=== Exe/dll files: 2284
=== Exe/dll files signature: 1111
=== Not referenced files: 25534
=== Copied files: 2624
=== Cluster KB: 4
=== MFT cluster no: 786432
=== MFT size: 43204608
=== MFT cluster bytes: 4096
=== Listed files MB: 13857

Hereafter I had all my photos in the local directory. However, the were
not readable. Only a few small ones could be seen.

Any hints ?

Regards
Kent