Discussion:
[E1]: Raid-HDDs komplett austauschen
(zu alt für eine Antwort)
Rolf Bensch
2020-06-03 17:40:14 UTC
Permalink
Hallo zusammen,

es ist geplant ein einem Eis1 ein Software-Raid1 komplett durch größere
Festplatten zu ersetzen. Problem hierbei: für das neue Raid1 steht
aktuell nur 1 SATA-Port zur Verfügung. Wie mache ich das am besten?

Meine Idee:
- Backup
- mdadm stop und deaktivieren (geht das so einfach?)
- Shutdown
- eine Platte des bestehenden Raids entfernen
- 2 neue Platten einbauen
- Start des Eis1
- mit mdadm neues Raid1 aktivieren
- Daten von alter Raid-Platte umkopieren
- shutdown
- 2. Platte des alten Raids entfernen
- restart
fertig

Könnte das so funktionieren? Oder besser erst _ein_ neues Laufwerk rein
=> Daten kopieren => ausbauen des alten Raid => 2. neue Platte rein =>
Raid-Verbund herstellen?

Grüße Rolf
Marcus Röckrath
2020-06-03 17:55:49 UTC
Permalink
Hallo Rolf,
Post by Rolf Bensch
es ist geplant ein einem Eis1 ein Software-Raid1 komplett durch größere
Festplatten zu ersetzen. Problem hierbei: für das neue Raid1 steht
aktuell nur 1 SATA-Port zur Verfügung. Wie mache ich das am besten?
- Backup
- mdadm stop und deaktivieren (geht das so einfach?)
- Shutdown
- eine Platte des bestehenden Raids entfernen
- 2 neue Platten einbauen
- Start des Eis1
- mit mdadm neues Raid1 aktivieren
- Daten von alter Raid-Platte umkopieren
Dabei Änderns sich duie UUIDs und dann passt es in der fstab nicht mehr,
also wird wohl das root-Dateisystem beim Boot nicht mehr gefunden.

Ich würde nacheinander jeweils eine Paltte tauschen, wie es in der
eisfair-Doku für das Desaster recovry beschrieben ist.

Also eine Plate als fail markieren und aus dem Raid nehmen; runterfahren,
Platte ausbauen, neue Platte rein, ...
--
Gruß Marcus
[eisfair-Team]
Marcus Röckrath
2020-06-03 18:15:56 UTC
Permalink
Hallo Rolf,
Post by Rolf Bensch
es ist geplant ein einem Eis1 ein Software-Raid1 komplett durch größere
Festplatten zu ersetzen. Problem hierbei: für das neue Raid1 steht
aktuell nur 1 SATA-Port zur Verfügung. Wie mache ich das am besten?
- Backup
- mdadm stop und deaktivieren (geht das so einfach?)
- Shutdown
- eine Platte des bestehenden Raids entfernen
- 2 neue Platten einbauen
- Start des Eis1
- mit mdadm neues Raid1 aktivieren
- Daten von alter Raid-Platte umkopieren
Dabei Änderns sich duie UUIDs und dann passt es in der fstab nicht mehr,
also wird wohl das root-Dateisystem beim Boot nicht mehr gefunden.

Ich würde nacheinander jeweils eine Paltte tauschen, wie es in der
eisfair-Doku für das Desaster recovry beschrieben ist.

Also eine Plate als fail markieren und aus dem Raid nehmen; runterfahren,
Platte ausbauen, neue Platte rein, ...
--
Gruß Marcus
[eisfair-Team]
Thomas Zweifel
2020-06-04 12:12:09 UTC
Permalink
Hallo Marcus
Post by Marcus Röckrath
Ich würde nacheinander jeweils eine Paltte tauschen, wie es in der
eisfair-Doku für das Desaster recovry beschrieben ist.
Also eine Plate als fail markieren und aus dem Raid nehmen; runterfahren,
Platte ausbauen, neue Platte rein, ...
Ergibt irgendwie keinen Sinn, die Partitionen aus dem Raid zu entfernen
(fail, remove), wenn man die Platte danach ohnehin ausbaut.

Diesen Teil kann man IMO aus der Doku streichen.




Gruss Thomas
Rolf Bensch
2020-06-04 12:45:57 UTC
Permalink
Hallo Marcus,

genau das was ich gesucht habe :-))

Danke

Gruß Rolf
Marcus Röckrath
2020-06-04 13:07:19 UTC
Permalink
Hallo Rolf,
Post by Rolf Bensch
genau das was ich gesucht habe :-))
Gut, pass ein wenig auf die bespielhaften Laufwerks/Partitions-Bezeichnungen
auf; das ist nicht unbedingt komplett sauber durchgehalten.

