1 Anfängerfehler: Die eine Platte war offenbar nicht in der BIOS-Boot-Tabelle eingetragen.

2-tes Problem: Es musste Grub ausgeführt werden:

grub


root (hd0,0)
setup (hd0)
root (hd1,0)
setup (hd1)
quit


Ausserdem habe ich am Ende die sfdisk-Methode genutzt. Die ist wirklich weniger aufwendig und hat funktioniert.

Damit werden dann auch die extendet platten korrekt kopiert

Device Boot Start End Blocks Id System
/dev/sda1 63 152344394 76172166 fd Linux raid autodetect
/dev/sda2 152344395 156296384 1975995 82 Linux swap / Solaris


Die Grub-Konfiguration sieht wie folgt aus:

title Debian GNU/Linux, kernel 2.6.18-5-686
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-5-686 root=/dev/md0 ro
initrd /boot/initrd.img-2.6.18-5-686
savedefault

title Debian GNU/Linux, kernel 2.6.18-5-686 (single-user mode)
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-5-686 root=/dev/md0 ro single
initrd /boot/initrd.img-2.6.18-5-686
savedefault


Die ursprüngliche Installation erfolgte direkt auf das Software-RAID1, nach dieser Anleitung: Install-Debian-Etch-on-a-Software-Raid-1-with-S-ATA-disks

Von der alten Festplatte kann auch gebootet werden. Daher sollte der MBR-Eintrag ja grundsätzlich in Ordnung sein?
Kann ich irgendwie testen, ob auf der neuen Festplatte (sdb) zumindest alle Daten korrekt kopiert wurden? mdadm zeigt mir zwar den Status “clean” an, aber im Moment bin ich mir nicht sicher, ob ich dem trauen kann.

Entweder nochmal manuell rüberkopieren oder Super Grub Disk ausprobieren.

Für einen Test habe ich die neue Festplatte an den Platz der alten Festplatte gehängt und die alte Festplatte vom SATA-Bus genommen.

Ein Neustart funktioniert jetzt nicht. Er bleibt bei der Meldung “GRUB” hängen.
Grub scheint also keine Boot-Informationen zu finden.
Was mache ich falsch?

Habe hier einen Debian Server mit Promis SATA-controller und Softwareraid laufen.
Ohne jegliche Probleme (4x500Gb HDD´s).
Root 5GB, Swab 1GB, var 1GB und va/log 1BG sind auf einem Raid1 mit 4 Festplatten und die restliche 4x491GB sind als Raid5.

Das Raid wird über Webmin administriert.

Auch über das webmin werden die Benutzer und Gruppen administriertd, allerdings in einem beschnittenen Webmin-Benutzer, der auch nur das kann.

Bis jetzt keine Probleme.

Gruß
Robert

Ansonsten ist sfdisk für erweiterte Partitionen sicherlich sinnvoll!

sfdisk -dx /dev/hda wäre das z.B.

Eigentlich könntest Du den Dump auch gleich wieder in sfdisk reinpipen für die Ersatzplatte.

Ok, Swap auf RAID1:
Wenn der RAM voll ist und der Swap genutzt wird, ist ein Swap auf RAID1 doch eine deutliche Performance Bremse, da erst nach dem kompletten Schreibvorgang auf beiden Platten der Vorgang beendet ist.
Und was genau würde passieren, wenn eine der beiden Festplatten abraucht und somit eine Swap Partition wegfällt (Linux nutzt ja alle angegeben Swapspaces aus der fstab)? Ein Kernel Crash? Hat das mal jemand erlebt? Sofern der Swap nicht genutzt wird, sollte auch nichts passieren. (auf keinem der von mir betreuten Server wird der Swap genutzt, und wenn wird der RAM erhöht)
Bei einer Workstation – insbesondere Laptop oder ähnliches – sehe ich mehr Sinn, wenn man hier Suspend-to-RAM nutzt…

>Habe mit Software-RAID auch noch keine Probleme gehabt – und die Performance ist voll ok. So >hatte ich bei manchen HW-RAIDs schon schlechtere Performance, aufgrund der schlechten >Treiberunterstützung.
3Ware ist ja direkt im Kernel und ganz gut verbreitet.

