Verschlüsseltes Raid 5 -- Crash
Verschlüsseltes Raid 5 -- Crash
Hallo liebe Mitglieder,
dies ist mein erster Beitrag und ich habe ein Problem mit meinem mdadm Raid Verbund vielleicht könnt ihr mir helfen.
Also mein System liegt auf einem verschlüsseltem Raid 5 Verbund mit ursprünglich 4 1TB Festplatten.
Auf den Festplatten sind 2 Partitionen 100Mb im Raid 1 für die Boot Partition und 900GB im Raid 5 Verbund fürs Dateisystem und alles andere.
Beim booten werde ich unter grub nach dem krypt key gefragt und das System fährt hoch.
Mein Problem ist nun:
Ich habe das System um eine baugleiche Platte erweitert mit den gewohnten Befehlen ( ich hatte mir alles vom ersten mal aufgeschrieben da ich ursprünglich mit 3Platten begonnen habe)
der grow des Verbundes war ungewohnt schnell (ca.5 stunden anstatt 24) bei trotzdem ursprünglich angesagten 1200Minuten. .
Sofort nach dem der Vorgang "erfolgreich" abgeschlossen war (md1 reshape done) ließ sich auch nichts mehr in der Konsole eingeben.
Vermutlich hatte sich das Raid ausgehängt und da mein System auf dem Raid 5 Verbund installiert ist hatte es natürlich keinen Plattenzugriff mehr.
Nach dem Neustart war dann auch zu lesen das md1 (der raid5 Verbund) nicht gefunden wird und egal welchen krypt key man eingibt nichts passiert. ( ist ja auch klar... ist ja nix mehr da zum überprüfen)
das warscheinlichste ist das die 5. Festplatte (aus einem usb gehäuse ausgebaut) schon vor dem reshape defekte sektoren hatte.
es waren auch darauf hindeutende Ausgaben zu lesen.
zusätzlich gab es vor dem reshape nach dem -add sde1 diesen 00.90 bla fehler der aber automatisch ignoriert wurde.
Ich bin im Moment ziemlich vorsichtig da auf diesem Raid Verbund nur persönliche Daten wie Fotos / Videos / Dokumente / etc. gespeichert sind die nicht für immer verloren sein dürfen...
ein zusätzliches Backup existiert nicht um die Sicherheit der Daten zu gewährleisten. (worüber ich aber bald nochmal nachdenken werde)
Wie würdest ihr an die Sache dran gehen?
Live CD? Manuell einhängen und Schäden reparieren?
Grub nochmal erklären wo was zu finden ist?
reshape zurück und 5.platte wieder rausholen?
ich will es nicht schlimmer machen als es ohne hin ist...
dies ist mein erster Beitrag und ich habe ein Problem mit meinem mdadm Raid Verbund vielleicht könnt ihr mir helfen.
Also mein System liegt auf einem verschlüsseltem Raid 5 Verbund mit ursprünglich 4 1TB Festplatten.
Auf den Festplatten sind 2 Partitionen 100Mb im Raid 1 für die Boot Partition und 900GB im Raid 5 Verbund fürs Dateisystem und alles andere.
Beim booten werde ich unter grub nach dem krypt key gefragt und das System fährt hoch.
Mein Problem ist nun:
Ich habe das System um eine baugleiche Platte erweitert mit den gewohnten Befehlen ( ich hatte mir alles vom ersten mal aufgeschrieben da ich ursprünglich mit 3Platten begonnen habe)
der grow des Verbundes war ungewohnt schnell (ca.5 stunden anstatt 24) bei trotzdem ursprünglich angesagten 1200Minuten. .
Sofort nach dem der Vorgang "erfolgreich" abgeschlossen war (md1 reshape done) ließ sich auch nichts mehr in der Konsole eingeben.
Vermutlich hatte sich das Raid ausgehängt und da mein System auf dem Raid 5 Verbund installiert ist hatte es natürlich keinen Plattenzugriff mehr.
Nach dem Neustart war dann auch zu lesen das md1 (der raid5 Verbund) nicht gefunden wird und egal welchen krypt key man eingibt nichts passiert. ( ist ja auch klar... ist ja nix mehr da zum überprüfen)
das warscheinlichste ist das die 5. Festplatte (aus einem usb gehäuse ausgebaut) schon vor dem reshape defekte sektoren hatte.
es waren auch darauf hindeutende Ausgaben zu lesen.
zusätzlich gab es vor dem reshape nach dem -add sde1 diesen 00.90 bla fehler der aber automatisch ignoriert wurde.
Ich bin im Moment ziemlich vorsichtig da auf diesem Raid Verbund nur persönliche Daten wie Fotos / Videos / Dokumente / etc. gespeichert sind die nicht für immer verloren sein dürfen...
ein zusätzliches Backup existiert nicht um die Sicherheit der Daten zu gewährleisten. (worüber ich aber bald nochmal nachdenken werde)
Wie würdest ihr an die Sache dran gehen?
Live CD? Manuell einhängen und Schäden reparieren?
Grub nochmal erklären wo was zu finden ist?
reshape zurück und 5.platte wieder rausholen?
ich will es nicht schlimmer machen als es ohne hin ist...
Re: Verschlüsseltes Raid 5 -- Crash
Als erstes Mal: 5 neue, mindestens exakt! gleich große Platten kaufen, jede Platte die jetzt in dem RAID drin ist auf die neue klonen (aus einem live-System heraus mit dd if=/dev/alt of=/dev/neu).
Die Original-Platten ausbauen! und in den Tresor legen und nicht mehr anfassen (auch nicht lesend mounten, da können ggf. auch Veränderungen passieren)! Machst Du das nicht, dann würde ich sagen besteht eine mehr als 80% ige Wahrscheinlichkeit das die Daten im Nirvana sind, denn schon ein kleiner Fehler kann alles schrotten!
Mit den Clonen kannst dann versuchen das System zu retten. Dabei würde ich raten immer ein externes System zu benutzen (also z.B. grml oder ein anderes Live-Systen).
Chancen:
- wenn die Verschlüsselung noch intakt ist: machbar, aber aufwändig.
- wenn die Verschlüsselung nicht mehr 100% intakt (ein Bitkipper reicht u.U. schon aus) ist: sehr gering bis unmöglich
Wer verschlüsselt der nimmt bewusst! in Kauf seine Daten komplett zu verlieren sofern kein Backup vorliegt!
Die Original-Platten ausbauen! und in den Tresor legen und nicht mehr anfassen (auch nicht lesend mounten, da können ggf. auch Veränderungen passieren)! Machst Du das nicht, dann würde ich sagen besteht eine mehr als 80% ige Wahrscheinlichkeit das die Daten im Nirvana sind, denn schon ein kleiner Fehler kann alles schrotten!
Mit den Clonen kannst dann versuchen das System zu retten. Dabei würde ich raten immer ein externes System zu benutzen (also z.B. grml oder ein anderes Live-Systen).
Chancen:
- wenn die Verschlüsselung noch intakt ist: machbar, aber aufwändig.
- wenn die Verschlüsselung nicht mehr 100% intakt (ein Bitkipper reicht u.U. schon aus) ist: sehr gering bis unmöglich
Wer verschlüsselt der nimmt bewusst! in Kauf seine Daten komplett zu verlieren sofern kein Backup vorliegt!
Re: Verschlüsseltes Raid 5 -- Crash
ist es wirklich schon so schlimm?
ich dachte ich könnte damit anfangen das raid per live cd erst einmal nur mit den ursprünglichen 4 platten zu mounten also im degraded modus laufen lassen und dann schnell ein backup ziehen.
zum beispiel so
sudo mdadm --create /dev/md1 --level=5 --raid-devices=5 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 missing /dev/sde1
eine platte im verbund darf ja ausfallen. ich weiß nur nicht was jetzt genau passiert ist.
falls die 5. platte wirklich einen defekt hatte vor dem einbau ist doch auch nur die 5. kaputt oder ist durch den paritätsspeicher vorgang vielleicht auch möglich das etwas auf den anderen platten kaputt gegangen ist?
was mich auch sehr stutzig macht ist das grub beim booten sagt das md1 nicht gefunden wird.
kann es vielleicht sein das hier hier grub nur nocheinmal erklärt haben muss was es machen soll?
könnte ich das nicht einfach machen und dann die defekte platte im raid einfach durch eine neue ersetzen und ins raid einarbeiten?
ich dachte ich könnte damit anfangen das raid per live cd erst einmal nur mit den ursprünglichen 4 platten zu mounten also im degraded modus laufen lassen und dann schnell ein backup ziehen.
zum beispiel so
sudo mdadm --create /dev/md1 --level=5 --raid-devices=5 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 missing /dev/sde1
eine platte im verbund darf ja ausfallen. ich weiß nur nicht was jetzt genau passiert ist.
falls die 5. platte wirklich einen defekt hatte vor dem einbau ist doch auch nur die 5. kaputt oder ist durch den paritätsspeicher vorgang vielleicht auch möglich das etwas auf den anderen platten kaputt gegangen ist?
was mich auch sehr stutzig macht ist das grub beim booten sagt das md1 nicht gefunden wird.
kann es vielleicht sein das hier hier grub nur nocheinmal erklärt haben muss was es machen soll?
könnte ich das nicht einfach machen und dann die defekte platte im raid einfach durch eine neue ersetzen und ins raid einarbeiten?
Zuletzt geändert von mooboo am 09.01.2012 15:45:44, insgesamt 2-mal geändert.
Re: Verschlüsseltes Raid 5 -- Crash
auch wenn ich das system mit nur 4 platten starte und die letzte ausgesteckt lasse gibt der start immer noch md1 not found aus.
liegt das problem nicht vielleicht nur hier?
was ließe sich denn von der grub konsole aus noch machen? bis dahin komme ich ja noch.
liegt das problem nicht vielleicht nur hier?
was ließe sich denn von der grub konsole aus noch machen? bis dahin komme ich ja noch.
Re: Verschlüsseltes Raid 5 -- Crash
Hier der Vorgang in der Konsole den ich noch gefunden habe:
36157
irgendwann war dann reshape fertig und nix war mehr los
irgendwann war dann reshape fertig und nix war mehr los
Zuletzt geändert von Saxman am 09.01.2012 18:25:23, insgesamt 1-mal geändert.
Grund: Nach NoPaste verschoben
Grund: Nach NoPaste verschoben
Re: Verschlüsseltes Raid 5 -- Crash
Also erstes fällt mir auf das deine Platten nicht so partitioniert sind wie es für ein RAID notwendig ist.
Wenn Du n Platten im System hast, dann müssen alle n Platten exakt gleich groß sein. Wenn Du n Partitionen für das RAID benutzt, dann gilt natürlich das die im RAID befindlichen n Partitionen EXAKT gleich groß sein MÜSSEN.
Und das ist bei Dir nicht der Fall. Das allein ist schon eine Garantie das dir das RAID irgendwann stirbt ...
/dev/sda2 : start= 1943865, size=1951174575, Id=fd
/dev/sdb2 : start= 1943865, size=1951174575, Id=fd
/dev/sdc1 : start= 63, size=1951174512, Id=fd
/dev/sdd1 : start= 63, size=1951174512, Id=fd
/dev/sde1 : start= 63, size=1951174512, Id=fd
sda2 und sdb2 sind gleich groß, sdc1, sdd1 und sde1 sind ebenfalls gleich groß, haben aber eine abweichende Größe verglichen mit sda2 und sdb2.
Hier kommt folgendes an Problemen zum tragen: das RAID ist aus unterschiedlich großen Partitionen zusammengebaut. Das knallt dann beim Resync ...
Hinzu kommt das das System verschlüsselt ist. Mach das alles noch mal schlimmer ...
Ich würde dir anraten alle Platten zu klonen und dann einen Spezialisten, und zwar einen der das wirlklich kann, mit dem Problem aufzusuchen. Alternativ schreibst das als Lehrgeld einfach ab. Ich persönlich sehe hier kaum eine realistische Chance das wieder herzustellen.
Vielleicht hat noch ein anderer eine Meinung dazu oder kann sogar helfen.
Wenn Du n Platten im System hast, dann müssen alle n Platten exakt gleich groß sein. Wenn Du n Partitionen für das RAID benutzt, dann gilt natürlich das die im RAID befindlichen n Partitionen EXAKT gleich groß sein MÜSSEN.
Und das ist bei Dir nicht der Fall. Das allein ist schon eine Garantie das dir das RAID irgendwann stirbt ...
/dev/sda2 : start= 1943865, size=1951174575, Id=fd
/dev/sdb2 : start= 1943865, size=1951174575, Id=fd
/dev/sdc1 : start= 63, size=1951174512, Id=fd
/dev/sdd1 : start= 63, size=1951174512, Id=fd
/dev/sde1 : start= 63, size=1951174512, Id=fd
sda2 und sdb2 sind gleich groß, sdc1, sdd1 und sde1 sind ebenfalls gleich groß, haben aber eine abweichende Größe verglichen mit sda2 und sdb2.
Hier kommt folgendes an Problemen zum tragen: das RAID ist aus unterschiedlich großen Partitionen zusammengebaut. Das knallt dann beim Resync ...
Hinzu kommt das das System verschlüsselt ist. Mach das alles noch mal schlimmer ...
Ich würde dir anraten alle Platten zu klonen und dann einen Spezialisten, und zwar einen der das wirlklich kann, mit dem Problem aufzusuchen. Alternativ schreibst das als Lehrgeld einfach ab. Ich persönlich sehe hier kaum eine realistische Chance das wieder herzustellen.
Vielleicht hat noch ein anderer eine Meinung dazu oder kann sogar helfen.
- Soong
- Beiträge: 207
- Registriert: 09.05.2011 11:05:26
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Verschlüsseltes Raid 5 -- Crash
Also ganz so schwarz sehe ich für deine Daten noch nicht, aber es sieht nicht gut aus und ich würde dir in jedem Fall dazu raten, das RAID jetzt nicht mehr anzufassen.
Du musst dich jetzt letztendlich entscheiden wie wichtig dir die Daten sind: Wenn du sie auf keinen Fall verlieren darfst, geh gleich zu einem Datenrettungsunternehmen (die c't hat da mal welche getestet) und hoffe auf das Beste.
Wenn du vorher noch selbst experimentieren willst und dir das Geld für die Datenrettung vorerst sparen willst, dann kauf dir Ersatzplatten und arbeite mit Klonen der Originalplatten. Dabei kannst du auch mit Images arbeiten, d.h. du kannst zwei 1-TB-Platten als zwei Images auf eine 2-TB-Platte packen, sofern die 2-TB-Platte mindestens genau doppelt so groß ist. Die neuen Platten kannst du dann Hinterher für eine Datensicherung nutzen.
Wenn dir die Daten nicht so wichtig sind, dann experimentiere jetzt weiter mit den Originalplatten rum bis du entweder Erfolg hast (dann lass uns bitte die Lösung wissen) oder nichts mehr geht und die Daten weg sind. Dann brauchst du auch das Datenrettungsunternehmen nicht mehr bemühen. Hat auch was Reinigendes wenn man alten Ballast über Bord wirft. Und das meine ich jetzt nicht mal zynisch, mir ist das schon so gegangen mit Daten, die ich keinesfalls verlieren wollte - hinterher habe ich bemerkt, dass ich doch ohne konnte und gleichzeitig eine Backup-Strategie entwickelt.).
Ach so: Alle von dir genannten Strategien würde ich auch versuchen, aber wie gesagt an Klonen. Das reshape rückgängig machen wird allerdings nicht funktionieren, weil du dazu ja erst mal ein laufendes RAID brauchst. Also versuch erst mal an die Daten zu kommen, sichere sie dann und mach erst dann weiter. Im Grunde kannst du aber auch nach dem Sichern aufhören und einfach das System neu aufsetzen; spart wahrscheinlich Zeit.
Du musst dich jetzt letztendlich entscheiden wie wichtig dir die Daten sind: Wenn du sie auf keinen Fall verlieren darfst, geh gleich zu einem Datenrettungsunternehmen (die c't hat da mal welche getestet) und hoffe auf das Beste.
Wenn du vorher noch selbst experimentieren willst und dir das Geld für die Datenrettung vorerst sparen willst, dann kauf dir Ersatzplatten und arbeite mit Klonen der Originalplatten. Dabei kannst du auch mit Images arbeiten, d.h. du kannst zwei 1-TB-Platten als zwei Images auf eine 2-TB-Platte packen, sofern die 2-TB-Platte mindestens genau doppelt so groß ist. Die neuen Platten kannst du dann Hinterher für eine Datensicherung nutzen.
Wenn dir die Daten nicht so wichtig sind, dann experimentiere jetzt weiter mit den Originalplatten rum bis du entweder Erfolg hast (dann lass uns bitte die Lösung wissen) oder nichts mehr geht und die Daten weg sind. Dann brauchst du auch das Datenrettungsunternehmen nicht mehr bemühen. Hat auch was Reinigendes wenn man alten Ballast über Bord wirft. Und das meine ich jetzt nicht mal zynisch, mir ist das schon so gegangen mit Daten, die ich keinesfalls verlieren wollte - hinterher habe ich bemerkt, dass ich doch ohne konnte und gleichzeitig eine Backup-Strategie entwickelt.).
Ach so: Alle von dir genannten Strategien würde ich auch versuchen, aber wie gesagt an Klonen. Das reshape rückgängig machen wird allerdings nicht funktionieren, weil du dazu ja erst mal ein laufendes RAID brauchst. Also versuch erst mal an die Daten zu kommen, sichere sie dann und mach erst dann weiter. Im Grunde kannst du aber auch nach dem Sichern aufhören und einfach das System neu aufsetzen; spart wahrscheinlich Zeit.
The strength of a civilization is not measured by its ability to fight wars, but rather by its ability to prevent them.
-Gene Roddenberry
Mitglied bei der Free Software Foundation oder der Free Software Foundation Europe werden oder kostenlos die Free Software Foundation Europe unterstützen!
-Gene Roddenberry
Mitglied bei der Free Software Foundation oder der Free Software Foundation Europe werden oder kostenlos die Free Software Foundation Europe unterstützen!
Re: Verschlüsseltes Raid 5 -- Crash
ja das problem mit den geringfügig unterschiedlich großen partitionen ist mir auch schon aufgefallen....
jedoch habe ich mit ursprünglich 3 platten begonnen und dieser unterschied war ab der ersten minute da wo das system lief.
als ich damals eine platte hinzugefügt hatte habe ich die partitionstabelle kopiert die sich auf der 3. platte befunden hat (diese partition wurde von dem installationsmanager auf diese größe beim installieren des grundsystems abgeändert.)
dieser geringe unterschied wurde vom system auch nie bemängelt (habe bis jetzt noch nie den maximalen platz auf den platten ausgenutzt)
da mich hauptsächlich die privaten daten interessieren (fotos oder videos von familienfesten etc) stellt sich mir auch die frage wie die daten im fall der fälle nachher aussehen.
könnte ich trotz verschlüsselung auf teils kaputte datensätze zurückgreifen z.b. videos die ruckeln oder bilder die fehler enthalten oder ist wenn ein datensätz beschädigt ist auch alles weg also das bild oder video gar nicht mehr zu öffnen weil es sich beispielsweise nicht mehr entschlüsseln lässt?
eine datenrettungsfirma ist eigentlich keine option da sich auch geheime firmendaten aus forschungsprojekten auf dem system befinden und der nachweis wer es veröffentlicht hat wenn es erst ein mal im netz gelandet ist fast unmachbar wäre.
von diesen daten existiert zwar ein backup jedoch dürfen sie nicht in falsche hände gelangen und vorzeitig veröffentlicht werden.
und das ich etwas gegen die einsicht oder veröffentlichung meiner privaten daten habe (videos / fotos) zeigt ja schon die verschlüsselung des systems.
jedoch habe ich mit ursprünglich 3 platten begonnen und dieser unterschied war ab der ersten minute da wo das system lief.
als ich damals eine platte hinzugefügt hatte habe ich die partitionstabelle kopiert die sich auf der 3. platte befunden hat (diese partition wurde von dem installationsmanager auf diese größe beim installieren des grundsystems abgeändert.)
dieser geringe unterschied wurde vom system auch nie bemängelt (habe bis jetzt noch nie den maximalen platz auf den platten ausgenutzt)
da mich hauptsächlich die privaten daten interessieren (fotos oder videos von familienfesten etc) stellt sich mir auch die frage wie die daten im fall der fälle nachher aussehen.
könnte ich trotz verschlüsselung auf teils kaputte datensätze zurückgreifen z.b. videos die ruckeln oder bilder die fehler enthalten oder ist wenn ein datensätz beschädigt ist auch alles weg also das bild oder video gar nicht mehr zu öffnen weil es sich beispielsweise nicht mehr entschlüsseln lässt?
eine datenrettungsfirma ist eigentlich keine option da sich auch geheime firmendaten aus forschungsprojekten auf dem system befinden und der nachweis wer es veröffentlicht hat wenn es erst ein mal im netz gelandet ist fast unmachbar wäre.
von diesen daten existiert zwar ein backup jedoch dürfen sie nicht in falsche hände gelangen und vorzeitig veröffentlicht werden.
und das ich etwas gegen die einsicht oder veröffentlichung meiner privaten daten habe (videos / fotos) zeigt ja schon die verschlüsselung des systems.
Re: Verschlüsseltes Raid 5 -- Crash
bis jetzt erst einmal vielen dank für eure bemühungen.
machen wir theoretisch weiter.
wenn ich alle platten geklont habe (was vielleicht bei der 5. nicht nötig ist da sie ja sowieso schrott zu sein scheint und eine platte ja ausfallen darf)
wie verfahre ich dann weiter?
lassen sich überhaupt einzelne platten eines raids anschließen und auslesen? also jetzt nicht mit dd kopieren sondern richtig drauf zugreifen?
ich dachte den zugriff bekommt man erst durch den zusammenschluss der platten.
das würde ja bedeuten das mir sowieso nichts anderes übrig bleibt als zu versuchen das raid mit einem live system in einem degraded status ein zu hängen um auf die darauf befindlichen daten zugreifen zu können. oder was kann man noch machen außer einfach nur das raid lauffähig zu bekommen?
machen wir theoretisch weiter.
wenn ich alle platten geklont habe (was vielleicht bei der 5. nicht nötig ist da sie ja sowieso schrott zu sein scheint und eine platte ja ausfallen darf)
wie verfahre ich dann weiter?
lassen sich überhaupt einzelne platten eines raids anschließen und auslesen? also jetzt nicht mit dd kopieren sondern richtig drauf zugreifen?
ich dachte den zugriff bekommt man erst durch den zusammenschluss der platten.
das würde ja bedeuten das mir sowieso nichts anderes übrig bleibt als zu versuchen das raid mit einem live system in einem degraded status ein zu hängen um auf die darauf befindlichen daten zugreifen zu können. oder was kann man noch machen außer einfach nur das raid lauffähig zu bekommen?
- Soong
- Beiträge: 207
- Registriert: 09.05.2011 11:05:26
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Verschlüsseltes Raid 5 -- Crash
Du hast mit all deinen Annahmen Recht. Theoretisch wäre es denkbar von einer einzelnen Platte Datenreste auszulesen, aber da bekäme man allenfalls Dateien, die kleiner als ein Stripe sind. Bei dir geht selbst das nicht (falls es denn überhaupt geht), weil dann obendrauf noch die Verschlüsselung sitzt und wenn dafür nicht alle Platten des RAIDs vollständig vorhanden sind, kannst du den Container nicht entschlüsseln und bekommst keinen Zugriff.
Deswegen hast du auch Recht, dass du das RAID mit einem Live-System einhängen musst, aber das kannst du ja auch mit den Klonen machen. Ob Original oder Klon spielt dafür nämlich keine Rolle.
Deswegen hast du auch Recht, dass du das RAID mit einem Live-System einhängen musst, aber das kannst du ja auch mit den Klonen machen. Ob Original oder Klon spielt dafür nämlich keine Rolle.
The strength of a civilization is not measured by its ability to fight wars, but rather by its ability to prevent them.
-Gene Roddenberry
Mitglied bei der Free Software Foundation oder der Free Software Foundation Europe werden oder kostenlos die Free Software Foundation Europe unterstützen!
-Gene Roddenberry
Mitglied bei der Free Software Foundation oder der Free Software Foundation Europe werden oder kostenlos die Free Software Foundation Europe unterstützen!
Re: Verschlüsseltes Raid 5 -- Crash
okay das werde ich selbstverständlich auch nur mit den klonen probieren.
schön zu sehen das meine daten über 2 jahre hinweg so "sicher" gespeichert waren das es jetzt fast unmöglich ist wieder dran zu kommen.
also ist das ersteinmal der einzige weg?
was ist wenn sich das LVM nicht einhängen lässt oder sich durch bitkipper das lvm nicht entschlüsseln lässt?
ist da schon schluss mit lustig?
wie warscheinlich ist dieser fall wenn es schon nicht mehr durch grub automatisch passiert?
ich habe noch etwas in einem anderen forum gefunden. was ist hier von zu halten?
Zitat
Original von Mac Gyver
noch mal ne frage zu den berüchtigeten UREs während des raid rebuilds-was passiert eigentlich wenn sowas auftritt? geht der rebuild weiter und einige daten die sich auf entsprechndem stripe befanden sind dann weg/korrupt oder bricht der ganze rebild ab und alles ist weg? eigentlich sollte es doch dafür keinen grund geben oder?
Ich habe das ungewollt praktisch ausprobieren dürfen. Bei meinem RAID Ausbau ist zu einem mir nicht erklärbaren Systemhänger gekommen, also notgedrungener weise musste das System neugestartet werden. Natürlich meinte das System das /dev/md2 nicht mehr existieren würden. (Leichter Panik Ausbruch) Aber ein mdadm --assemble /dev/md2 /dev/sdaX /dev/sdbX ... --force, hat es wieder zusammengesetzt und der Grow/Resize Prozess lief ohne Datenverlust von der letzten Stelle weiter.
schön zu sehen das meine daten über 2 jahre hinweg so "sicher" gespeichert waren das es jetzt fast unmöglich ist wieder dran zu kommen.
also ist das ersteinmal der einzige weg?
was ist wenn sich das LVM nicht einhängen lässt oder sich durch bitkipper das lvm nicht entschlüsseln lässt?
ist da schon schluss mit lustig?
wie warscheinlich ist dieser fall wenn es schon nicht mehr durch grub automatisch passiert?
ich habe noch etwas in einem anderen forum gefunden. was ist hier von zu halten?
Zitat
Original von Mac Gyver
noch mal ne frage zu den berüchtigeten UREs während des raid rebuilds-was passiert eigentlich wenn sowas auftritt? geht der rebuild weiter und einige daten die sich auf entsprechndem stripe befanden sind dann weg/korrupt oder bricht der ganze rebild ab und alles ist weg? eigentlich sollte es doch dafür keinen grund geben oder?
Ich habe das ungewollt praktisch ausprobieren dürfen. Bei meinem RAID Ausbau ist zu einem mir nicht erklärbaren Systemhänger gekommen, also notgedrungener weise musste das System neugestartet werden. Natürlich meinte das System das /dev/md2 nicht mehr existieren würden. (Leichter Panik Ausbruch) Aber ein mdadm --assemble /dev/md2 /dev/sdaX /dev/sdbX ... --force, hat es wieder zusammengesetzt und der Grow/Resize Prozess lief ohne Datenverlust von der letzten Stelle weiter.
- Soong
- Beiträge: 207
- Registriert: 09.05.2011 11:05:26
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Verschlüsseltes Raid 5 -- Crash
Ja, das ist erst einmal der einzige Weg. Zumindest fällt mir auch nichts anderes ein. Wenn sich das LVM nicht mehr einhängen oder entschlüsseln lässt, sehe ich auch schwarz. Wie wahrscheinlich der Fall ist, kann ich dir nicht sagen, weil ich das dafür nicht oft genug mache.
Die Beschreibung aus dem anderen Forum klingt soweit richtig, aber ich weiß ja nicht in welchem Zustand dein RAID jetzt ist. Darauf kommt es dann letztendlich an. Das findest du aber nur durch Probieren raus. Wenn bei dir ein URE auftritt, hast du wohl verloren, weil bei dir ja ein verschlüsseltes Dateisystem eine Ebene über dem RAID sitzt. Die Chance für so einen URE liegt bei dir bei rund 32% und zwar bei neuen Platten. Bei älteren Platten ist die Wahrscheinlichkeit höher.
Mir fällt gerade noch was zum Klonen ein: Verwende vielleicht besser ddrescue statt einfach dd, weil das auch bei Lesefehlern weitermacht und gegebenenfalls später nochmal einen Leseversuch von defekten Sektoren starten kann.
Noch was Allgemeines zum Thema Sicherheit bei RAID 5. Du hast aus gutem Grund das Wort "sicher" in Anführungszeichen gesetzt, denn Sicherheit bietet es so gut wie gar keine. Ich betreibe auch ein RAID 5 in ähnlicher Konfiguration (6 TB insgesamt), aber hauptsächlich wegen der Geschwindigkeit und der im Vergleich zu RAID 0 höheren Sicherheit. Aber da aktuelle Festplatten durchschnittlich einen Fehler pro 10^14 Bits haben, ist mir bewusst, dass die Chance eines URE bei mir bei fast 50% liegt. Ich bin deswegen am Überlegen das RAID aufzugeben und den Platz irgendwie anders zusammenzufassen. In der aktuellen c't (2/2012) ist dazu übrigens ein sehr guter Artikel, der die Problematik beschreibt (und mir entsprechend Kopfschmerzen bereitet hat). Aber das nur allgemein, auch für alle die per Google hierüber stolpern.
Die Beschreibung aus dem anderen Forum klingt soweit richtig, aber ich weiß ja nicht in welchem Zustand dein RAID jetzt ist. Darauf kommt es dann letztendlich an. Das findest du aber nur durch Probieren raus. Wenn bei dir ein URE auftritt, hast du wohl verloren, weil bei dir ja ein verschlüsseltes Dateisystem eine Ebene über dem RAID sitzt. Die Chance für so einen URE liegt bei dir bei rund 32% und zwar bei neuen Platten. Bei älteren Platten ist die Wahrscheinlichkeit höher.
Mir fällt gerade noch was zum Klonen ein: Verwende vielleicht besser ddrescue statt einfach dd, weil das auch bei Lesefehlern weitermacht und gegebenenfalls später nochmal einen Leseversuch von defekten Sektoren starten kann.
Noch was Allgemeines zum Thema Sicherheit bei RAID 5. Du hast aus gutem Grund das Wort "sicher" in Anführungszeichen gesetzt, denn Sicherheit bietet es so gut wie gar keine. Ich betreibe auch ein RAID 5 in ähnlicher Konfiguration (6 TB insgesamt), aber hauptsächlich wegen der Geschwindigkeit und der im Vergleich zu RAID 0 höheren Sicherheit. Aber da aktuelle Festplatten durchschnittlich einen Fehler pro 10^14 Bits haben, ist mir bewusst, dass die Chance eines URE bei mir bei fast 50% liegt. Ich bin deswegen am Überlegen das RAID aufzugeben und den Platz irgendwie anders zusammenzufassen. In der aktuellen c't (2/2012) ist dazu übrigens ein sehr guter Artikel, der die Problematik beschreibt (und mir entsprechend Kopfschmerzen bereitet hat). Aber das nur allgemein, auch für alle die per Google hierüber stolpern.
The strength of a civilization is not measured by its ability to fight wars, but rather by its ability to prevent them.
-Gene Roddenberry
Mitglied bei der Free Software Foundation oder der Free Software Foundation Europe werden oder kostenlos die Free Software Foundation Europe unterstützen!
-Gene Roddenberry
Mitglied bei der Free Software Foundation oder der Free Software Foundation Europe werden oder kostenlos die Free Software Foundation Europe unterstützen!
Re: Verschlüsseltes Raid 5 -- Crash
guten morgen.
ich habe nun am freitag den 13. passender weise den kopiervorgang mit dd begonnen.
ich habe 2 2TB festplatten auf denen ich nun jeweils 3 partitonen angelegt habe.
jeweils einmal die raid 1 boot partition und zwei raid 5 partitionen.
also insgesamt 6 primäre partitionen auf 2 festplatten.
das boot flag wurde automatisch mit sfdisk | sfdisk übernommen jedoch musste ich die jeweils dritte partition mit gparted selbst anlegen. dort konnte ich leider auch kein raid flag setzen.
mal schauen ob es damit noch probleme gibt.
ich habe in mehreren schritten den kopiervorgang durchgeführt
zu erst die erste original festplatte 1:1 auf den klon kopiert ca. 90MB/s
danach die zweite genau so jedoch zusätzlich von der 3.original festplatte auf die 3.partiton der 1. klon festplatte.
hier betrug die geschwindigkeit vom zu erst gestarteten dd vorgang 77Mb/s und vom 2. nur noch 15MB/s
obwohl die kiste nun über nacht lief und der 1. vorgang schon fertig ist braucht der 2. noch eine stunde.
ich habe jetzt den letzten dd gestartet jedoch wirds vor 21Uhr heute abend nix mit dem basteln so wie es aussieht.
meine frage nun:
1.
wieso komme ich nirgendwo mehr annähernd auf 50MB/s oder insgesamt zumindestens?
es findet doch nur je festplatte entweder ein lese- oder schreibzugriff statt.
ärgert mich schon ein bisschen denn ich habe dafür nur noch heute zeit danach muss die diagnose feststehen.
2..
nachdem die 1. festplatte worauf sich die boot partition befand kopiert war habe ich damit mal versucht bis zum grub zu kommen was mir aber nicht gelang.
wieso? ich dachte nun wäre alles wie auf dem 1.original und damit lässt sich das system zumindestens bis zur fehlerausgabe hoch fahren.
ich habe nun am freitag den 13. passender weise den kopiervorgang mit dd begonnen.
ich habe 2 2TB festplatten auf denen ich nun jeweils 3 partitonen angelegt habe.
jeweils einmal die raid 1 boot partition und zwei raid 5 partitionen.
also insgesamt 6 primäre partitionen auf 2 festplatten.
das boot flag wurde automatisch mit sfdisk | sfdisk übernommen jedoch musste ich die jeweils dritte partition mit gparted selbst anlegen. dort konnte ich leider auch kein raid flag setzen.
mal schauen ob es damit noch probleme gibt.
ich habe in mehreren schritten den kopiervorgang durchgeführt
zu erst die erste original festplatte 1:1 auf den klon kopiert ca. 90MB/s
danach die zweite genau so jedoch zusätzlich von der 3.original festplatte auf die 3.partiton der 1. klon festplatte.
hier betrug die geschwindigkeit vom zu erst gestarteten dd vorgang 77Mb/s und vom 2. nur noch 15MB/s
obwohl die kiste nun über nacht lief und der 1. vorgang schon fertig ist braucht der 2. noch eine stunde.
ich habe jetzt den letzten dd gestartet jedoch wirds vor 21Uhr heute abend nix mit dem basteln so wie es aussieht.
meine frage nun:
1.
wieso komme ich nirgendwo mehr annähernd auf 50MB/s oder insgesamt zumindestens?
es findet doch nur je festplatte entweder ein lese- oder schreibzugriff statt.
ärgert mich schon ein bisschen denn ich habe dafür nur noch heute zeit danach muss die diagnose feststehen.
2..
nachdem die 1. festplatte worauf sich die boot partition befand kopiert war habe ich damit mal versucht bis zum grub zu kommen was mir aber nicht gelang.
wieso? ich dachte nun wäre alles wie auf dem 1.original und damit lässt sich das system zumindestens bis zur fehlerausgabe hoch fahren.
- Soong
- Beiträge: 207
- Registriert: 09.05.2011 11:05:26
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Verschlüsseltes Raid 5 -- Crash
Erst mal grundsätzlich: Ich hätte die Platten nicht in Partitionen kopiert, weil du sonst am Anfang der zweiten und dritten Partition wieder eine Partitionstabelle hast, die da nicht hingehört. Ich würde auf den neuen Platten jeweils eine große Partition erstellen und darin dann zwei Images.
zu 1. Sind das IDE-Platten? Falls ja, dann liegt es daran, dass jeweils nur Master oder Slave angesprochen werden kann. Falls es SATA-Platten sind, nehme ich an, dass der Controller einfach nicht mehr Leistung hergibt. Oder eine der Platten ist defekt.
zu 2. Wahrscheinlich hast du nicht die Platte, sondern nur die Boot-Partition kopiert und es fehlt der MBR. Was meldet dein System denn? Ich vermute etwas in der Richtung von "Boot device not found.". Wenn das der Fall ist, habe ich mit meiner Vermutung Recht, falls nicht, schreib doch mal was genau passiert.
zu 1. Sind das IDE-Platten? Falls ja, dann liegt es daran, dass jeweils nur Master oder Slave angesprochen werden kann. Falls es SATA-Platten sind, nehme ich an, dass der Controller einfach nicht mehr Leistung hergibt. Oder eine der Platten ist defekt.
zu 2. Wahrscheinlich hast du nicht die Platte, sondern nur die Boot-Partition kopiert und es fehlt der MBR. Was meldet dein System denn? Ich vermute etwas in der Richtung von "Boot device not found.". Wenn das der Fall ist, habe ich mit meiner Vermutung Recht, falls nicht, schreib doch mal was genau passiert.
The strength of a civilization is not measured by its ability to fight wars, but rather by its ability to prevent them.
-Gene Roddenberry
Mitglied bei der Free Software Foundation oder der Free Software Foundation Europe werden oder kostenlos die Free Software Foundation Europe unterstützen!
-Gene Roddenberry
Mitglied bei der Free Software Foundation oder der Free Software Foundation Europe werden oder kostenlos die Free Software Foundation Europe unterstützen!
Re: Verschlüsseltes Raid 5 -- Crash
naja.... wäre vielleicht besser gewesen....
habe warscheinlich wirklich nur die boot partition kopiert... ist auch erst mal nicht so wichtig hauptsache ich komm an die daten.
alles mit sata angeschlossen
erst mal ein anderes problem...
ich habe nun versucht mit dem live system das raid zu starten
mit mdadm --assemble --scan
hängt er eine platte vom raid 1 automatisch ein und eine platte vom raid 5
raid 1 wird im degraded modus gestartet jedoch raid 5 aufgrund fehlender weiterer 3 platten bleibt uneingehangen.
wenn ich versuche es manuell zu machen sagt er mir das die superblocks fehlen
mit dumpe2fs lassen sich auch keine alten superblocks anzeigen.. (vielleicht nur nicht mitkopiert) komischerweise ist es ja bei 2 festplatten ok....
in einem anderen forum wurde das problem mit den superblocks besprochen und diese lösung gefunden...
The solution was to recreate the RAID array. This sound counter-intuitive: if we recreate a raid array over an existing one, it will be erased ! Right ? Wrong ! As it is said on debian-user-french, mdadm is smart enough to “see” that HDD of the new array were elements of a previous one. Knowing that, mdadm will try to do its best (i.e. if parameters match the previous array configuration) and rebuild the new array upon the previous one in a non-destructive way, by keeping HDD content.
also ein neues create mit mdadm .
mdadm --create /dev/md1 --level=5 --raid-devices=5 /dev/sda2 /dev/sdb2 /dev/sda3 /dev/sdb3 missing
dies funktioniert bei mir jedoch auch nicht --> /dev/sda1 no such file or directory
UPDATE:
(Mit einer debian live cd ging es und er hat das raid neu zusammengesetzt(späteres posting))
jedoch gibt auch lsmod | grep md_mod nichts aus obwohl ich eine neue ubuntu live cd benutze und es mit apt-get install md hinzufügen musste obwohl es angeblich seit version 9.... enthalten sein soll....
zb mdadm --examine /dev/sda1
gibt ein cannot open /dev/sda1 no souch file or directory aus
(liegt das an der verschlüsselung das er das nicht öffnen kann?)
also auch ein mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1 --force
gibt nur /dev/sda1 has no superblock aus... wie kann ich das umgehen?
(wurde umgangen mit debian live cd und mdadm create s.o. (jetzt keinen zugriff mehr mit cryptsetup)(falsche reihenfolge?)
EDIT:
habe jetzt mal mit ls /dev/ geguckt ob es überhaupt ein sda1 gibt und siehe da... es gibt nur /dev/sda und /dev/sdb also die festplatten selbst... und kein partitions pfad statt dessen gibt es jetzt dm-0 dm-1 dm-2 dm-3
naja... wo sind jetzt die einzelnen partitionen (4 Raid5 und 2 Raid1) ?
das raid 5 scheint in dm-3 versteckt zu sein
wenn ich mdadm --examine /dev/md-3 eingebe wird ein der raid 5 superblock gefunden und active wird angezeigt?
jedoch gibt ein mdadm --detail /dev/md-3
does not appear to be an md device aus.
wie nun weiter?
wie hänge ich es ein oder ist es das schon und ich kann jetzt mit crypt versuchen drauf zu zu greifen?
ein cryptsetup luksOpen /dev/md-3 lukslvm sagt schon mal das es da etwas findet jedoch kommt nach schlüssel eingabe ein
no key available with this passphrase
(mit debian live cd und mdadm --create sagt luks jetzt das darauf kein crypt volume ist)(falsche reihenfolge der festplatten?)
was sagt mir das? ist hier schluss?
habe warscheinlich wirklich nur die boot partition kopiert... ist auch erst mal nicht so wichtig hauptsache ich komm an die daten.
alles mit sata angeschlossen
erst mal ein anderes problem...
ich habe nun versucht mit dem live system das raid zu starten
mit mdadm --assemble --scan
hängt er eine platte vom raid 1 automatisch ein und eine platte vom raid 5
raid 1 wird im degraded modus gestartet jedoch raid 5 aufgrund fehlender weiterer 3 platten bleibt uneingehangen.
wenn ich versuche es manuell zu machen sagt er mir das die superblocks fehlen
mit dumpe2fs lassen sich auch keine alten superblocks anzeigen.. (vielleicht nur nicht mitkopiert) komischerweise ist es ja bei 2 festplatten ok....
in einem anderen forum wurde das problem mit den superblocks besprochen und diese lösung gefunden...
The solution was to recreate the RAID array. This sound counter-intuitive: if we recreate a raid array over an existing one, it will be erased ! Right ? Wrong ! As it is said on debian-user-french, mdadm is smart enough to “see” that HDD of the new array were elements of a previous one. Knowing that, mdadm will try to do its best (i.e. if parameters match the previous array configuration) and rebuild the new array upon the previous one in a non-destructive way, by keeping HDD content.
also ein neues create mit mdadm .
mdadm --create /dev/md1 --level=5 --raid-devices=5 /dev/sda2 /dev/sdb2 /dev/sda3 /dev/sdb3 missing
dies funktioniert bei mir jedoch auch nicht --> /dev/sda1 no such file or directory
UPDATE:
(Mit einer debian live cd ging es und er hat das raid neu zusammengesetzt(späteres posting))
jedoch gibt auch lsmod | grep md_mod nichts aus obwohl ich eine neue ubuntu live cd benutze und es mit apt-get install md hinzufügen musste obwohl es angeblich seit version 9.... enthalten sein soll....
zb mdadm --examine /dev/sda1
gibt ein cannot open /dev/sda1 no souch file or directory aus
(liegt das an der verschlüsselung das er das nicht öffnen kann?)
also auch ein mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1 --force
gibt nur /dev/sda1 has no superblock aus... wie kann ich das umgehen?
(wurde umgangen mit debian live cd und mdadm create s.o. (jetzt keinen zugriff mehr mit cryptsetup)(falsche reihenfolge?)
EDIT:
habe jetzt mal mit ls /dev/ geguckt ob es überhaupt ein sda1 gibt und siehe da... es gibt nur /dev/sda und /dev/sdb also die festplatten selbst... und kein partitions pfad statt dessen gibt es jetzt dm-0 dm-1 dm-2 dm-3
naja... wo sind jetzt die einzelnen partitionen (4 Raid5 und 2 Raid1) ?
das raid 5 scheint in dm-3 versteckt zu sein
wenn ich mdadm --examine /dev/md-3 eingebe wird ein der raid 5 superblock gefunden und active wird angezeigt?
jedoch gibt ein mdadm --detail /dev/md-3
does not appear to be an md device aus.
wie nun weiter?
wie hänge ich es ein oder ist es das schon und ich kann jetzt mit crypt versuchen drauf zu zu greifen?
ein cryptsetup luksOpen /dev/md-3 lukslvm sagt schon mal das es da etwas findet jedoch kommt nach schlüssel eingabe ein
no key available with this passphrase
(mit debian live cd und mdadm --create sagt luks jetzt das darauf kein crypt volume ist)(falsche reihenfolge der festplatten?)
was sagt mir das? ist hier schluss?
Zuletzt geändert von mooboo am 16.01.2012 18:47:41, insgesamt 6-mal geändert.