Severe file system corruption 300 GB SAS case

[terminator2]

I have got a 300GB SAS disk from a malfunctioned server . In disk management it is showing unallocated space.
I have tried R-stdudio & UFS explorer (both trial) to scan the disk . But I think NTFS boot record is missing so though data is present file system reconstruction is not successful.
What should I try now ? Attached is first 10000 Sectors of the disk.
download link - https://drive.google.com/file/d/1KC2s6D ... sp=sharing

Attachments

[Arch Stanton]

It's almost as if 504 bytes/sector. All 55 AA signatures are 'off' by 8 sectors.

[Arch Stanton]

It's almost as if 504 bytes/sector. All 55 AA signatures are 'off' by 8 sectors.

*bytes. Off by 8 bytes.

[fzabkar]

If you patch the first 4 sectors, everything else lines up.

Edit: No it doesn't. Sorry.

[terminator2]

It's almost as if 504 bytes/sector. All 55 AA signatures are 'off' by 8 sectors.

*bytes. Off by 8 bytes.

Thanks Arch

[terminator2]

If you patch the first 4 sectors, everything else lines up.

Edit: No it doesn't. Sorry.

Thanks fzabkar
Due to unknown reasons (may be multiple restarts / power failures) this might have happened.
I think plain software based logical recovery may not be possible.
Is there anything I can try or is it irrecoverable at my end.

[chipsang]

in toms hardware forum this info is present
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Arno Wagner" <me@privacy.net> wrote in message news:3fdrkbF77gb8U1@individual.net
> Previously news.xtra <jdekker@xtra.co.nz> wrote:
> > When wanting to put another hard drive into a Panasonic Hard disk recorder
> > and failing, I tried to mount the old Samsung sv0802n on my pc, it wouldn't
> > be recognized by bios.
> > Using a hard disk info program I discovered it had a reported 504 bytes per
> > sector and 34902 bytes per track. This is probably why it couldn't be seen
> > by bios.
> > I somehow need to change the seagate st380011a to match the samsung.
> > Is there a low level program for dos or windows that can do this?
>
> If your number is correct, then there is nothing you can do.

Probably. No ATA commands to change it, AFAICT.

> All standard drives have 512 Bytes/Sector.

Not necessarily with SCSI, And not necessarily with ATA-CE drives
(for Consumer Electronics equipment such as Hard disk recorders).

> This one must have a modified firmware.

Or just the latest firmware that supports some of the new Long/Large
Sector features in ATA-7/8.

>
> 34902 is not divisible by 504, which is strange.

He most likely meant sectors. No point in listing bytes per track

It seems we cannot change bytes /sectors. This must be done by hard disks firmware

[fzabkar]

It seems to me that the beginning of the data area is laid down as follows:

write 500 bytes, drop 8 bytes, write 500 bytes, drop 8 bytes, write 500 bytes, drop 8 bytes ...

This results in the next sector rolling into the previous sector.

However, there is a FAT32 boot sector at offset 0x100000. Its BIOS Parameter Block points to sector 0x800 (= 2048), which means that this boot sector is in the right place. This means that the sectors are correctly synchronised at this point, at least at the beginning. However, once again the previous pattern repeats after 500 bytes.

The BPB indicates that there are 0x19DE reserved sectors, which means that the first copy of the FAT should be located at offset ...

0x100000 + (0x19DE x 0x200) = 0x43BC00

However, the two FATs are located at 0x43B504 and 0x49D67C, which once again points to dropped bytes.

[terminator2]

It seems to me that the beginning of the data area is laid down as follows:

write 500 bytes, drop 8 bytes, write 500 bytes, drop 8 bytes, write 500 bytes, drop 8 bytes ...

This results in the next sector rolling into the previous sector.

However, there is a FAT32 boot sector at offset 0x100000. Its BIOS Parameter Block points to sector 0x800 (= 2048), which means that this boot sector is in the right place. This means that the sectors are correctly synchronised at this point, at least at the beginning. However, once again the previous pattern repeats after 500 bytes.

The BPB indicates that there are 0x19DE reserved sectors, which means that the first copy of the FAT should be located at offset ...

0x100000 + (0x19DE x 0x200) = 0x43BC00

However, the two FATs are located at 0x43B504 and 0x49D67C, which once again points to dropped bytes.

You are absolutely great fzabkar
This much low level analysis is something amazing.
from above description it seems to me that recovery is impossible or at least beyond my scope. Will UDMA SAS will help ?

