Also ich habe jetzt deinen Befehl mal so probiert! allerdigs hast du vergessen, die Anzahl der Plattenanzugeben, ich habe sie hinzugefügt

root@tux-server:~# mdadm --create /dev/md42 --assume-clean --level=6 --raid-devices=5 --metadata=0.90 --chunk=64  /dev/sdb2 /dev/sdc2 /dev/sdd2 /dev/sde2 missing
mdadm: /dev/sdb2 appears to be part of a raid array:
    level=-unknown- devices=0 ctime=Wed Jan  1 01:02:00 2003
mdadm: /dev/sdc2 appears to be part of a raid array:
    level=-unknown- devices=0 ctime=Wed Jan  1 01:02:00 2003
mdadm: /dev/sdd2 appears to be part of a raid array:
    level=-unknown- devices=0 ctime=Wed Jan  1 01:02:00 2003
mdadm: /dev/sde2 appears to be part of a raid array:
    level=-unknown- devices=0 ctime=Wed Jan  1 01:02:00 2003
Continue creating array? 
Continue creating array? (y/n) y
mdadm: array /dev/md42 started.
root@tux-server:~# file -s /dev/md42
/dev/md42: data

Verstehe ich das jetzt richtig? Ich muss weiterprobieren, mit der Chunksize oder? sda2 gehört nicht zum Raid, da hat mir mdam einen Fehler ausgespuckt.

horschtinator schrieb:

allerdigs hast du vergessen, die Anzahl der Plattenanzugeben, ich habe sie hinzugefügt

Dafür hast du ein missing zuwenig bzw. ein Laufwerk zuviel. Wenn sda2 nicht ging hättest du es durch missing ersetzen müssen und nicht alles eins weiterschieben.

sda2 gehört nicht zum Raid, da hat mir mdam einen Fehler ausgespuckt.

Kannst du dann mal bitte klarstellen, welche Geräte in dein RAID gehören und welche nicht? Es müssen ja 5 Geräte sein und ein sdf hast du soweit ich das mitbekommen habe gar nicht. (Poste mal deine /proc/partitions)

Und welchen Fehler hat mdadm ausgespuckt?

Das md42 kannst du jedenfalls wieder stoppen. "data" ist wirklich nicht das erwünschte Ergebnis.

Das hier kam bei sda2 heraus

root@tux-server:~# mdadm --create /dev/md42 --assume-clean --level=6 --raid-devices=5 --metadata=0.90 --chunk=64 /dev/sda2 /dev/sdb2 /dev/sdc2 missing missing
mdadm: /dev/sda2 is not suitable for this array.

Dafür hast du ein missing zuwenig bzw. ein Laufwerk zuviel. Wenn sda2 nicht ging hättest du es durch missing ersetzen müssen und nicht alles eins weiterschieben.

Ich zähle mit dem missing zusammen 5 Laufwerke. Oder verstehe ich das mit dem Mossing falsch?

Die Ausgabe für /proc/partitions

root@tux-server:~# cat /proc/partitions
major minor  #blocks  name

   8        0   15466496 sda
   8        1   14949376 sda1
   8        2          1 sda2
   8        5     514048 sda5
   8       16  488386584 sdb
   8       17    1959898 sdb1
   8       18  486424102 sdb2
   8       32  488386584 sdc
   8       33    1959898 sdc1
   8       34  486424102 sdc2
   8       48  488386584 sdd
   8       49    1959898 sdd1
   8       50  486424102 sdd2
   8       64  488386584 sde
   8       65    1959898 sde1
   8       66  486424102 sde2
   9       42 1459272000 md42

wie stoppe ich die md42? Verzeih bitte meine jämmerliche Unwissenheit! Die Platten sind: sdb2 sdc2 sdd2 sde2 liege ich richtig? Eine Platte fehlt, oder? Danke für die schnellen Antworten

Hab gerade im syslog file eine Entdeckung geacht, habe ich wohl früher übersehen!