Insbesondere vergewissere dich, beim Übertragen der Partitionstabelle, dass
Quelle und Ziel nicht vertauscht sind.
--
Gruß Marcus
[eisfair-Team]
Rolf Bensch
2020-06-04 13:29:07 UTC
Permalink
Ich geb alles :-))
Olaf Jaehrling
2020-06-03 20:01:45 UTC
Permalink
Hallo Rolf,
Post by Rolf Bensch
Hallo zusammen,
es ist geplant ein einem Eis1 ein Software-Raid1 komplett durch größere
Festplatten zu ersetzen. Problem hierbei: für das neue Raid1 steht
aktuell nur 1 SATA-Port zur Verfügung. Wie mache ich das am besten?
Genau das habe ich letzte Woche bei 3 Raid-1 auch gemacht.
Ich diesem Beispiel nehme ich mal an dass das vorhandene Raid ein raid-1
mit den Festplatten sda und sdb. Die neuen Platten sind sdc und sdd
Vorlage bei mir war die eisfair-Doku:
https://www.eisfair.org/fileadmin/eisfair/doc/node4.html#SECTION00428000000000000000

- sgdisk -Z /dev/sdc
- gdisk /dev/sdc -> Partition erstellen lt. Doku "Einrichten der ersten
Festplatte"
Mehr aus der Doku erstmal noch nicht. Die Platte schon auf die neue
Grüße einrichten

Danach
- mdadm --zero-superblock /dev/sdc1

Nun wird das alte raid bearbeitet und die 2. Platte daraus entfernt
- mdadm --manage --set-faulty /dev/md0 /dev/sdb1
- mdadm --manage /dev/md0 -r /dev/sdb1
- Die Platte sdb in Ruhe lassen, somit hat man alle Daten noch zur
Verfügung wenn was schief gehen sollte


Die neue Platte in das alte Raid integrieren:
mdadm --manage /dev/md0 -a /dev/sdc1

Sync abwarten und prüfen mit
cat /proc/mdstat

Wenn fertig die Platte sdb vom Sata-Port und Strom abziehen und dafür
die 2. neue Platte einbauen (sdd).
- sgdisk -Z /dev/sdd
- gdisk /dev/sdc -> Partition erstellen lt. Doku "Einrichten der ersten
Festplatte"
Mehr aus der Doku erstmal noch nicht. Die Platte schon auf die neue
Grüße einrichten
- mdadm --zero-superblock /dev/sdd1

Nun ist die 2. Platte für das Raid vorbereitet. und kann in das Raid
integriert werden.
Zuerst sda entfernen
- mdadm --manage --set-faulty /dev/md0 /dev/sda1
- mdadm --manage /dev/md0 -r /dev/sda1

dann die neue Platte (sdd) hinzufügen
mdadm --manage /dev/md0 -a /dev/sdd1

Wieder Syncen lassen.

Nun hast die das Raid wieder vollständig. Nur leider ist das Raid noch
in der alten Größe
Anpassen mit
mdadm --grow -z max /dev/md0
Nach sync (geht schnell) ist das raid zwar größer, aber noch nicht das
Filesystem.
Wenn du das raid mit ext4 formatiert hast geht das sogar im gemounteten
zustand (online) mit
resize2fs /dev/md0

Die Platte sda vom Strom und sataport trennen.

Danach solltest du ein Kernelupdate machen, damit das alles in die
initrd kommt.
Du kannst den gleichen Kernel nochmal drüberbügeln. Wenn du das nicht
willst, sag beischeid :)

Bitte noch beachten, dass sich die uuid geändert haben könnte und du das
in der /etc/fstab anpassen musst.
bklid /dev/md0 zeigt die ID an


Gruß

Olaf




Gruß

Olaf
Rolf Bensch
2020-06-04 12:47:22 UTC
Permalink
Hallo Olaf,

Wow! Ssehr detailliert und mit Praxis-Background. Das hilft sicher.
Warte noch auf die Lieferung.

Danke

Gruß Rolf
Rolf Bensch
2020-06-27 11:12:37 UTC
Permalink
Hallo Olaf,
Post by Olaf Jaehrling
Nun hast die das Raid wieder vollständig. Nur leider ist das Raid noch
in der alten Größe
Anpassen mit
mdadm --grow -z max /dev/md0
die Drives sind jetzt getauscht und gesynct, mit --grow habe ich aber
Schwierigkeiten:

ibs-server # mdadm --grow -z max /dev/md0
mdadm: component size of /dev/md0 unchanged at 976758912K