>Außerdem ist ein Software-RAID immer gleich – egal welche Hardware man nutzt. Man kann es >also mit genau den selben Tools überwachen und administrieren, wie auf allen anderen
>Maschinen.
Wenn man überall 3Ware einbaut, ist auch immer alles gleich

>Zum Thema Swap auf RAID: Ich halte trotzdem nicht viel davon. Wenn der Rechner den Swap
>nutzt, hat das System ja wahrscheinlich schon zu wenig RAM. Dann lieber zwei einzelne
>Swap-Bereiche mit besserer Performance als Swap auf RAID1.
Auf einer Workstation würde ich dir zustimmen, aber nicht bei einem Server wegen des Crash-Problems.

Wegen eurer Performanceangaben: hdparm -tT sagt aber nicht SOOO viel aus, es kommt ja auch auf die Zugriffszeiten, Schreibgeschwindigkeit usw. an!

mach mal:
time dd if=/dev/urandom of=/tmp/u count=1024000 bs=1024
dann rebooten
und dann: time dd if=/tmp/u of=/tmp/u2
time rm -f /tmp/u /tmp/u2

Ein richtiger benchmark wie bonnie++ wäre aber besser…

Auch ich habe noch keine schlechten Erfahrungen mit einem Software-RAID unter Linux gemacht. Bis jetzt hat immer alles problemlos funktioniert.

Mit Performacedaten kann ich im Moment leider nicht dienenm, da ich zur Zeit nur AIX Kisten in Reichweite habe.

Zum Thema Swap auf RAID: Ich halte trotzdem nicht viel davon. Wenn der Rechner den Swap nutzt, hat das System ja wahrscheinlich schon zu wenig RAM. Dann lieber zwei einzelne Swap-Bereiche mit besserer Performance als Swap auf RAID1.

BTW: Mein RAID0 hier auf diesem Rechner:
matthias@pcmatthias:~$ sudo hdparm -t /dev/md1
Password:

/dev/md1:
Timing buffered disk reads: 318 MB in 3.02 seconds = 105.35 MB/sec

Finde ich voll i.O. für ein Software-RAID mit SATA1 Platten

mm@lisa:~>lspci | grep 3114
01:0b.0 Mass storage controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)

Auf meiner privaten Maschine betreibe ich damit ein RAID1 (/boot) sowie 2x RAID5 (/ und /home) mit 4x 80GB Samsung Platten.

Funktioniert nun seit Jahren reibungslos, wenn man von Mein RAID5 löst sich auf/ einmal absieht.

Lese-Performance:

root@lisa:~>hdparm -t /dev/md3

/dev/md3:
Timing buffered disk reads: 254 MB in 3.02 seconds = 84.22 MB/sec

Gruss,
Marcel.

Ich hatte 4x Samsung SpinPoint T166 HD501LJ & folgendes:

01:09.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02) (http://www.stetech.de/images/sata-controller.jpg)

Damit habe ich RAID1 und RAID5 ausprobiert…totaler Schrott, miese Performance, immer Dateisystemprobleme. Vielleicht war die Karte auch einfach nur Müll, aber ich hatte die Schnauze voll, habe mich entschieden, Software-Raid zu lassen und habe mir einen 3Ware 9500S-4 gekauft, damit habe ich wenigstens keinen Ärger…

Software-Raid kann aber toll sein, wenn man sehr knapp kalkulieren muss; ich würde sowas aber nicht mehr freiwillig verbauen, ich baue doch nichts unzuverlässiges in mein Netz, wenn ich was zuverlässigeres kaufen darf

Achja, wegen des –monitor Modus; in /etc/mdadm.conf kann man anpassen:

# When used in –follow (aka –monitor) mode, mdadm needs a
# mail address and/or a program. This can be given with “mailaddr”
# and “program” lines to that monitoring can be started using
# mdadm –follow –scan & echo $! > /var/run/mdadm
# If the lines are not found, mdadm will exit quietly
#MAILADDR root@mydomain.tld
#PROGRAM /usr/sbin/handle-mdadm-events

Von daher: Auch Swap auf ein /dev/md* Device packen und schön mit aufs RAID verteilen.

Gruss,
Marcel.

PS: Mittels /proc/sys/dev/raid/speed_limit_max kann man das IO-Aufkommen beim Rebuild im Zaum halten, wenn ansonsten das System zu sehr in die Knie gezwungen wird.