Jul 28 12:04:48 tux-server kernel: [ 2101.746429] md/raid:md1: device sdb2 operational as raid disk 0
Jul 28 12:04:48 tux-server kernel: [ 2101.746434] md/raid:md1: device sdf2 operational as raid disk 4
Jul 28 12:04:48 tux-server kernel: [ 2101.746438] md/raid:md1: device sde2 operational as raid disk 3
Jul 28 12:04:48 tux-server kernel: [ 2101.746442] md/raid:md1: device sdd2 operational as raid disk 2
Jul 28 12:04:48 tux-server kernel: [ 2101.746445] md/raid:md1: device sdc2 operational as raid disk 1
Jul 28 12:04:48 tux-server kernel: [ 2101.747118] md/raid:md1: allocated 5258kB
Jul 28 12:04:48 tux-server kernel: [ 2101.748905] md/raid:md1: raid level 5 active with 5 out of 5 devices, algorithm 2
Jul 28 12:04:48 tux-server kernel: [ 2101.748910] RAID conf printout:
Jul 28 12:04:48 tux-server kernel: [ 2101.748913]  --- level:5 rd:5 wd:5
Jul 28 12:04:48 tux-server kernel: [ 2101.748917]  disk 0, o:1, dev:sdb2
Jul 28 12:04:48 tux-server kernel: [ 2101.748920]  disk 1, o:1, dev:sdc2
Jul 28 12:04:48 tux-server kernel: [ 2101.748923]  disk 2, o:1, dev:sdd2
Jul 28 12:04:48 tux-server kernel: [ 2101.748926]  disk 3, o:1, dev:sde2
Jul 28 12:04:48 tux-server kernel: [ 2101.748929]  disk 4, o:1, dev:sdf2

d.h: wir haben jetzt die Reihenfolge und die namen der Platten richtig? Allerdings finde ich komisch, das das Raid6 damals als Raid5 Erkannt und eingebunden wurde. Bin mir eigentlich ziemlich sicher, dass es ein Raid 6 war? Kann das sein, dass das System das verwechseln kann, oder irre ich mich einfach?

Ich zähle mit dem missing zusammen 5 Laufwerke. Oder verstehe ich das mit dem Mossing falsch?

Die Idee war die Redundanzlaufwerke wegzulassen. Bei RAID 6 gibts zweifache Redundanz also braucht man missing auch zweimal. Du hattest es am Ende aber nur einmal drin. Aber das ist jetzt eh wurst.

Stoppe erstmal md42 wieder:

sudo mdadm --stop /dev/md42

Es ist leider verdammt schwer zu helfen wenn man mit falschen Informationen arbeiten muss. Der Logausgabe hattest du ein RAID 5. sda scheint allerdings was ganz anderes zu sein, und sdf fehlt ganz. Durch einen Kernelbug passiert das jedenfalls nicht, ist die Platte ausgebaut worden oder defekt?

Der Logausgabe könntest du dann jedenfalls mal diesen Befehl probieren:

sudo mdadm --create /dev/md42 --assume-clean --level=5 --raid-devices=5 --metadata=0.90 --chunk=64  /dev/sdb2 /dev/sdc2 /dev/sdd2 /dev/sde2 missing

missing ist hier zwangsweise die sdf2 da die ja tatsächlich fehlt. Wenn dann noch eine der anderen Platten defekt ist dann sind die Daten so oder so hinüber, da es bei RAID 5 nur einfache Redundanz gibt.

In dem Log steht drum herum nicht zufällig noch die Chunksize dabei, oder? Die 64 sind jedenfalls auch nur geraten.

Viel Glück.

Nein, die Chunksize habe ich nirgends gefunden. Als ich das Raid vor 3 Jahren eingerichtet habe, war es meine ich Raid6, kann das aber leider nicht mehr nachschauen. Sorry für die Fehlinformationen!

Hi Hi,hier die Ausgabe von deinem Befehl:

root@tux-server:~# mdadm --stop /dev/md42
mdadm: stopped /dev/md42
root@tux-server:~# mdadm --create /dev/md42 --assume-clean --level=5 --raid-devices=5 --metadata=0.90 --chunk=64  /dev/sdb2 /dev/sdc2 /dev/sdd2 /dev/sde2 missing
mdadm: /dev/sdb2 appears to be part of a raid array:
    level=raid6 devices=5 ctime=Wed Aug  1 18:47:50 2012
mdadm: /dev/sdc2 appears to be part of a raid array:
    level=raid6 devices=5 ctime=Wed Aug  1 18:47:50 2012
mdadm: /dev/sdd2 appears to be part of a raid array:
    level=raid6 devices=5 ctime=Wed Aug  1 18:47:50 2012
mdadm: /dev/sde2 appears to be part of a raid array:
    level=raid6 devices=5 ctime=Wed Aug  1 18:47:50 2012

Da steht ja auf einmal Raid 6! Weiß jetzt nicht ob ich lachen oder weinen soll!

Ausgabe Nach create:

mdadm: array /dev/md42 started.
root@tux-server:~# file -s /dev/md42
/dev/md42: LVM2 PV (Linux Logical Volume Manager), UUID: R0Hhff-Z0EY-3uFA-JUCA-RyU0-IM0y-AjNsa5, size: 1992392507392