[Lardman]

Was this a single drive or part of an array, nas or das etc.

[Arch Stanton]

Weird stuff. I am no expert on this, can it be the connection itself?

I assume RAW scan still results in files being found, and that these are all corrupt?

[fzabkar]

Weird stuff. I am no expert on this, can it be the connection itself?

The location of the FAT suggests that 4 bytes are dropped at some time, which means that the original pattern is not consistent.

To test the connection, one could read offset 0x43BC00 (LBA 0x21DE) and see whether the data corresponds to FAT #1. Alternatively, one could read LBA 1 and see whether the EFI signature is now correctly aligned.

[Rainbow]

Isn't the drive formatted for 520 bytes per sector?

[terminator2]

Was this a single drive or part of an array, nas or das etc.

Thanks. Strangely this was a single disk that customer has given. Even I am not aware of any Raid 1 / Raid 5 configuration,

[terminator2]

Isn't the drive formatted for 520 bytes per sector?

I don't have any idea how drive was formatted earlier.

[terminator2]

Weird stuff. I am no expert on this, can it be the connection itself?

I assume RAW scan still results in files being found, and that these are all corrupt?

Hi Arch
Yes raw recovery shows large no of files ,some of them are working while others have lost integrity.

[terminator2]

Meantime I have got reply from Dmitry (dmde) according to him --
The data is misaligned / shifted. SAS disks have the feature of supporting / reporting varying sector sizes. Maybe this relates somehow, maybe there is a firmware problem. From the full scan log it also seems that significant amount of data is also lost / corrupted (besides the rest data is shifted)

[Arch Stanton]

Yeah, but 504 bytes per block? What OS can possible work with that block size?

To me it is af if the drive is 'dropping' bytes.

In MBR we see a Windows disk signature at correct location (offset 440), partition table starts at correct location. First partition table entry seems correct (offset 446) .. then zeros until 55 AA 8 bytes to early. So somewhere in between end of 1st partition entry and 55 AA bytes are 'dropped' for lack of better term. When you partition a drive Fdisk or disk management etc. will write 55 AA to offset 510 no matter block size, right? Because MBR is 512 bytes regardless logical block size. So it's the drive that's doing something weird, which IMO you'll never be able to solve using software, unless

- you find pattern (This is Frank's job )
- process disk image to undo shifts (insert dummy bytes)
- and you accept you lose 8 bytes every block you need to shift

Which in the end will result in massive corruption the more sectors you have to 'unshift'.

Ergo, this is not a solution. Does drive behave the same when attached to original controller? Or of that's already the case, to different controller? How does drive report / ID itself with which physical / logical block size?

[fzabkar]

I "repaired" the first 13 sectors beginning at offset 0x100000. That's where the FAT32 boot sector is located.

The procedure I used was ...

read 500 bytes, insert 8 pad bytes, read 500 bytes, insert 8 pad bytes, read 500 bytes, insert 8 pad bytes, ...

Obviously the data is corrupt, but the sectors are correctly aligned. I tried other approaches, but this was the only one where the text in both boot sectors was correct.

Attachments

Boot_sector_repaired.7z

(947 Bytes) Downloaded 396 times

[terminator2]

Yeah, but 504 bytes per block? What OS can possible work with that block size?

To me it is af if the drive is 'dropping' bytes.

In MBR we see a Windows disk signature at correct location (offset 440), partition table starts at correct location. First partition table entry seems correct (offset 446) .. then zeros until 55 AA 8 bytes to early. So somewhere in between end of 1st partition entry and 55 AA bytes are 'dropped' for lack of better term. When you partition a drive Fdisk or disk management etc. will write 55 AA to offset 510 no matter block size, right? Because MBR is 512 bytes regardless logical block size. So it's the drive that's doing something weird, which IMO you'll never be able to solve using software, unless

- you find pattern (This is Frank's job )
- process disk image to undo shifts (insert dummy bytes)
- and you accept you lose 8 bytes every block you need to shift

Which in the end will result in massive corruption the more sectors you have to 'unshift'.

Ergo, this is not a solution. Does drive behave the same when attached to original controller? Or of that's already the case, to different controller? How does drive report / ID itself with which physical / logical block size?

Hi Arch
Yes you have valid point - I haven't checked with original controller but with Adaptech 1405 controller. Its possible that sector count is not measured correctly. I have asked customer to send original sas controller ,may be that will give different results.