… trying alternative server operating systems… even linux live CDs on a „live“ system… (i wanted to test if knoppix can access the 1068e RAID) could lead to severe NTFS-dataloss.
Linux usually has no problem with NTFS and per default only has read access to those partitions.
But something went wrong when trying to to load the mptsas kernel module für the 1068e… those windows-driver-dependen-raid controlers are a real horror for linux… better is to not even have such a „pro“ LSI system but have normal sata ports and create a software raid created with mdadm (http://wiki.ubuntuusers.de/Software-RAID)
…. first of all:
it won’t display any video, you need to hit F3 to see the boot-help… there look for the line that says „fixes problems with videocards“ and type it in like it is displayed.
This is what my main RAID10-GPT-NTFS partition looked after „trying out“ Knoppix Live DVD on a Supermicro X8DT3
DON’T DO THIS:
Not an option here… because i only have proper access to the raid through windows (ARGH!).
What can you do? RESTORE WITH A VIRTUAL LINUX WITH DIRECT PHYSICAL ACCESS TO THE BROKEN DRIVE!
1. Install VirtualBox
2. Download some Live-Linux (Knoppix recommended)
3. Setup a Linux VM in VirtualBox Manager
4.1. open a terminal (start->run->cmd) find out how windows refers to your missing harddisk:
C:UsersAdministrator>wmic diskdrive list BRIEF Caption DeviceID Model Partitions Size Samsung SSD 840 PRO Series ATA Device \.PHYSICALDRIVE0 Samsung SSD 840 PRO Series ATA Device 1 128034708480 LSI MegaSR SCSI Disk Device \.PHYSICALDRIVE1 LSI MegaSR SCSI Disk Device 2 62997419520 LSI MegaSR SCSI Disk Device \.PHYSICALDRIVE2 LSI MegaSR SCSI Disk Device 0 5996994071040
now create the fake vmdk
# windows VBoxManage internalcommands createrawvmdk -filename C:X_PHYSICALDRIVE2.vmdk -rawdisk \.PHYSICALDRIVE2 # linux VBoxManage internalcommands createrawvmdk -filename /path/to/file.vmdk -rawdisk /dev/sda
Change the settings of your linux system to use this *.vmdk-fake-harddisk.
under linux open a terminal and :
# become root sudo bash # try to find the harddisk affected lsblk - list block devices # start gdisk gdisk /dev/sdb
here luckily gdisk reports that it found intact backup partition tables
hit 1 to restore those
to view changes
to write/save the changes.
then type: reboot to reboot the system into windows… what i got now is an intact partition… but without the files… so i guess i have severe filesystem damage.
THEN USE GETDATABACK NTFS TO GET ALL POSSIBLY MISSING FILES!
… the 3.03 version took around 2 days to scan for files… and even worse: it fails badly on large drives (5TB) with loads of errors.
I ENDED UP FORMATING AND RESTORING FROM BACKUP! 🙁
So i need to conclude:
DO NOT BOOT A LINUX LIVE SYSTEM ON A WINDOWS-SERVER WITH THE 1068e CONTROLLER!!
someone write! (did not work for me)
Let it attempt to repair. Worst case scenario, you might have boot off a Vista installation disk and open the recovery console to perform a
If it doens’t work on the first try, do it again. I have repaired a few NTFS file sysmtems using
more than once.
Unfortunately, it may be so bad off that it’s unrepairable. Thats when you might try some external tools like ntfsfix from a linux live boot disk. Good luck.
-> that is probably my case.
Example of a QNAP NAS Software-Raid:
[~] # mdadm --detail /dev/md0 /dev/md0: Version : 00.90.03 Creation Time : Mon Oct 7 10:03:23 2013 Raid Level : raid5 Array Size : 970518272 (925.56 GiB 993.81 GB) Used Dev Size : 242629568 (231.39 GiB 248.45 GB) Raid Devices : 5 Total Devices : 5 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Sun Dec 8 10:40:34 2013 State : clean Active Devices : 5 Working Devices : 5 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 64K UUID : bc8276a3:c995a945:e2dabd83:778f1f3b Events : 0.4 Number Major Minor RaidDevice State 0 8 3 0 active sync /dev/sda3 1 8 19 1 active sync /dev/sdb3 2 8 35 2 active sync /dev/sdc3 3 8 51 3 active sync /dev/sdd3 4 8 67 4 active sync /dev/sde3