Meiner Meinung nach sieht das recht gut aus oder?

Ja, versuche die weiteren Schritte die ich am Ende meines vorvorherigen Posts geschrieben hatte.

So, bin jetzt weiter, aber es gibt noch Problemchen:

root@tux-server:~# file -s -L /dev/mapper/vg0-lv0
/dev/mapper/vg0-lv0: Linux rev 1.0 ext3 filesystem data, UUID=5470e0a8-8e77-4bde-bc16-344f3fe6c8f8 (errors) (large files)
root@tux-server:~# mount -o ro /dev/vg0/lv0 /mnt/
mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg0-lv0,
       missing codepage or helper program, or other error
       Manchmal liefert das Syslog wertvolle Informationen – versuchen
       Sie  dmesg | tail  oder so

root@tux-server:~# dmesg | tail
[ 6336.282425]  disk 1, o:1, dev:sdc2
[ 6336.282428]  disk 2, o:1, dev:sdd2
[ 6336.282432]  disk 3, o:1, dev:sde2
[ 6336.282488] md42: detected capacity change from 0 to 1992392704000
[ 6336.286791]  md42: unknown partition table
[ 6336.473856] bio: create slab <bio-0> at 0
[ 8651.881887] EXT3-fs error (device dm-1): ext3_check_descriptors: Block bitmap for group 1920 not in group (block 130023424)!
[ 8652.054319] EXT3-fs (dm-1): error: group descriptors corrupted
[ 8848.092684] EXT3-fs error (device dm-1): ext3_check_descriptors: Block bitmap for group 1920 not in group (block 130023424)!
[ 8848.092809] EXT3-fs (dm-1): error: group descriptors corrupted

Was jetzt? Ich stehe wie der Ochs vorm Berg! sdf2 Wurde nicht ausgebaut. Das Raid war einfach vom einem auf den anderen Tag nicht erreichbar!

Wie gesagt, die Chunksize könnte noch falsch sein.

Kannst du mal die Ausgabe von vgdisplay und lvdisplay posten?

Ist vg0-lv0 das einzige Dateisystem oder gibt es noch weitere LVs? Falls es weitere gibt, funktionieren die?

Ansonsten eben andere Chunksizes durchprobieren. Dazu alles wieder stoppen (vgchange -a n vg0, mdadm --stop /dev/md42, und dann jeweils erneutes create mit chunk=512, chunk=256, chunk=128 statt chunk=64 und nochmal probieren).

Ausgabe von vgdisplay

root@tux-server:/# vgdisplay
  --- Volume group ---
  VG Name               vg0
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  4
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               1,81 TiB
  PE Size               4,00 MiB
  Total PE              475023
  Alloc PE / Size       475009 / 1,81 TiB
  Free  PE / Size       14 / 56,00 MiB
  VG UUID               7Mse3T-Zwby-rDxw-z3Pw-9lZQ-3WQO-GFffBg

Ausgabe von lvdisplay

root@tux-server:/# lvdisplay
  --- Logical volume ---
  LV Name                /dev/vg0/syslv
  VG Name                vg0
  LV UUID                6Gg3A0-heML-XZhL-RhlG-v4bh-J9m8-HMgOWX
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                1,00 GiB
  Current LE             256
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     1024
  Block device           252:0
   
  --- Logical volume ---
  LV Name                /dev/vg0/lv0
  VG Name                vg0
  LV UUID                BJe3Tm-RCNl-L5tj-dDWd-oSjQ-xD9t-3TUges
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                1,81 TiB
  Current LE             474753
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     1024
  Block device           252:1

Ich probiere jetzt mal mit Chunksize 512. Kein Erfolg mit chunksize: 512, 256, 128 64 und 1024

Wenn die anderen Chunksizes auch nicht gehen dann bleib jedenfalls mal bei 64 da das das wahrscheinlichste ist.

Was ist denn syslv? Was sagt file -s -L dazu? Läßt sich das mounten?

Hast du auf lv0 größere Dateien eines bekannten Types? z.B. JPEG-Dateien von einer Digitalkamera? Da könnte man PhotoRec nach JPEG-Dateien suchen lassen und schauen ob die intakt sind. Wenn eine (größere) JPEG-Datei gefunden wird die intakt ist dann stimmt auch die Chunksize. Wenn sich das Dateisystem trotzdem nicht mounten läßt bleibt fsck. Bei LVM bieten sich dann Snapshots an, da fsck auch Daten kaputtmachen kann; mit einem Snapshot könnte man das dann gut wieder rückgängig machen. Dazu müsstest du in deinem LVM allerdings mehr freien Speicher haben.

