Something messes up NTFS drives. Data lost.

I had my NTFS-formatted RAID1 pair of 1TB drives connected while trying to install openSUSE 11.0. (I have one, fresh, single drive for Linux, one RAID1 NTFS storage meant to become iSCSI-target). Installation was unsuccessful, because GRUB wouldn’t install onto the HDD. I tried installing to the mbr and to the bootable partition but nada. Write to the MBR generic(something) option - still nothing. Error popup contained blank text field so can’t provide any error message. Everytime Installer then offered me a possibility to rearrange partitions and boot methods, all attempts failed. I don’t remember touching raid1 drives at any point though. The raid1 present, was a software raid managed by BIOS on ATI SB700. Thing is, linux did not see it as one drive but two separate ones, as i noticed in the partition manager. After failing installation I removed them from my box, reattempted installation of openSUSE 11.0 and everything went fine. Patching, drivers, everything. When i tried to reconnect the RAID1, openSUSE boots, shows up menu, and after i choose something - it reboots w/o warning nor error. Safe mode doesn’t work - it is just before loading vmlinuz. Just can’t boot with ATI’s software raid BIOS installed in memory. Earlier I made GRUB diskette and now ensured that my NTFS drive is hd1 not hd0 so i can’t see the reason. I typed ‘boot’ at the prompt but it just reset itself. Then i booted to windows and checked the RAID1 - turns out Partition is there, type NTFS but UNKNOWN FILESYSTEM. Read that? **Near 1TB **of dear, especially protected and mirrored data lost by failed installation of linux and on a totally separate drive? Unbelievable! How could either grub or that partition editor write something to totally unrelated disks?

After that i put these two drives to the side. Since then, in pursuit of the root of my problem, i installed several Windows XPs on various SATA and ATA drives, all of them managed to become unbootable after some playing in openSUSE and mounting their NTFS filesystems. These drives, being non-raid, cam be seen, read and written w/o problem under linux or windows, they show no errors, according to chkdsk, except for the fact that none of them is bootable anymore. Boot attempt from one of these is always the same - instant reboot of my machine. fdisk /fixmbr does not work. After this command i get ‘Partition Table Error’ string on screen at boot, and everything halts - doesn’t reboot anymore but that’s hardly any consolation. Recovery from xp installation CD unsuccesful, no changes, same message. Removing all partitions and creating them anew - works.

I tried then connecting one of my RAID1 drives to my notebook using some USB adapter, and i got that fancy data restore application which finds my damaged NTFS partition at sector 63. It can recover lost data, but is very unreliable and non-eng filenames are always omitted. Thing is, majority of my files have non-english filenames. My only hope is to get back what i lost - which is my original partition table.

Seems like either openSUSE 11.0 partition manager or grub at some point is able to alter slightly partition table. In case of my RAID1, i suspect it wrote to the area where some important data resided.

I would be very grateful if someone helped me revert this change, whatever it was. Better yet, i still plan on putting a RAID1 in that box, this time using hardware controller ARECA 9650SE, so i would desire to identify the problem to avoid data loss in the future, and if we knew what that “change” was i could just re-create the RAID1 on some other pair of drives and just copy some sector to my other broken RAID1 or something…

Anyway it is hard to say what exactly makes my drives go bad in the same way. I tried to play with partition manager - just mounting and fstab editing - at some point it would make my drive unbootable, but i still was unable to determine which operation. Maybe not even partition manager but GRUB itself - who ktnows. I have many drives i can play with, i have time and will to do it, but it simply is beyond my skills at this point. Please help.

I have replied to this to bring it back up the list for you, as I don’t have any RAID experience. Though Grub will only write to where you tell it!
Hope someone with experience in this area picks this up.

Hello again,
Today i have analyzed first 256 sectors of my unbootable but otherwise healthy NTFS drives and here’s what i found:
first of all boot sector contains some information about 4th partition, while i have only one that spans the whole disk. It does not make any sense, it’s all rubbish there anyway.
The funny thing is, while my normal, bootable drive has some kind of NTFS information at the beginning of every cluster, (contains a lot of 1880h) the one that does not want to boot contains these strings in the 255th, 275th and 279th sector:

WA_funta_RURU
OSTA Compressed Unicode
OSTA Compressed Unicode
*Aplix UDF.
vi

Does it seem familiar to Anyone?
Anyone knows what thing could write this to an NTFS drive?

OK i know what is that thing in 255th sector. nevermind that, please.

yes, you’re right. I think either modifying boot loader in yast or enabling sysrq keys in kernel setup in yast destroys the ntfs filing system:(