ibs-server # mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Wed Jan 30 19:28:24 2013
Raid Level : raid1
Array Size : 976758912 (931.51 GiB 1000.20 GB)
Used Dev Size : 976758912 (931.51 GiB 1000.20 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent

Intent Bitmap : Internal

Update Time : Sat Jun 27 13:03:38 2020
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Consistency Policy : unknown

UUID : 5f172df9:10613a1e:be99f867:ce7966d1
Events : 0.9795

Number Major Minor RaidDevice State
0 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
ibs-server # mdadm --grow --raid-devices=2 /dev/md0
mdadm: /dev/md0: no change requested

Das Device ist nicht gemountet. Die neuen Drives sind knapp 2GB groß:

ibs-server # fdisk -l /dev/sdc
Disk /dev/sdc: 1.84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 9F397FBF-4E2C-5A48-8057-73CE302F1D67

Device Start End Sectors Size Type
/dev/sdc1 2048 1953519999 1953517952 931.5G Linux RAID

Im Netz ist zu lesen, dass ich das Raid zunächst auftrennen soll, dann
eine Platte neu Partitionieren und dann wieder in das Raid einbinden
kann. Ist das so sinnvoll oder gibt es einen besseren Weg?

Grüße Rolf
Marcus Röckrath
2020-06-27 11:26:22 UTC
Permalink
Hallo Rolf,
Post by Rolf Bensch
Post by Olaf Jaehrling
Nun hast die das Raid wieder vollständig. Nur leider ist das Raid noch
in der alten Größe
Anpassen mit
mdadm --grow -z max /dev/md0
die Drives sind jetzt getauscht und gesynct, mit --grow habe ich aber
ibs-server # mdadm --grow -z max /dev/md0
mdadm: component size of /dev/md0 unchanged at 976758912K
ibs-server # mdadm --detail /dev/md0
Version : 0.90
Creation Time : Wed Jan 30 19:28:24 2013
Raid Level : raid1
Array Size : 976758912 (931.51 GiB 1000.20 GB)
Used Dev Size : 976758912 (931.51 GiB 1000.20 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Sat Jun 27 13:03:38 2020
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : unknown
UUID : 5f172df9:10613a1e:be99f867:ce7966d1
Events : 0.9795
Number Major Minor RaidDevice State
0 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
ibs-server # mdadm --grow --raid-devices=2 /dev/md0
mdadm: /dev/md0: no change requested
ibs-server # fdisk -l /dev/sdc
Disk /dev/sdc: 1.84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 9F397FBF-4E2C-5A48-8057-73CE302F1D67
Device Start End Sectors Size Type
/dev/sdc1 2048 1953519999 1953517952 931.5G Linux RAID
Deine Vergrößerung, die ich noch nie selbst durchgezogen habe, muss IMHO in
zwei Schritten geschehen.

Es muss zunächst die Partitionen auf dem Datenträger aufgezogen werden,
danach dann das Dateisystem in der Partition.

Thomas Zweifel hat das IMHO hier mal in der Newsgroup sehr schön
beschrieben, suche doch mal im Forum.
--
Gruß Marcus
[eisfair-Team]
Rolf Bensch
2020-06-27 12:02:32 UTC
Permalink
Hallo Marcus,
Post by Marcus Röckrath
Hallo Rolf,
Post by Rolf Bensch
Post by Olaf Jaehrling
Nun hast die das Raid wieder vollständig. Nur leider ist das Raid noch
in der alten Größe
Anpassen mit
mdadm --grow -z max /dev/md0
die Drives sind jetzt getauscht und gesynct, mit --grow habe ich aber
ibs-server # mdadm --grow -z max /dev/md0
mdadm: component size of /dev/md0 unchanged at 976758912K
ibs-server # mdadm --detail /dev/md0
Version : 0.90
Creation Time : Wed Jan 30 19:28:24 2013
Raid Level : raid1
Array Size : 976758912 (931.51 GiB 1000.20 GB)
Used Dev Size : 976758912 (931.51 GiB 1000.20 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Sat Jun 27 13:03:38 2020
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : unknown
UUID : 5f172df9:10613a1e:be99f867:ce7966d1
Events : 0.9795
Number Major Minor RaidDevice State
0 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
ibs-server # mdadm --grow --raid-devices=2 /dev/md0
mdadm: /dev/md0: no change requested
ibs-server # fdisk -l /dev/sdc
Disk /dev/sdc: 1.84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 9F397FBF-4E2C-5A48-8057-73CE302F1D67
Device Start End Sectors Size Type
/dev/sdc1 2048 1953519999 1953517952 931.5G Linux RAID
Deine Vergrößerung, die ich noch nie selbst durchgezogen habe, muss IMHO in
zwei Schritten geschehen.
Es muss zunächst die Partitionen auf dem Datenträger aufgezogen werden,
danach dann das Dateisystem in der Partition.
korrekt. "mdadm --grow" sollte zunächst die Partition vergrößern - das
scheitert aber mit "component size of /dev/md0 unchanged at 976758912K".
Post by Marcus Röckrath
Thomas Zweifel hat das IMHO hier mal in der Newsgroup sehr schön
beschrieben, suche doch mal im Forum.
Ich fand bereits "Defekte RAID Platte durch größere Neue ersetzen",
konnte darin aber keine andere Vorgehensweise herauslesen. Thomas
verwendet eine minimal andere Syntax als Olaf, das Ergebnis ist aber
identisch:

ibs-server # mdadm -G -zmax /dev/md0
mdadm: component size of /dev/md0 unchanged at 976758912K

Grüße Rolf
Marcus Röckrath
2020-06-27 12:23:50 UTC
Permalink
Hallo Rolf,
Post by Rolf Bensch
Post by Marcus Röckrath
Deine Vergrößerung, die ich noch nie selbst durchgezogen habe, muss IMHO
in zwei Schritten geschehen.
Es muss zunächst die Partitionen auf dem Datenträger aufgezogen werden,
danach dann das Dateisystem in der Partition.
korrekt. "mdadm --grow" sollte zunächst die Partition vergrößern - das
scheitert aber mit "component size of /dev/md0 unchanged at 976758912K".
Muss dazu nicht vorher die Partionstabelle der einzelnen Platten geändert
werden, also auf jeder Platte des Raids die Partionion sdc1 und sdd1
aufgezogen werden, bevor man an md0 rangeht?
--
Gruß Marcus
[eisfair-Team]
Rolf Bensch
2020-06-27 12:48:57 UTC
Permalink
Hallo Marcus,
Post by Marcus Röckrath
Hallo Rolf,
Post by Rolf Bensch
Post by Marcus Röckrath
Deine Vergrößerung, die ich noch nie selbst durchgezogen habe, muss IMHO
in zwei Schritten geschehen.
Es muss zunächst die Partitionen auf dem Datenträger aufgezogen werden,
danach dann das Dateisystem in der Partition.
korrekt. "mdadm --grow" sollte zunächst die Partition vergrößern - das
scheitert aber mit "component size of /dev/md0 unchanged at 976758912K".
Muss dazu nicht vorher die Partionstabelle der einzelnen Platten geändert
werden, also auf jeder Platte des Raids die Partionion sdc1 und sdd1
aufgezogen werden, bevor man an md0 rangeht?
das ist das, was ich aktuell im Netz zu lesen bekomme. Das aus den
Eisfair-Unterlagen stammende "sgdisk -R ..." unterbindet das aber.

Ich versuche jetzt mal den Weg wie im Netz empfohlen:

# Device aus dem Raid aushängen
mdadm /dev/md0 --fail /dev/sdd1 --remove /dev/sdd1

# Partition löschen und neu anlegen
fdisk /dev/sdd

# Check des fs:
e2fsck -f /dev/sdd1

# wieder einhängen
mdadm -a /dev/md0 /dev/sdd1

Sync abwarten (läuft gerade) und dann das Gleiche nochmals für die
andere Platte. Ich vermute, dass danach noch ein resize2fs fällig wird.

Grüße Rolf
Marcus Röckrath
2020-06-27 12:51:38 UTC
Permalink
Hallo Rolf,
Post by Rolf Bensch
das ist das, was ich aktuell im Netz zu lesen bekomme. Das aus den
Eisfair-Unterlagen stammende "sgdisk -R ..." unterbindet das aber.
Das serhält aber die UUIDs!
--
Gruß Marcus
[eisfair-Team]
Rolf Bensch
2020-06-28 07:33:44 UTC
Permalink
Hallo Marcus,
Post by Marcus Röckrath
Hallo Rolf,
Post by Rolf Bensch
das ist das, was ich aktuell im Netz zu lesen bekomme. Das aus den
Eisfair-Unterlagen stammende "sgdisk -R ..." unterbindet das aber.
Das serhält aber die UUIDs!
meine Vorgehensweise hat jetzt funktionioert, auch die UUIDs blieben
erhalten. Ich musste aber auch nochmal das raid vergrößern (hat sehr
lange gedauert). Meine abschließende Lösung ist:

# Device aus dem Raid aushängen
mdadm /dev/md0 --fail /dev/sdd1 --remove /dev/sdd1

# Partition löschen und neu anlegen
fdisk /dev/sdd

# Check des fs:
e2fsck -f /dev/sdd1

# wieder einhängen
mdadm -a /dev/md0 /dev/sdd1

#Sync abwarten
watch cat /proc/mdstat

das Gleiche für die 2. Platte

#das Raid vergrößern
mdadm --greo -z max /dev/md0

#Sync abwarten (hat sehr lange gedauert)
watch cat /proc/mdstat

# filesystem anpassen
resize2fs /dev/md0

Danach war das raid1 vollständig erhalten (einschl. UUIDs) und die
Partition hatte die volle Kapazität des neuen Laufwerks.

Grüße Rolf
Olaf Jaehrling
2020-06-28 17:13:05 UTC
Permalink
Hallo Rolf,

Rolf Bensch schrieb am 28.06.20 um 09:33:
fangen wir mal der Reihe nach an.

Was sagt fdisk -l /dev/sdd
Was sagt mdadm --detail /dev/md0


Gruß

Olaf
Rolf Bensch
2020-06-29 08:22:47 UTC
Permalink
Hallo Olaf,
Post by Marcus Röckrath
Hallo Rolf,
fangen wir mal der Reihe nach an.
Was sagt fdisk -l /dev/sdd
Was sagt mdadm --detail /dev/md0
gerne. Aber es gibt aktuell KEIN Problem mehr. Ich hatte hier nur
nochmal meine Erfahrungen der Baustelle für die Nachwelt abgelegt.

Gruß Rolf


ibs-server # fdisk -l
...

Disk /dev/sdc: 1.84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 9F397FBF-4E2C-5A48-8057-73CE302F1D67

Device Start End Sectors Size Type
/dev/sdc1 2048 3907029134 3907027087 1.8T Linux filesystem


Disk /dev/sdd: 1.84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 9F397FBF-4E2C-5A48-8057-73CE302F1D67

Device Start End Sectors Size Type
/dev/sdd1 2048 3907029134 3907027087 1.8T Linux filesystem

...

Disk /dev/md0: 1.84 TiB, 2000397795328 bytes, 3907026944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

ibs-server # mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Wed Jan 30 19:28:24 2013
Raid Level : raid1
Array Size : 1953513472 (1863.02 GiB 2000.40 GB)
Used Dev Size : 1953513472 (1863.02 GiB 2000.40 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent

Intent Bitmap : Internal

Update Time : Mon Jun 29 10:21:22 2020
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Consistency Policy : unknown

UUID : 5f172df9:10613a1e:be99f867:ce7966d1
Events : 0.15140

Number Major Minor RaidDevice State
0 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
Olaf Jaehrling
2020-06-29 08:32:46 UTC
Permalink
Hallo Rolf,
Post by Rolf Bensch
gerne. Aber es gibt aktuell KEIN Problem mehr. Ich hatte hier nur
nochmal meine Erfahrungen der Baustelle für die Nachwelt abgelegt.
Ahh, ok. Ich meinte gelesen zu haben, dass du mit dem grow noch ein
Problem hattest.

Alles klar, dann hat sich das erledigt.

Danke und Gruß

Olaf
--
Packageserver: https://ojaehrling.de/eis/index.txt
Hilix
2020-06-29 07:27:47 UTC
Permalink
Hallo Rolf,
vielen Dank für die Beschreibungen Deiner Vorgehenweisen zum Tausch von (HDD->SDD) Platten im RAID. Sehr interessant.
Was ich noch nicht verstanden habe: Hattest Du einmal im Rahmen des Tausches einen funktionierenden RAID-Verbund aus HDD und SDD
(mit allen Daten erhalten)? (Marcus meinte mal, dass die Disktypen nicht kompatibel sein könnten?
Post by Rolf Bensch
# Partition löschen und neu anlegen
fdisk /dev/sdd
Die neu angelegte sdd1 umfasst jetzt die ganze Platte?
(müsste nicht vor dem e2fsck ein mkfs stehen?)
Grüße./Hilmar.
Marcus Röckrath
2020-06-29 07:46:39 UTC
Permalink
Hallo Hilmar,
Post by Hilix
vielen Dank für die Beschreibungen Deiner Vorgehenweisen zum Tausch von
(HDD->SDD) Platten im RAID. Sehr interessant. Was ich noch nicht
verstanden habe: Hattest Du einmal im Rahmen des Tausches einen
funktionierenden RAID-Verbund aus HDD und SDD (mit allen Daten erhalten)?
Wenn die erste Platte getauscht und der Sync gelaufen ist, hat man doch
einen RAID-Verbund.
Post by Hilix
(Marcus meinte mal, dass die Disktypen nicht kompatibel sein könnten?
Hast du den Beitrag genauer im Kopf oder im Forum gefunden? Ich weiß jetzt
nicht was du meinst oder ich gesagt habe.
--
Gruß Marcus
[eisfair-Team]
Rolf Bensch
2020-06-29 08:29:32 UTC
Permalink
Post by Marcus Röckrath
Hallo Rolf,
vielen Dank für die Beschreibungen Deiner Vorgehenweisen zum Tausch von
(HDD->SDD) Platten im RAID. Sehr interessant.
Was ich noch nicht verstanden habe: Hattest Du einmal im Rahmen des
Tausches einen funktionierenden RAID-Verbund aus HDD und SDD (mit allen
Daten erhalten)? (Marcus meinte mal, dass die Disktypen nicht kompatibel
sein könnten?
Ja. Zunächst ein synchronisertes Raid mit hdd/ssd später dann auch ein
ssd/ssd-Raid. (sync dauert jeweils ca. 2 Std/TB). Beim ssd/ssd-Raid
konnte ich dann nicht mehr das Raid auf die Kapazität des ssd-Laufwerk
erweitern. Daher der Zwischenschritt mit fdisk (würde ich in Zukunft
direkt machen)
Post by Marcus Röckrath
Post by Rolf Bensch
# Partition löschen und neu anlegen
fdisk /dev/sdd
Die neu angelegte sdd1 umfasst jetzt die ganze Platte?
(müsste nicht vor dem e2fsck ein mkfs stehen?)
Hmm, ja. Allerdings hatte ich bereits ein ext4 Filesystem auf der
Platte. fdisk hatte rückgefragt ob dieses verwendet werden soll. Ich
hatte das bestätigt, so konnte mkfs entfallen.

Grüße Rolf
Thomas Zweifel
2020-06-04 12:07:58 UTC
Permalink
Hallo Rolf
Post by Rolf Bensch
Hallo zusammen,
es ist geplant ein einem Eis1 ein Software-Raid1 komplett durch größere
Festplatten zu ersetzen. Problem hierbei: für das neue Raid1 steht
aktuell nur 1 SATA-Port zur Verfügung. Wie mache ich das am besten?
Herunterfahren
Erste Platte austauschen
Neue Platte passend Partitionieren
Resync anstossen, wenn fertig lilo

Herunterfahren
Zweite Platte austauschen
Gemäss der erste Platte Partitionieren
Resync anstossen, wenn fertig lilo

md vergrössern
Dateisystem vergrössern

Fertig

(Wenn der Eis nicht auf diesen Platten installiert ist, kann der lilo
Aufruf entfallen.)



Gruss Thomas
Rolf Bensch
2020-06-04 12:56:29 UTC
Permalink
Hallo Thomas,
Post by Marcus Röckrath
Hallo Rolf
Post by Rolf Bensch
Hallo zusammen,
es ist geplant ein einem Eis1 ein Software-Raid1 komplett durch größere
Festplatten zu ersetzen. Problem hierbei: für das neue Raid1 steht
aktuell nur 1 SATA-Port zur Verfügung. Wie mache ich das am besten?
Herunterfahren
ohne vorher etwas am Raid1 zu verändern?
Post by Marcus Röckrath
Erste Platte austauschen
Neue Platte passend Partitionieren
Resync anstossen, wenn fertig lilo
Der Eis bootet zwar nicht vom Raid aber was sagt mdadm beim Booten zum
fehlenden Device? Bleibt das Raid in diesem Zustand lesbar?

Grüße Rolf
Marcus Röckrath
2020-06-04 13:09:04 UTC
Permalink
Hallo Rolf,
Post by Rolf Bensch
Der Eis bootet zwar nicht vom Raid aber was sagt mdadm beim Booten zum
fehlenden Device? Bleibt das Raid in diesem Zustand lesbar?
Wenn eine Platte aus dem RAID per fail/remove entfernt ist, wird eben mit
dem nun nur übrigen Einzeldevice das RAID assembliert.
--
Gruß Marcus
[eisfair-Team]
Thomas Zweifel
2020-06-04 13:23:34 UTC
Permalink
Hallo Rolf
Post by Rolf Bensch
Post by Thomas Zweifel
Post by Rolf Bensch
es ist geplant ein einem Eis1 ein Software-Raid1 komplett durch größere
Festplatten zu ersetzen. Problem hierbei: für das neue Raid1 steht
aktuell nur 1 SATA-Port zur Verfügung. Wie mache ich das am besten?
Herunterfahren
ohne vorher etwas am Raid1 zu verändern?
Richtig.
Post by Rolf Bensch
Post by Thomas Zweifel
Erste Platte austauschen
Neue Platte passend Partitionieren
Resync anstossen, wenn fertig lilo
Der Eis bootet zwar nicht vom Raid aber was sagt mdadm beim Booten zum
fehlenden Device? Bleibt das Raid in diesem Zustand lesbar?
Wenn eine Platte ausfällt sind die Daten noch verfügbar, beim Reboot
wird das Raid dann zwangsläufig dediziert (ohne Redundanz) an den Start
gebracht. ;-)





Gruss Thomas
Rolf Bensch
2020-06-26 17:18:44 UTC
Permalink
Hall zusammen,

der Umbau ist gestartet und das Chaos ist perfekt. Vermutlich hatte ich
ein Problem mit sgdisk:

ibs-server # sgdisk -R /dev/sdd /dev/sdc
Creating new GPT entries in memory.
Caution! Secondary header was placed beyond the disk's limits! Moving
the header, but other problems may occur!
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

Danach ein Restart und das Raid ist nicht mehr vorhanden:

ibs-server # cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5]
[raid4] [multipath]
unused devices: <none>

--- cut --

Ausgangslage war: /data ist ein raid1-Verbund aus /dev/sdc1 und
/dev/sdd1 jeweils:

Disk /dev/sdd: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC WD10EFRX-68J
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt

Ich hatte ausgeführt:
mdadm /dev/md0 --fail /dev/sdc1
mdadm /dev/md0 --remove /dev/sdc1

danach Austausch von sdc gegen eine SSD:

Disk /dev/sdc: 1.84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Es folgte "sgdisk -R /dev/sdd /dev/sdc" mit o. a. Fehlermeldung und
"sgdisk -G /dev/sdd". Danach Neustart. sdc1 ist danach nicht vorhanden.
"cat /proc/mdstat" listet kein md0 mehr (wo ist das raid?). Problem: die
Partition sdd1 (mit den Daten) ist auch nicht mehr vorhanden (bzw.
sichtbar).

Weiteres Problem: weil ich die Daten nach dieser Maßnahme nicht mehr
sehen konnte, hatte ich die ausgebaute sdc gegen die noch eingebaute sdd
getauscht - also quasi die alten Platten des Raid getauscht. Kurzzeitig
sah ich dann wieder md0, dach sgdisk und Neustart sehe ich auch auf der
2. Platte des alten raids keine Daten mehr.

Muss ich jetzt mit den neuen SSDs ein raid aufbauen und das Backup
bemühen oder habe ich noch eine bessere Chance mit den Daten aud den
alten raid-Platten?

Laut Netz tritt der sgdisk-Fehler bei unterschiedlichen Sektorgrößen der
Medien auf. Das scheint auch das Problem zu sein: während die alten
1TB-Platten mit 4k-Sektoren arbeiten, laufen die neuen 2TB SSDs mit 512
Bytes/Sektor.

Bitte um Unterstützung.

Vielen Dank

Rolf
Marcus Röckrath
2020-06-26 17:37:33 UTC
Permalink
Hallo Rolf,
Post by Rolf Bensch
Ausgangslage war: /data ist ein raid1-Verbund aus /dev/sdc1 und
Disk /dev/sdd: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC WD10EFRX-68J
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
mdadm /dev/md0 --fail /dev/sdc1
mdadm /dev/md0 --remove /dev/sdc1
Disk /dev/sdc: 1.84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Es folgte "sgdisk -R /dev/sdd /dev/sdc" mit o. a. Fehlermeldung
IMHO ist die Reihenfolge der Devices im sgdisk-Aufruf falsch.

Die neue Platte ist sdc, der sgdisk-Aufruf überträgt aber die
Partionstabelle von sdc auf sdd:

sgdisk -R Ziel Quelle

Jedenfalls lese ich die Manpage so.

Nachdem du das dann auch mit deiner zweiten Altplatte gemacht hast, hast du
möglicherweise nun auf beiden die Partitionstabelle zerstört.
--
Gruß Marcus
[eisfair-Team]
Rolf Bensch
2020-06-26 17:59:13 UTC
Permalink
Hallo Marcus,
Post by Marcus Röckrath
sgdisk -R Ziel Quelle
Jedenfalls lese ich die Manpage so.
Nachdem du das dann auch mit deiner zweiten Altplatte gemacht hast, hast du
möglicherweise nun auf beiden die Partitionstabelle zerstört.
das ist gruselig aber vermutlich real :-(( Wäre nicht auf die Idee
gekommen "Ziel" zuerst zu benennen.

Habe ich irgendeine Chance die alten Partitionstabelle (gpt)
wiederherzustellen?

Grüße Rolf
Marcus Röckrath
2020-06-26 18:43:55 UTC
Permalink
Hallo Rolf,
Post by Rolf Bensch
Post by Marcus Röckrath
sgdisk -R Ziel Quelle
Jedenfalls lese ich die Manpage so.
Nachdem du das dann auch mit deiner zweiten Altplatte gemacht hast, hast
du möglicherweise nun auf beiden die Partitionstabelle zerstört.
das ist gruselig aber vermutlich real :-(( Wäre nicht auf die Idee
gekommen "Ziel" zuerst zu benennen.
sgdisk [ options ] device
...
-R, --replicate=second_device_filename
Replicate the main device's partition table on the specified second
device. Note that the replicated partition table is an exact copy,
including all GUIDs; if the device should have its own unique GUIDs, you
should use the -G option on the new disk.

Hinter der Option R steht das Device das das Ziel der Replikation ist.
Post by Rolf Bensch
Habe ich irgendeine Chance die alten Partitionstabelle (gpt)
wiederherzustellen?
Wenn du die Werte der alten Partitionstabelle hast, könnte man die schlicht
neu anlegen. Bei DOS/MBR-Partitionstabelle habe ich das schon gemacht.

Wenn die Platte nur eine Partizion hatte, ist es doch wahrscheinlich, dass
diese vom Anfang bis Ende der Platte ging, wobei es nicht schlimm wäre,
wenn die neue Partition am Ende größer wäre.
--
Gruß Marcus
[eisfair-Team]
Rolf Bensch
2020-06-26 20:27:02 UTC
Permalink
Hallo Marcus,
Post by Marcus Röckrath
Hallo Rolf,
Post by Rolf Bensch
Post by Marcus Röckrath
sgdisk -R Ziel Quelle
Jedenfalls lese ich die Manpage so.
Nachdem du das dann auch mit deiner zweiten Altplatte gemacht hast, hast
du möglicherweise nun auf beiden die Partitionstabelle zerstört.
das ist gruselig aber vermutlich real :-(( Wäre nicht auf die Idee
gekommen "Ziel" zuerst zu benennen.
sgdisk [ options ] device
...
-R, --replicate=second_device_filename
Replicate the main device's partition table on the specified second
device. Note that the replicated partition table is an exact copy,
including all GUIDs; if the device should have its own unique GUIDs, you
should use the -G option on the new disk.
Hinter der Option R steht das Device das das Ziel der Replikation ist.
Post by Rolf Bensch
Habe ich irgendeine Chance die alten Partitionstabelle (gpt)
wiederherzustellen?
Wenn du die Werte der alten Partitionstabelle hast, könnte man die schlicht
neu anlegen. Bei DOS/MBR-Partitionstabelle habe ich das schon gemacht.
Wenn die Platte nur eine Partizion hatte, ist es doch wahrscheinlich, dass
diese vom Anfang bis Ende der Platte ging, wobei es nicht schlimm wäre,
wenn die neue Partition am Ende größer wäre.
Habe es mit testdisk reparieren können. Jetzt läuft die Synchronisation.

Danke für die Unterstützung.

Rolf
Olaf Jaehrling
2020-06-28 17:17:54 UTC
Permalink
Hallo Rolf,
Post by Rolf Bensch
Hallo Marcus,
Habe ich irgendeine Chance die alten Partitionstabelle (gpt)
wiederherzustellen?
tztztz. Ich hatte doch geschrieben die 1. HD des alten RAID nicht mehr
anfassen, falls etwas schief geht. :)
Aber du hast es ja zum Glück wieder hinbekommen.

Eine Platte immer schön zur Seite legen, bis das neue RAID so läuft wie
du es willst!

Gruß

Olaf
Post by Rolf Bensch
Grüße Rolf
Marcus Röckrath
2020-06-28 17:22:42 UTC
Permalink
Hallo Olaf,
Post by Olaf Jaehrling
Post by Rolf Bensch
Habe ich irgendeine Chance die alten Partitionstabelle (gpt)
wiederherzustellen?
tztztz. Ich hatte doch geschrieben die 1. HD des alten RAID nicht mehr
anfassen, falls etwas schief geht. :)
Aber du hast es ja zum Glück wieder hinbekommen.
Ich denke, er hatte großes Gottvertrauen, dass die Durchführung der exakt
gleichen Schritte beim zweitenmal dann korrekt läuft. ;-)
--
Gruß Marcus
[eisfair-Team]
Rolf Bensch
2020-06-29 08:31:10 UTC
Permalink
Hallo Olaf,
Post by Marcus Röckrath
Hallo Rolf,
Post by Rolf Bensch
Hallo Marcus,
Habe ich irgendeine Chance die alten Partitionstabelle (gpt)
wiederherzustellen?
tztztz. Ich hatte doch geschrieben die 1. HD des alten RAID nicht mehr
anfassen, falls etwas schief geht. :)
Aber du hast es ja zum Glück wieder hinbekommen.
Am besten lernt man eben durch [Bauch-]Schmerzen :-))

Grüße Rolf
Loading...