Warum ist eine chunksize von 64kb am wahrscheinlichsten? Ist das eine Annahme? Probiere jetzt mal aus was sylv ist. Größere Dateien sind viele vorhanden, .mkv mit bis zu 12GB und verschiedene iso Files. Photos sind auch vorhanden!

root@tux-server:/# file -s -L /dev/vg0/syslv
/dev/vg0/syslv: data

horschtinator schrieb:

Warum ist eine chunksize von 64kb am wahrscheinlichsten?

Es war die Standardeinstellung jedenfalls zu dem Zeitpunkt wo 0.90 Metadata auch die Standardeinstellung war.

Heute macht mdadm RAIDs mit 1.2 Metadata und 512 Chunks. 512er Chunk wäre somit das zweitwahrscheinlichsete.+

Ohne nähere Anhaltspunkte kann man ja leider nur raten

Photos sind auch vorhanden!

Dann photorec (aus dem testdisk Paket) mal auf lv0 loslassen und dabei nach JPEG suchen lassen (photorec unterstützt auch andere Formate aber wenn du alles außer JPEG ausmachst bekommst du nicht so viel Müll). Und dann schauen ob bei den gefundenen Dateien was größeres intaktes dabei ist (>1MB Datei). Falls ja ist die Chunksize und auch sonst alles richtig...

Nachteil an der Methode ist daß Photorec die ganze Platte einliest und es somit lang dauern kann ehe es was findet

Habe photorec mal gestartet, lasse den server die Nacht durchlaufen, speichern werde ich auf diversen externen Festplatten, hab gott sei dank USB anschluss! Danke dir mal so weit, bis Morgen!

Oh oh: Ausgabe von Photorec:

Filesystem analysis, please wait...
Getötet

Nach neustart von photorer funktioniert was, bis jetzt hat photorec 26 .txt files recovered

Teilweise kann ich die Textdateien lesen: z.B:

root@tux-server:/mnt/Bilder/recup_dir.1# cat f5844818.txt
sso per eliminare anche i file specifici di Shivering Isles.

*****************************************************************

     2. Problemi generali

*****************************************************************

- Problemi di installazione
	Installando e rimuovendo ripetutamente il gioco, alcuni sistemi potrebbero presentare un messaggio di errore. Per risolvere il problema, inserisci il DVD di Oblivion nell�unit� DVD-ROM e clicca due volte sul file setup.exe. In questo modo, l�errore verr� risolto e potrai nuovamente rimuovere e installare il gioco.

- Salvataggi
	I tuoi salvataggi si trovano nella cartella \Documenti\My Games\Oblivion.

- Prima dell�installazione
	Prima di installare Oblivion, assicurati che il tuo computer soddisfi i requisiti di sistema elencati pi� in basso.
	
	Inoltre, ti consigliamo di preparare il tuo disco per l�installazione avviando ScanDisk e Defrag. Questi strumenti di Windows� possono identificare e risolvere problemi del disco che potrebbero precludere l�installazione o impedire di giocare correttamente.
	
	Per avviare uno di questi programmi e ottimizzare il disco fisso:
	
	   1. Apri Risorse del computer.
	   2. Clicca con il pulsante destro del mouse sul disco sul quale vuoi installare il gioco (generalmente C:).
	   3. Clicca su Propriet�.
	   4. Seleziona la scheda Strumenti.
	   5. Clicca su Esegui ScanDisk per avviare ScanDisk.
	   6. Al termine delle operazioni di ScanDisk, ripeti dal punto 1 al punto 3 e clicca su Esegui Defrag per avviare la deframmentazione del disco.
	
	Attenzione: la deframmentazione del disco � un processo che puroot@tux-server:/mnt/Bilder/recup_dir.1# 

Ich denke das bestätigt die chunksize oder?

Da die Datei allem Anschein irgendwo mittendrin anfängt, eher nicht. Das kann aber auch durch Fragmentierung des Dateisystems kommen.

Textdateien sind aber kein gutes Beispiel weil nicht groß genug.

Muss dazu sagen, dass ich diese Dateien eigentlich gelöscht habe, als das Raid noch ohne Probleme lief... Habe jetzt die suche Abgebrochen und neugestartet, jetzt sucht er nur nach jpegs und .mkf files. Danke für deine Hilfe, ich bin heute schon echt weitergekommen und habe Hoffnung gewittert. Gute Nacht und bis Morgen!