Software RAID auf größere Platten umziehen
Hi,
bei mir hat ein ältere Server mit zwei 60GB Platten in einem Software RAID (RAID 1) den Dienst eingestellt, da diese schlicht voll sind. Es sind leider keine alten Logdateien sondern eine Datenbank. --> Das System läuft noch!
Jetzt war mein Gedanke
Jetzt habe ich aber zwei Probleme:
Hardware
Auf dem Server läuft Ubuntu 16.04 LTS
Ist es eventuell Sinnvoll statt das MD-Raid zu reparieren auf ZFS umzusteigen? (Die Datenplatten sind auch ein ZFS Verbund)
bei mir hat ein ältere Server mit zwei 60GB Platten in einem Software RAID (RAID 1) den Dienst eingestellt, da diese schlicht voll sind. Es sind leider keine alten Logdateien sondern eine Datenbank. --> Das System läuft noch!
Jetzt war mein Gedanke
- die Daten per rsync (rsync --stats --progress --numeric-ids -axAhHSP /mnt/alt/ /mnt/neu ) auf eine externe Platte zu kopieren
- dann die neuen Platten in den Server zu schrauben
- auf diesen mit einem Live System ein Software RAID einzurichten
- die Daten mit rsync wieder zurück zu kopieren.
- in /etc/fstab die UUIDs anpassen
- Per chroot hab ich dann noch grub installiert und die Kiste neu gestartet.
Jetzt habe ich aber zwei Probleme:
- Im BIOS/UEFI kann ich die neuen SSDs nicht als Boot Platten auswählen. Über die temproäre Startdevice Auswahl (F11) kann ich allerdings von den Platten starten. Der Support des MB Herstellers schweigt.
- Das System kommt nicht richtig hoch. Es bleibt beim boot mit "Failed to start Network Time Synchronisation" hängen.
Hardware
- MB: ASRock Z77 Extreme3
- alte SSDs von SanDisk
- neue SSDs Samsung Pro
- Da steckt noch ein HBA für Datenplatten drin.
- 16GB RAM
Auf dem Server läuft Ubuntu 16.04 LTS
Ist es eventuell Sinnvoll statt das MD-Raid zu reparieren auf ZFS umzusteigen? (Die Datenplatten sind auch ein ZFS Verbund)
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 347200
Url: https://administrator.de/contentid/347200
Ausgedruckt am: 22.11.2024 um 19:11 Uhr
43 Kommentare
Neuester Kommentar
Nun erst mal scheinst du nicht so die Erfahrung zu haben wodurch es so schon ein Fehler war nur Copy & Paste zu machen ohne sich Auszukennen.
Ihr solltet jedenfalls Schulung zu Linux Grundkenntnisse mal machen.
Nun auch wenn ihr die Daten Kopiert habt (mit Symlink & Co?), habt ihr zwar eine Kopie die jedoch ohne Handarbeit unbrauchbar als Startsystem ist.
Jede Platte und Partition hat eine Individuelle UUID worüber Linux die Platte erkennt und zuordnen wodurch es nach dem Start auch egal ist in welchen Port welche Platte steckt.
Da du 2 neue Platten hast haben die natürlich nach dem Dateisystem Anlegen auch eine andere UUID wo beim Start schon die ersten Probleme auftauchen da das System die Alte Platte Ansprechen will (mounten & Co) diese jedoch nicht mehr da ist wodurch das System stehen bleibt.
Dies kann man zwar auch Händisch auf die neuen Platten alle umändern (Grundwissen).
Dazu je nachdem was später noch geändert wurde in Scripten,Programmen für Backup & Co das auf die UUIDs zugreift (Dokumentation vorhanden?).
Normal würde man (je nach Raid was wohl 1 sein dürfte) die eine Platte als Fehlerhaft kennzeichnen und diese gegen die neue Platte Tauschen und diese einbinden.
Nach dem Rebuild auf die neue wird der Vorgang für die andere Platte gemacht und danach der Plattenplatz vergrößert.
Aber du kannst auch das System komplett neu machen falls alle Einstellungen & Co Bekannt sind.
Es gibt viele Dateisysteme wie auch BTRFS aber ein Umstieg sollte auch alle Vor und Nachteile bekannt sein sowie die Handhabung Bekannt sein was zb bei Problemen zu tun ist.
Bootflag bei der Platte gesetzt?
Ihr solltet jedenfalls Schulung zu Linux Grundkenntnisse mal machen.
Nun auch wenn ihr die Daten Kopiert habt (mit Symlink & Co?), habt ihr zwar eine Kopie die jedoch ohne Handarbeit unbrauchbar als Startsystem ist.
Jede Platte und Partition hat eine Individuelle UUID worüber Linux die Platte erkennt und zuordnen wodurch es nach dem Start auch egal ist in welchen Port welche Platte steckt.
Da du 2 neue Platten hast haben die natürlich nach dem Dateisystem Anlegen auch eine andere UUID wo beim Start schon die ersten Probleme auftauchen da das System die Alte Platte Ansprechen will (mounten & Co) diese jedoch nicht mehr da ist wodurch das System stehen bleibt.
Dies kann man zwar auch Händisch auf die neuen Platten alle umändern (Grundwissen).
Dazu je nachdem was später noch geändert wurde in Scripten,Programmen für Backup & Co das auf die UUIDs zugreift (Dokumentation vorhanden?).
Normal würde man (je nach Raid was wohl 1 sein dürfte) die eine Platte als Fehlerhaft kennzeichnen und diese gegen die neue Platte Tauschen und diese einbinden.
Nach dem Rebuild auf die neue wird der Vorgang für die andere Platte gemacht und danach der Plattenplatz vergrößert.
Aber du kannst auch das System komplett neu machen falls alle Einstellungen & Co Bekannt sind.
Es gibt viele Dateisysteme wie auch BTRFS aber ein Umstieg sollte auch alle Vor und Nachteile bekannt sein sowie die Handhabung Bekannt sein was zb bei Problemen zu tun ist.
Bootflag bei der Platte gesetzt?
Hallo,
nur noch kurz eine Anmerkung von mir nachtrtäglich dazu.
Vorredner beschrieben und wenn das nicht mehr funktionierten sollte dann muss eben das Backup mit "ins Spiel" und
man setzt den Server ganz neu auf und spielt dann ein Backup ein. Mal nach einem neuen BIOS für das Board geschaut?
für Dich das die dort drauf ist und Du nicht das RAID reparieren möchtest?
wenn dort erst einmal ein Fehler drauf ist bekommt man den so schnell und einfach nicht wieder herunter!!!!
Gruß
Dobby
nur noch kurz eine Anmerkung von mir nachtrtäglich dazu.
MB: ASRock Z77 Extreme3
Ist jetzt nicht so das Server Mainboard oder? Aber egal, ich würde die HDD/SSDs so wechseln wie schon von meinemVorredner beschrieben und wenn das nicht mehr funktionierten sollte dann muss eben das Backup mit "ins Spiel" und
man setzt den Server ganz neu auf und spielt dann ein Backup ein. Mal nach einem neuen BIOS für das Board geschaut?
alte SSDs von SanDisk
Funktioniert denn noch eine davon, oder bootet der Server noch mit den beiden alten Platten?neue SSDs Samsung Pro
Einmal nach einer neuen Firmware für die SSDs geschaut?Da steckt noch ein HBA für Datenplatten drin.
Firmware auch hier aktuell?Auf dem Server läuft Ubuntu 16.04 LTS
Schön und gut, nur mit was wurde denn das Backup gemacht?Ist es eventuell Sinnvoll statt das MD-Raid zu reparieren auf ZFS umzusteigen?
Also Platten reparieren ist das eine und die Daten wieder beschaffen das andere! Ist die Datenbank denn nicht wichtigfür Dich das die dort drauf ist und Du nicht das RAID reparieren möchtest?
(Die Datenplatten sind auch ein ZFS Verbund)
Mag sein aber das ist ein stark protokolliertes Dateisystem, und da empfiehlt es sich immer ECC RAM zu benutzen dennwenn dort erst einmal ein Fehler drauf ist bekommt man den so schnell und einfach nicht wieder herunter!!!!
Gruß
Dobby
moin,
die einfachste Art so ein RAID umzuziehen ist. mit ddrescue ein image des alten zu ziehen und dann per dd auf das neu erstellte zurückzuspielen.
Danach das filesystem resizen auf die neue Größe udn alles wird gut.
Durch das kopieren mit drescue bleiben auch die uuids und bootblöcke erhalten, so daß auc das direkte starten davon kein problem mehr sein sollte.
lks
die einfachste Art so ein RAID umzuziehen ist. mit ddrescue ein image des alten zu ziehen und dann per dd auf das neu erstellte zurückzuspielen.
Danach das filesystem resizen auf die neue Größe udn alles wird gut.
Durch das kopieren mit drescue bleiben auch die uuids und bootblöcke erhalten, so daß auc das direkte starten davon kein problem mehr sein sollte.
lks
ich denke es ist eher an Gamer gerichtet. Aber war wohl bezahlbar und hat die Anforderungen meines Vor- Vorgängers erfüllt.
Ok, kein Thema.Das alte SSD Raid funktioniert noch. Habe die Info oben ergänzt. --> Das alte System konnte ich nach dem kopieren
auch noch ganz normal starten. Es sollte also noch eine laufende Kopie des Systems vorhanden sein.
Also dann würde ich glatt die beiden noch lauffähigen SSDs einbauen und dann eine davon austauschen gegen eineauch noch ganz normal starten. Es sollte also noch eine laufende Kopie des Systems vorhanden sein.
größere SSD und dann das ganze noch einmal machen mit der zweiten SSD, fertig. Das ist eine faire Chance das System
wieder flott zu bekommen und es auch gleich auf zu rüsten!
Firmware von SSD, MB und HBA sind auf dem aktuellen Stand (Stand letzte Woche Montag)
Das ist ebenso wichtig denn dadurch werden eventuell schon gelöste Probleme voll erledigt und ausgeschlossen!Gruß
Dobby
Und wie groß sind die partitionen ais denen die raids zusammengebaur wurden (/dev/sdxy)
Welche version der Metadaten ist auf dem raid?
Wie finde ich das raus?mdadm --detail
Zitat von @TrialAndError:
EDIT 2: Irgend was übersehe ich gerade. Wenn ich das in der Anleitung richtig sehe, dann sollte mdadm --grow doch die raid Partitionen auf den Platten vergrößern oder muss ich das mit fdisk manuell machen?
EDIT 2: Irgend was übersehe ich gerade. Wenn ich das in der Anleitung richtig sehe, dann sollte mdadm --grow doch die raid Partitionen auf den Platten vergrößern oder muss ich das mit fdisk manuell machen?
Die grow-option vergrößert oder verklenert das Raid nur nnerhalb der Größe der physikkalischen Partition /dev/sdxy.
Wenn Du die genauso groß ist wie vorher, mußt du erstmal mit fdisk/gdisk/parted/gpareted/etc. die physiklaischen Partitionen größer machen, bevor Du mit mdadm --grow das Raid vergrößern kannst.
In dieser Anleitung liest es sich so als müsste man eine Platte aus dem Array nehmen und dann mit fdisk die raid Partition vergrößern um es anschließend wieder im raid aufzunehmen.
Man muß die partition nicht entfernen und wieder aufnehmen. Man kann sie direkt größer machen. Ansonsten wird resynchronisiert.
Kann mir jemand nen Tipp geben, der das schon mal gemacht hat?
Somit geschehen.
lks
Zitat von @TrialAndError:
/dev/sdq1 linux-raid 4,66GiB
/dev/sdq2 linux-swap 4,66 GiB
/dev/sdq3 linux-raid 49,39 GiB
nicht zugewiesen: 179,78 GiB
/dev/sdq1 linux-raid 4,66GiB
/dev/sdq2 linux-swap 4,66 GiB
/dev/sdq3 linux-raid 49,39 GiB
nicht zugewiesen: 179,78 GiB
Du hast offnesichtlich die neune RAID-Partiitionen genauso groß gemacht wie die vorherigen. Du hättest sie größer machen müssen, damit Du dann anschließend mit "mdadm -grow" das raid auch vergrößern kannst.
Es gibt nun mehrere Möglichkeiten:
- gparted
Du boostest mit knoppix und verschiebst/vergrößerst die Partitionen mit gparted.
- raid aufbrechen udn neu zusammenbauen.
Du nimmst die einen Hälfte des RAIDs wieder weg. Partitionierst die entsprechende SSD neu mit den gewünschten Zielgrößen! Danach nimmst Du die Partitionen wieder in das RAID auf. nach er Synchronisation wirfst Du die '"kleinere Hälfte" des RAIDs raus und partitionierst die auch neu. Danach ins RAID aufnehmen, synchronisation abwarten. Anschließen mit mdadm -grow RAID auf maximum aufblasen und anschließend mit resize2fs oder dem jeweils entsprechenden Tool Deines ausgewählten Filesystems Dein dateisystem vergrößern.
#mdadm --detail
Version: 1.2
Version: 1.2
Du solltest das mdadm --detail für die jeweiligen raids machen. Also:
# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed May 10 15:10:24 2017
Raid Level : raid1
Array Size : 4192192 (4.00 GiB 4.29 GB)
Used Dev Size : 4192192 (4.00 GiB 4.29 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Mon Aug 28 00:24:55 2017
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : dagobert:0 (local to host dagobert)
UUID : b3755415:faacd74f:5fca311d:bdac93df
Events : 282
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
2 8 1 1 active sync /dev/sda1
# mdadm --detail /dev/md1
...
ausführen.
Zitat von @TrialAndError:
baue jetzt erst mal wieder die alten Platten ein und beginne noch mal von vorne.
baue jetzt erst mal wieder die alten Platten ein und beginne noch mal von vorne.
Dann machst Du das folgendermaßen:
- boote mit Live-system (z.B. knoppix)
- Stecke eine "alte" und eine neue Platte ein.
- Falls die RAIDs automatisch loslaufen solltest Du diese mit mdadm --stop anhalten!
- kopiere mit ddrescue die alte auf die neue Platte.
- Steck beide neuen Platten ein
- Starte die RAIDs auf der kopierten Platte.
- erzeuge auf der "leeren" neune Platte die Partitionsen in der Größe wie Du sie benötigst.
- füge diese Partitionen den RAIDs hinzu.
- warte auf Synchronisationsende.
- wirf die "kleine" Partitionen auys dem RAID
- repartitioniere die Platte
- füge die Partitionen dem RAId hinzu.
- vergrößerere mit -grow das RAID
- resize das filesystem.
lks
PS. Alternativ:
- bau alle Platten geleichzeitig rein.
- Boote vom livesystem.
- Kopiere mit ddrescue 1MB der Plattenanfänge der alten Platten auf die neuen (mbr + bootlader, i.d.R. grub).
- Erstelle die neuen RAIDs. mit gewünschten Größen
- kopiere mit rsync die jeweiligen RAIDs
- passe /etc/fstab auf die neuen uuids an.
- passe /boot/grub/grub.cfg (oder die passende datei für Deinen bootlader) an die neuen uuids an.
- booten und genießen.
Zitat von @TrialAndError:
Hier wurde das Ganze mit parted gemacht: https://superuser.com/questions/469117/resize-underlying-partitions-in-m ...
Dabei wurde aber auch die Platte aus dem RAID genommen.
Hier wurde das Ganze mit parted gemacht: https://superuser.com/questions/469117/resize-underlying-partitions-in-m ...
Dabei wurde aber auch die Platte aus dem RAID genommen.
du mußt einfach das RAID stoppen. bevor Du an den Partitionen rumwerkelst.
lks
* Starte die RAIDs auf der kopierten Platte. [???]
Bis hier hin ist alles ok. Aber ''cat /proc/mdstat'' zeigt mir jetzt keine RAIDs mehr an. In GParted sehen die Partitionen so weit ok aus.
Bis hier hin ist alles ok. Aber ''cat /proc/mdstat'' zeigt mir jetzt keine RAIDs mehr an. In GParted sehen die Partitionen so weit ok aus.
mdadm -A /dev/mdX /dev/sdaY missing
Vorher natürlich die alte Platte entfernen.
* erzeuge auf der "leeren" neune Platte die Partitionsen in der Größe wie Du sie benötigst.
Ich habe von den vorher erstellten Partitionen die /dev/sdr3 gelöscht und Plattenfüllend neu angelegt.
Ich habe von den vorher erstellten Partitionen die /dev/sdr3 gelöscht und Plattenfüllend neu angelegt.
o.k.
dann mit mdadm /dev/mdX --add /dev/sdr3 die Partition dem raid hinzufügen.
lks
Zitat von @TrialAndError:
Ja, ich habe die ganze Platte übertragen. Bin dabei dieser (https://www.030-datenrettung.de/datenrettung-linux-ddrescue-anleitung) Anleitung gefolgt.
Also noch mal von vorne?
Kann ich auch das alte System von einer der ursprünglichen Platten booten und die Platte mit der vergrößerten RAID Partition hinzufügen?
Ja, ich habe die ganze Platte übertragen. Bin dabei dieser (https://www.030-datenrettung.de/datenrettung-linux-ddrescue-anleitung) Anleitung gefolgt.
Also noch mal von vorne?
Kann ich auch das alte System von einer der ursprünglichen Platten booten und die Platte mit der vergrößerten RAID Partition hinzufügen?
Ja.
Ich sehe dabei aber das Risiko, dass er bei meinem Glück die original Platte überschreibt.
Wenn Du das alte System gebootet hast, überschreibt er da ncihts beim hinzufügen.
lks
Zitat von @TrialAndError:
Jetzt wollte ich die neue Platte /dev/sdq dem Array hinzufügen. Aber in ''/proc/mdstat'' steht:
Müsste da jetzt nicht eigentlich die Platte stehen, von der ich gebootet habe? Also sdr???
Jetzt wollte ich die neue Platte /dev/sdq dem Array hinzufügen. Aber in ''/proc/mdstat'' steht:
> root@copie:~# cat /proc/mdstat
> Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
> md0 : active raid1 sdq1[1]
> 4877312 blocks super 1.2 [2/1] [_U]
>
> md1 : active raid1 sdq3[1]
> 51747840 blocks super 1.2 [2/1] [_U]
>
> unused devices: <none>
Offensichtlich hast Du die RAIDs 8bzw. deren Superblocks) auf der neuen SSD nicht gelöscht.
Was sagt denn "cat /proc/mounts"
Was passiert denn jetzt, wenn ich die original Platte /dev/sdr hinzufüge? Synct er mir dann die Daten von der original Platte auf die neue Platte oder überschreibt er dann die laufende Platte?
Ja nicht hinzufügen. So wie das aussieht, laufen die RAIDS auf der neuen Platte.
SChau mal, welche Filesystem er von welchen devicces gemountett hat (cat /proc/mounts). dann sehen wir weiter.
lks
Moin
ja, denn dadurch verschwinden die Superblocks nicht.
Nicht unbedingt.
Die Kiste hat ja vom "neuen" RAID gebootet, wie es aussieht. Ist denn das System, daß da läuft o.k. und vollständig?. wenn ja, dann kannst Du das auf die neuen Größen anpassen. da mußt du nichts mehr kopieren, sondern nur noch die andere SSd in das RAID einbinden. Am besten überprüfst Du, ob /dev/sdr alle Dateien hat, die Du brauchst. Dann sehen wir weiter.
lks
Zitat von @TrialAndError:
Naja, habe in gparted die Partitionen gelöscht und neu angelegt.
Da habe ich es mir wohl zu einfach gemacht.
Offensichtlich hast Du die RAIDs 8bzw. deren Superblocks) auf der neuen SSD nicht gelöscht.
Naja, habe in gparted die Partitionen gelöscht und neu angelegt.
Da habe ich es mir wohl zu einfach gemacht.
ja, denn dadurch verschwinden die Superblocks nicht.
Also Kiste noch mal neu starten und Platte komplett formatieren? Oder lässt sich das aus dem laufenden System heraus beheben?
Nicht unbedingt.
Die Kiste hat ja vom "neuen" RAID gebootet, wie es aussieht. Ist denn das System, daß da läuft o.k. und vollständig?. wenn ja, dann kannst Du das auf die neuen Größen anpassen. da mußt du nichts mehr kopieren, sondern nur noch die andere SSd in das RAID einbinden. Am besten überprüfst Du, ob /dev/sdr alle Dateien hat, die Du brauchst. Dann sehen wir weiter.
lks
Zitat von @TrialAndError:
Auch wenn es da steht, aber es kann nicht von der neuen Platte gebootet sein.
Ich habe zwischenzeitlich (neben einem schnellen Abendessen) die Platte noch mal neu formatiert (msdos -> wie auch zuvor).
Die Kiste hat ja vom "neuen" RAID gebootet, wie es aussieht. Ist denn das System, daß da läuft o.k. und vollständig?
Auch wenn es da steht, aber es kann nicht von der neuen Platte gebootet sein.
Ich habe zwischenzeitlich (neben einem schnellen Abendessen) die Platte noch mal neu formatiert (msdos -> wie auch zuvor).
Was genau meinst Du mit formattiert? partoirtion gelöscht udn neu angelegt? Dann bleibt sowohl filesystem als auch RAID-Superblock erhlten.
nur ein ddrescue /dev/zero /dev/sdX löscht alle szuverlässig.
Es sieht aber immer noch so aus als würde er von der Platte starten. Da die Platte formatiert ist kann das aber nicht sein. Kann das eventuell ein mapping Problem sein? Also, dass die alte SSD vorher sdq war und die neue jetzt ebenfallst als sdq erkannt wird?
Um das festzustellen, höng einfach mal die alte Platte raus und starte nur mit der Platte die als /dev/sdr eingebunden ist. andererseits muß er die sdr3 als RAID gebootet haben, weil die RAID-größer zur Partitionsgröße paßt.
Andererseits sollten das ja die uuids ausschließen und die passen ja auch alle zur neuen Platte.
wenn die uuids gleich sind, kann es sein, daß er bei der "richtigen" UUId auf das falsche device zeigt.
Nach dem ich die Platte jetzt formatiert habe habe ich noch mal die UUIDs abgefragt. Die sind immer noch identisch mit der von eben. Ich hätte erwartet, dass die Partition /dev/sdq1 jetzt eine neue UUID hat.
???
Am besten überprüfst Du, ob /dev/sdr alle Dateien hat, die Du brauchst.
Wie meinst du das? /dev/sdr3 ist ja eine RAID Partition.Die ist als md1 eingebunden und gemountet, wenn man Den obigen Ausgaben trauen darf.
Von welcher Platte das System jetzt auch immer gestartet ist. Da sind anscheinend alle Daten da. Zumindest die 30Gb Postgres DB sind da.
Um das ganz in einem definierten Zustand zu haben solltest Du folgendes tun:
- Bau die alten SSd raus.
- Laß nur die eine neue SSD drin, die als sdr oben zu sehen war.
- Schau ob das System bootet und alle daten da sind, wenn es gebootet hat.
- Wenn es nicht bootet, nimmst Du ein knoppix o.ä. und löscht mit ddrescue /dev/zero /dev/sdX die komplette SSD. und bootest anschließend mit der alten SSD. udn schaust, was als RAID-member udn root/boot-filesystem angezeigt wird.
lks
lks
Zitat von @TrialAndError:
so, das RAID läuft jetzt mit beiden neuen SSDs.
Ich nehme an, dass ich jetzt mit dem zuvor probierten Befehl ''mdadm --grow -z max /dev/md1'' das RAID md1 auf die volle Partitionsgröße ausdehnen kann.
so, das RAID läuft jetzt mit beiden neuen SSDs.
cat /proc/mdstat
> Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
> md0 : active raid1 sdr1[3] sdq1[2]
> 4877312 blocks super 1.2 [2/2] [UU]
>
> md1 : active raid1 sdr3[3] sdq3[2]
> 51747840 blocks super 1.2 [2/2] [UU]
>
> unused devices: <none>
>
Ich nehme an, dass ich jetzt mit dem zuvor probierten Befehl ''mdadm --grow -z max /dev/md1'' das RAID md1 auf die volle Partitionsgröße ausdehnen kann.
Ja
Ich tippe mal, danach muss ich noch das Dateisystem vergrößern. Laut parted ist es ein ext4.
Ja mt resize2fs.
lks