Ich habe ein Backup aller wichtigen Daten. Am Ende ist eine Wiederherstellung erforderlich. Aber ich möchte zuerst etwas ausprobieren, bevor ich diesen Weg gehe, und es ist eine gute Gelegenheit, etwas über all die Dinge zu lernen, die ich hier verwendet habe.
Ich habe einen MPT-SAS-Controller mit 8 SATA-Kanälen angeschlossen und zwei interne 2,5-Zoll-Festplattenschächte konfiguriert. Zwei davon wurden für SSD-Laufwerke verwendet, die nur zum Zwischenspeichern von LVM-Volumes verwendet werden.
6 1-TB-Festplatten werden für Datenteile auf Partition 3 verwendet, die als RAID5-Soft-Array konfiguriert ist.
Zwei davon wurden für Bootparts auf Partition 1 und Rootparts auf Partition 2 verwendet. Beide Bootparts sind ein einfaches RAID1 mit ext3 fs. Beide Bootparts sind ein RAID1 welches mit luks verschlüsselt ist und ein lvm vg xenrootdg mit mehreren lvs hat. Alle 6 Dataparts werden wie beschrieben als RAID5 verwendet. Das Raidvolume ist luks verschlüsselt und darauf ein lvm mit einem vg xendatadg. Nur auf dem RAID5 Volume gibt es Probleme diese hochzufahren.
Das Hauptproblem waren mehrere Stromausfälle im 4-Disc-Gehäuse, in dem 4 der sechs 1-TB-Discs untergebracht sind. Eine neue Disc muss hinzugefügt werden, weil eine Disc entfernt wurde. Vielleicht muss die neue Disc gegen Ende neu synchronisiert werden. Genaueres ist nicht bekannt.
Ich konnte das Volume nach dem ersten Fehler starten und einen Resync einleiten. Aber das Problem tritt erneut auf und das RAID-Volume ist erneut ausgefallen.
Zum Zeitpunkt des zweiten Fehlers konnte das System Sektoren einer speziellen Festplatte nicht lesen und das RAID 5 war aufgrund eines protokollierten permanenten Lesefehlers eines Sektors einer der ausgefallenen Festplatten beeinträchtigt.
In der Zwischenzeit wurden die Datenträger vom Kernel mit neuen Namen neu registriert (z. B. von SDE in SDK usw. umbenannt).
Nach dem Neustart des Systems habe ich überprüft, welche Festplatte als fehlerhaft gemeldet wurde, und sie durch Vergleich der Seriennummer gefunden. Ein DD der Festplatte nach /dev/zero hat keine Probleme gezeigt, also habe ich versucht, sie erneut zu synchronisieren, aber das gleiche Problem tritt auf.
Jetzt wurde mir klar, dass es ein Problem mit der Stromversorgung des Festplattenschachts sein könnte, also entfernte ich alle Festplatten und schloss sie zumindest an die vorhandenen SATA-Anschlüsse des Mainboards an. Ich fügte dem SAS-Controller weitere Festplatten hinzu, sodass ich jetzt mithilfe von DD ein Backup der Partitionen erstellen konnte.
Ich konnte alle zugehörigen Partitionen auf zwei neue Datenträger kopieren, das Lesen stellt also kein Problem dar.
Außerdem wurden nur maximal 3 Volumes innerhalb des LVM-VG verwendet. Die meisten LVs sollten also noch in einem sauberen Zustand sein, da sie sich nicht geändert haben, nachdem ich die erste CD Nr. 2 (sdl3) entfernt habe.
Ich habe smartctl überprüft, sodass kein dauerhaftes Problem auf der Festplatte selbst registriert ist (keine nicht behebbaren Fehler und keine verschobenen Sektoren angezeigt).
Aber ich kann das RAID5-Volume nicht starten, obwohl es über genügend Datenträger verfügen sollte.
Ich habe 5 CDs (#0,1,3,4,5) und die noch vorhandene entfernte CD #2. Auch die neue Ersatz-CD #2 ist da, wird aber als Ersatz angezeigt. Es sollte möglich sein, das Volume mit #0,1,3,4,5 hochzufahren, was 5 von 6 verfügbaren Volumes sind. Aber was auch immer ich versuche, zumindest #3 macht mir die meisten Probleme, weil sie nie als Teil des Volumes akzeptiert wird.
Aufgrund von sdX kann sich hier die Reihenfolge der angezeigten Geräterollen ändern. Hier eine kurze Liste für den Moment:
#0 sdc3 #1 sdk3 #3 sda3 #4 sdg3 #5 sdf3
entfernt #2 sdl3 neu #2 markiert a #S sdb3
root@newxen:~# mdadm -E /dev/sdc3
/dev/sdc3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Unused Space : before=260912 sectors, after=1200 sectors
State : clean
Device UUID : 1142cc76:b224395c:8fb15126:fd1801fe
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 00:02:32 2024
Checksum : bae896cd - correct
Events : 248741
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 0
Array State : AARA.A ('A' == active, '.' == missing, 'R' == replacing)
root@newxen:~# mdadm -E /dev/sdk3
/dev/sdk3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Unused Space : before=260912 sectors, after=1200 sectors
State : clean
Device UUID : 701ed2ed:13a03708:da9cc185:9c9ce3e2
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 10:26:32 2024
Checksum : 223defb1 - correct
Events : 248741
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 1
Array State : .A...A ('A' == active, '.' == missing, 'R' == replacing)
root@newxen:~# mdadm -E /dev/sdl3
/dev/sdl3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Unused Space : before=260912 sectors, after=1200 sectors
State : clean
Device UUID : 1b34e8d5:f3df3e52:307a06a0:38c265e4
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Jan 15 13:36:40 2024
Checksum : 7023234b - correct
Events : 248741
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 2
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
root@newxen:~# mdadm -E /dev/sda3
/dev/sda3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x83
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Recovery Offset : 0 sectors
Unused Space : before=260912 sectors, after=1200 sectors
State : clean
Device UUID : fa9d44c6:bb18bc8c:04ed5943:13a6ddfb
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 00:02:32 2024
Checksum : 55c99a69 - correct
Events : 243265
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 3
Array State : AAAA.A ('A' == active, '.' == missing, 'R' == replacing)
root@newxen:~# mdadm -E /dev/sdg3
/dev/sdg3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x8b
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Recovery Offset : 0 sectors
Unused Space : before=260904 sectors, after=1200 sectors
State : clean
Device UUID : 63a171d2:dad103ed:ff18efc4:d31bc05d
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 10:22:01 2024
Bad Block Log : 512 entries available at offset 72 sectors - bad blocks present.
Checksum : a5b990c1 - correct
Events : 244946
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 4
Array State : .AA.AA ('A' == active, '.' == missing, 'R' == replacing)
root@newxen:~# mdadm -E /dev/sdf3
/dev/sdf3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Unused Space : before=260912 sectors, after=1200 sectors
State : clean
Device UUID : d6e11e48:e1258598:f9d5251c:795c8308
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 10:26:32 2024
Checksum : c8dc31e3 - correct
Events : 248741
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 5
Array State : .A...A ('A' == active, '.' == missing, 'R' == replacing)
Here the replacing disc
root@newxen:~# mdadm -E /dev/sdb3
/dev/sdb3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x9
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 7720024847 (3681.19 GiB 3952.65 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Unused Space : before=260912 sectors, after=5810804111 sectors
State : clean
Device UUID : 1be91027:ca00bcc9:7e21dd61:76cdf787
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 10:26:32 2024
Bad Block Log : 512 entries available at offset 16 sectors - bad blocks present.
Checksum : f892a18d - correct
Events : 248741
Layout : left-symmetric
Chunk Size : 64K
Device Role : spare
Array State : .A...A ('A' == active, '.' == missing, 'R' == replacing)
Aktuelle Situation:
root@newxen:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md128 : inactive sda3[3](S) sdb3[6](S) sdf3[5](S) sdc3[0](S) sdg3[2](S) sdk3[1](S)
8633067263 blocks super 1.2
...
root@newxen:~# mdadm --detail /dev/md128
/dev/md128:
Version : 1.2
Raid Level : raid0
Total Devices : 6
Persistence : Superblock is persistent
State : inactive
Working Devices : 6
Name : newxen:128 (local to host newxen)
UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Events : 248741
Number Major Minor RaidDevice
- 8 163 - /dev/sdk3
- 8 99 - /dev/sdg3
- 8 83 - /dev/sdf3
- 8 35 - /dev/sdc3
- 8 19 - /dev/sdb3
- 8 3 - /dev/sda3
Wenn ich das letzte Datum und den Array-Status überprüfe, meine ich, dass zuerst 15. Jan. 13:36:40 sdl3 auf „Fehlgeschlagen“ gesetzt und entfernt werden muss (was ich manuell gemacht habe) mit AAAAAA, aber es sollte sauber sein 16. Jan. 00:02:32 sda3 mit AAAA.A sieht sauber aus 16. Jan. 00:02:32 sdc3 mit AARA.A sieht sauber aus 16. Jan. 10:22:01 sdg3 mit .AA.AA sieht nicht sauber aus 16. Jan. 10:26:32 sdk3 mit .A...A sieht nicht sauber aus 16. Jan. 10:26:32 sdf3 mit .A...A sieht sauber aus 16. Jan. 10:26:32 sdb3 mit .A..A sieht nicht sauber aus
Es sollte möglich sein, das RAID-Volume mit den vorhandenen Teilen sda3, sdc3, sdg3, sdk3, sdf3 zusammenzustellen, möglicherweise weil es sich im Array sdb3 befand.
Ich habe verschiedene Methoden ausprobiert, aber keine davon führt mich zu einem erneuten Synchronisierungsvolume zurück.
mdadm --assemble --scan --verbose
...
mdadm: /dev/sda3 is identified as a member of /dev/md128, slot 3.
mdadm: /dev/sdl3 is identified as a member of /dev/md128, slot 2.
mdadm: /dev/sdf3 is identified as a member of /dev/md128, slot 5.
mdadm: /dev/sdg3 is identified as a member of /dev/md128, slot 4.
mdadm: /dev/sdk3 is identified as a member of /dev/md128, slot 1.
mdadm: /dev/sdc3 is identified as a member of /dev/md128, slot 0.
mdadm: /dev/sdb3 is identified as a member of /dev/md128, slot -1.
mdadm: ignoring /dev/sdk3 as it reports /dev/sdl3 as failed
mdadm: ignoring /dev/sdf3 as it reports /dev/sdl3 as failed
mdadm: device 12 in /dev/md128 has wrong state in superblock, but /dev/sdb3 seems ok
mdadm: no uptodate device for slot 1 of /dev/md128
mdadm: added /dev/sdl3 to /dev/md128 as 2
mdadm: added /dev/sda3 to /dev/md128 as 3 (possibly out of date)
mdadm: added /dev/sdg3 to /dev/md128 as 4 (possibly out of date)
mdadm: no uptodate device for slot 5 of /dev/md128
mdadm: added /dev/sdb3 to /dev/md128 as -1
mdadm: added /dev/sdc3 to /dev/md128 as 0
mdadm: /dev/md128 assembled from 2 drives and 1 spare - not enough to start the array.
...
root@newxen:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md128 : inactive sdf3[5](S) sdb3[6](S) sdc3[0](S) sdk3[1](S) sdg3[2](S) sdl3[4](S)
8633067263 blocks super 1.2
...
root@newxen:~# mdadm --detail /dev/md128
/dev/md128:
Version : 1.2
Raid Level : raid0
Total Devices : 6
Persistence : Superblock is persistent
State : inactive
Working Devices : 6
Name : newxen:128 (local to host newxen)
UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Events : 248741
Number Major Minor RaidDevice
- 8 179 - /dev/sdl3
- 8 163 - /dev/sdk3
- 8 99 - /dev/sdg3
- 8 83 - /dev/sdf3
- 8 35 - /dev/sdc3
- 8 19 - /dev/sdb3
Es sieht also so aus, als ob das alte entfernte SDL3 und das ersetzte SDB3 einige Probleme machen. Also habe ich MD128 erneut gestoppt und versucht, es ohne sie manuell hochzufahren:
root@newxen:~# mdadm --assemble /dev/md128 /dev/sdc3 /dev/sdk3 /dev/sda3 /dev/sdg3 /dev/sdf3 --verbose
mdadm: looking for devices for /dev/md128
mdadm: /dev/sdc3 is identified as a member of /dev/md128, slot 0.
mdadm: /dev/sdk3 is identified as a member of /dev/md128, slot 1.
mdadm: /dev/sda3 is identified as a member of /dev/md128, slot 3.
mdadm: /dev/sdg3 is identified as a member of /dev/md128, slot 4.
mdadm: /dev/sdf3 is identified as a member of /dev/md128, slot 5.
mdadm: ignoring /dev/sdk3 as it reports /dev/sdc3 as failed
mdadm: ignoring /dev/sdg3 as it reports /dev/sdc3 as failed
mdadm: ignoring /dev/sdf3 as it reports /dev/sdc3 as failed
mdadm: no uptodate device for slot 1 of /dev/md128
mdadm: no uptodate device for slot 2 of /dev/md128
mdadm: added /dev/sda3 to /dev/md128 as 3 (possibly out of date)
mdadm: no uptodate device for slot 4 of /dev/md128
mdadm: no uptodate device for slot 5 of /dev/md128
mdadm: added /dev/sdc3 to /dev/md128 as 0
mdadm: /dev/md128 assembled from 1 drive - not enough to start the array.
root@newxen:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md128 : inactive sdk3[1](S) sdf3[5](S) sdg3[2](S) sdc3[0](S)
3818443872 blocks super 1.2
...
root@newxen:~# mdadm --detail /dev/md128
/dev/md128:
Version : 1.2
Raid Level : raid0
Total Devices : 4
Persistence : Superblock is persistent
State : inactive
Working Devices : 4
Name : newxen:128 (local to host newxen)
UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Events : 248741
Number Major Minor RaidDevice
- 8 163 - /dev/sdk3
- 8 99 - /dev/sdg3
- 8 83 - /dev/sdf3
- 8 35 - /dev/sdc3
Daher wundere ich mich, dass sda3 nicht in den Details angezeigt wird.
Ich habe auch versucht, sdl3 statt sdb3 zu verwenden und die fehlenden Teile erneut hinzuzufügen, aber nichts hat wirklich geholfen. Ich schätze also, ich sollte die Superblöcke auf Null setzen und den Raid mit der Option --assume-clean neu erstellen. Meiner Meinung nach sollte es in der richtigen Reihenfolge sein. Bestenfalls sollte es vielleicht ohne sdb3 und sdl3 sein, da ich nicht sicher bin, ob sdb3 jemals den Synchronisierungsstatus erreicht hat, bevor das erste Problem auftrat. Gibt es eine Möglichkeit, dies zu überprüfen?
Wenn es also keine andere Möglichkeit gibt, würde ich Folgendes tun (ist diese Reihenfolge richtig?):
mdadm --create --verbose --force --assume-clean /dev/md128 --level=5 --raid-devices=6 /dev/sdc3 /dev/sdk3 missing /dev/sda3 /dev/sdg3 /dev/sdf3
Eine andere Lösung könnte sein, dass ich davon ausgehe, dass die Festplatte sdb3 nahezu synchronisiert ist.
mdadm --create --verbose --force --assume-clean /dev/md128 --level=5 --raid-devices=6 /dev/sdc3 /dev/sdk3 /dev/sdb3 /dev/sda3 /dev/sdg3 /dev/sdf3
Wie kann ich das überprüfen?:
echo check >> /sys/block/md128/md/sync_action and then check dmesg carefully?
Außerdem würde ich gerne wissen, in welchen Bereichen ich nach Abschluss der Rekonstruktion mit Problemen rechnen muss. Gibt es Vorschläge, wie ich diese Probleme identifizieren kann?
Weitere Details hinzugefügt: Es ist schwer, detaillierte Informationen zu finden. Daher wäre es schön, wenn jemand meine Ideen bestätigen oder korrigieren könnte.
Inzwischen müssen die Entschlüsselungstests abgeschlossen sein. Es darf keine Permutation der Gerätereihenfolge vorgenommen werden.
Es war also möglich, das RAID-Array zum Laufen zu bringen, die Daten selbst scheinen jedoch immer noch gemischt und unbrauchbar zu sein. Aus diesem Grund kann ich die darauf befindlichen Luks-Daten im Moment nicht entschlüsseln.