Archiv verlassen und diese Seite im Standarddesign anzeigen : Festplatte für den Ausfall spiegeln (mit dd)
Hi @ll,
ich möchte eine Festplatte (die mit der root-Parition) in meinem openSuSE System spiegeln für denn Fall, dass die alte abbrennt oder ähnliches.
Es sollte so sein, dass im Problemfall ich die defekte Platte aus dem System rausziehen kann und stattdessen mein Backup hereinstecke und alles funktioniert wie immer (unter der Annahme, das sonst alle Hardware noch funktioniert).
Dafür habe ich mit
dd if=/dev/sda of=/dev/sdb
(EDIT: Ja, die neue Platte ist größer als die Alte)
von einer Linux livecd (sysresccd) aus die Festplatte gespiegelt.
Dann habe ich auf dem clone noch in der /etc/fstab die links nach /dev/disk/by-id/... angepasst und das gleiche noch in der /boot/grub/menu.lst
Leider meckert der Computer beim hochfahren mit der geklonten Platte jetzt "reiserfs superblock cannot be found on /dev/disk/by-id/..."
Das Rootdateisystem mountet er allerdings korrekt und lässt mich dann mit einer filesystem-rescue konsole hängen.
fsck meckert, dass fsck.reiserfs mit exit code 0x10 fehlgeschlagen ist und fordert mich zu "check manually" auf.
fsck.reiserfs direkt aufzurufen bringt nichts interessantes. Er fragt mich, ob er es wirklich tun soll ("Type yes") und dann beendet sich das Programm. Kein Fehler, kein Erfolg.
Das gleiche passiert auch bei fsck.reiserfs --rebuild-sb.
Jetzt gehen mir die Ideen aus...
ThorstenHirsch
02.05.09, 16:53
Das liegt daran, dass (seit nicht allzu langer Zeit) die Partitionen in der /etc/fstab über eine ID angesprochen werden. Das alte System war:
/dev/sda1
/dev/sda2
/dev/sdb1
...
Aber dabei ist nicht (mehr) sichergestellt, dass der Kernel bei jedem Booten /dev/sda und /dev/sdb in der Reihenfolge benennt wie beim letzten mal. Du hast also 2 Möglichkeiten:
a) auf das alte System zu wecheln und die Platte 1:1 zu spiegeln, aber mit der Gefahr leben, dass sich /dev/sda und b mal plötzlich tauschen
b) alles so lassen und im Ernstfall die ID auf der Austauschplatte ändern bevor sie benutzt werden kann (z.B. von einem Live-System booten, dort die ID anschauen, Platte mounten, /etc/fstab entsprechend ändern, speichern, unmounten, rebooten, Live-CD rausnehmen
Ich empfehle auf UUIDs zu wechseln (wenn das mit reiserfs geht).
UUIDs werden beim Klonen mit-gespiegelt. Das kann natürlich zu Problemen führen, wenn beide Platten gleichzeitig im System sind, sollte andere Probleme aber eliminieren.
Die Grub-Konfiguration dürfte auch problemlos kopiert werden, es sei denn, es ist eine komische Version von Grub oder Du betreibst die zweite Platte später nicht am selben Anschluss.
Und vielleicht ist es auch einfach Sinnvoll das System auf den LinuxSoftwareRAID umzustellen, einfach die Partitonstyp auf 0xfd stellen und mdadm das RAID erstellen.
Greeez Oli
Wenn man die Platten Raid-mäßig spiegelt, dann hilft das ja "nur" gegen einen Hardware-Defekt.
Wenn man einen funktionierenden Stand aufheben möchte, um bei Software-Problemen einfach die Platte tauschen zu können, dann bringt Raid ja nix.
Raid bringt auch nix im Falle einer Katastrophe, wie eines Brandes, weil ja beide Platten am Rechner in Betrieb sein müssen. Wenn Eine abfackelt, dann erwischt es wahrscheinlich auch die Andere. Zum Schutz vor Feuer muss man ein Backup mindestens in einem anderen Raum haben, aber am besten in entfernten Gebäuden.
hiTCH-HiKER
03.05.09, 11:51
Warum soll RAID da nicht helfen? Ich hab mir aus meinem RAID 5 öfter mal eine Platte rausgenommen, um sie anderweitig zu nutzen und das System lief mit den 2 verbliebenen problemlos weiter. Das sollte doch bei RAID 1 (Spiegelung) genauso funktionieren, d.h. beide Platten arbeiten unabhängig voneinander auch alleine in dem Rechner.
Wenn man die Platten Raid-mäßig spiegelt, dann hilft das ja "nur" gegen einen Hardware-Defekt.
Natürlich hilft das gegen Hardware Defekt, die Platten sind jedoch auch synchronisiert. Das Raid kein Backup ersetzt ist natürlich was anderes.
Raid bringt auch nix im Falle einer Katastrophe, wie eines Brandes, weil ja beide Platten am Rechner in Betrieb sein müssen. Wenn Eine abfackelt, dann erwischt es wahrscheinlich auch die Andere. Zum Schutz vor Feuer muss man ein Backup mindestens in einem anderen Raum haben, aber am besten in entfernten Gebäuden.
Oergs man kann auch übertreiben, wenn die Hütte brennt dann nützt auch eine Ersatzplatte im Tresor nichts und da die Maschine wahrscheinlich hinüber ist nutzt die Ersatzplatte in Gebäude Xy praktisch auch nix mehr, da davon auszugehen ist das die neue Maschine eine andere Hardware hat.
Man könnte jetzt natürlich hergehen......... eine Darkfibreleitung in einen Ort am anderen Ende der Welt zu legen.... um sein Schreibtischrechner in ein Datacenter zu spiegeln..... wenn man sich das leisten kann. :ugly:
Wenn mans billiger will kann man auch irgendwo vom nächsten SAN boote:pn.
Man muss ja nicht immer die Platten im Rechner zum booten nehmen. ;)
By the way, wir reden hier schon von einem Privatarbeitsplatz und nicht von einer HA Umgebung, oder?
Dann tuts nämlich auch einfach mal Ghost4linux, oder was vergleichbares.
Wenn mans billiger will kann man auch irgendwo vom nächsten SAN boote:pn.
Mit Windows, iSCSI und den passenden NICs geht das sogar ganz gut. Und das auch mit kleinem Budget. :D
Mit Windows, iSCSI und den passenden NICs geht das sogar ganz gut. Und das auch mit kleinem Budget. :D
Das äh große "Opensose Unix" kann das auch :D
Ich hab mich bei der Argumentationskette nur teilweise gefragt, ob das ganze atombombensicher und gegen höhere Gewalt gesichert werden soll. ;)
Andererseits ein Vorschlaghammer, hätte alle "Probleme" äh Sicherungen "erlöst".
Oergs man kann auch übertreiben, wenn die Hütte brennt dann nützt auch eine Ersatzplatte im Tresor nichts [...]Kommt darauf an, wie viel brennt, wie lange es brennt und ob es ein feuerfester Tresor/Schrank ist.
[...] da die Maschine wahrscheinlich hinüber ist nutzt die Ersatzplatte in Gebäude Xy praktisch auch nix mehr, da davon auszugehen ist das die neue Maschine eine andere Hardware hat.Das stimmt so nicht ganz, im Gegensatz zu einigen anderen Betriebssystemen gehört Linux zu denen, die durchaus auch auf anderer Hardware laufen können. Es kommt natürlich ein bisschen darauf an, wie unterschiedlich die Systeme (Architektur usw.) sind und was alles speziell auf die Hardware angepasst war (z.B. Kernel ohne X86-Unterstützung, Compilieren der Software mit -march=..., etc.).
Außerdem muss es ja nach so einem GAU vielleicht nicht unbedingt laufen, vermutlich genügt es dann schon, wenn man wenigstens die wichtigsten Daten noch hat, die ja dann mit drauf wären.
ich möchte eine Festplatte (die mit der root-Parition) in meinem openSuSE System spiegeln für denn Fall, dass die alte abbrennt oder ähnliches.Vielleicht habe ich das "abbrennt" hier zu wörtlich genommen... Kann das sein?
Ich habe mich sowieso ein bisschen gewundert, wie begrenzt so ein Feuerchen doch sein muss, damit es den Rest der Hardware verschont, aber da ein Absatz zwischen diesem und dem nächsten Satz, in dem es um das tauschen der Platten geht, ist, dachte ich das Backup sei echt primär gegen Feuer & Co..
Das stimmt so nicht ganz, im Gegensatz zu einigen anderen Betriebssystemen gehört Linux zu denen, die durchaus auch auf anderer Hardware laufen können.
Ohne Dir jetzt nahe treten zu wollen.... aber das ist kein Alleinstellungsmerkmal von Linux.
Das konnte seinerzeit schon mein Windows 2000, das System hat zwei Motherboardwechse und mehrfachen Komponententaushcl überlebt. Meine damaligen SuSE oder Debian Installationen haben da schon die Grätsche gemacht.
Es kommt natürlich ein bisschen darauf an, wie unterschiedlich die Systeme (Architektur usw.) sind und was alles speziell auf die Hardware angepasst war (z.B. Kernel ohne X86-Unterstützung, Compilieren der Software mit -march=..., etc.).
Ich frage mich gerade was dein herumschmeissen mit "Pseudofachwoertern" eigentlich soll.
Außerdem muss es ja nach so einem GAU vielleicht nicht unbedingt laufen, vermutlich genügt es dann schon, wenn man wenigstens die wichtigsten Daten noch hat, die ja dann mit drauf wären.
Vielleicht habe ich das "abbrennt" hier zu wörtlich genommen... Kann das sein?
Daher hat der liebe IT Gott uns das Backup gegeben..... Ja das mit dem abbrennen hast Du wohl zu wörtlich genommen. ;)
Na wie auch immer schönen Sonntag Abend.
aber das ist kein Alleinstellungsmerkmal von Linux. Jo, hab' ich ja auch nicht behauptet.
Meine Linux-Systeme würden aber alle direkt auch mit anderen x86-Boards und i686-Prozessoren funktionieren. Da achte ich ein bisschen drauf. Nur die Sound- und X-Einstellungen müsste ich evtl. nachjustieren. Ich denke bei vielen Distros ist das ähnlich.
Ich frage mich gerade was dein herumschmeissen mit "Pseudofachwoertern" eigentlich soll.Welche "Pseudofachwörter" peilst Du denn nicht? Ich sehe ein, dass manches mehrdeutig ist, aber ich habe mich speziell auf Linux-Kernel und -Software bezogen.
Jo, hab' ich ja auch nicht behauptet.
Meine Linux-Systeme würden aber alle direkt auch mit anderen x86-Boards und i686-Prozessoren funktionieren. Da achte ich ein bisschen drauf. Nur die Sound- und X-Einstellungen müsste ich evtl. nachjustieren. Ich denke bei vielen Distros ist das ähnlich.
Das ist zwar höchst wahrscheinlich, aber meistens ist es einfacher sowas neu aufzusetzen, (zumindest bei dem räudigen x86 Krempel) jedenfalls heute. Da man ja ein Backup hat kann man auch die Homes und Serverdirectorys mit den gesicherten Datenbeständen in kurzer Zeit wieder flott kriegen. Ist ja nicht mehr so wie vor zehn Jahren als der Weg zu Fuss noch etwas steiniger war.
Welche "Pseudofachwörter" peilst Du denn nicht? Ich sehe ein, dass manches mehrdeutig ist, aber ich habe mich speziell auf Linux-Kernel und -Software bezogen.
Z.B. das da... bzw. hat das mit nicht peilen eher weniger zu tun....
chiedlich die Systeme (Architektur usw.) sind und was alles speziell auf die Hardware angepasst war (z.B. Kernel ohne X86-Unterstützung, Compilieren der Software mit -march=...,
Hat mit fachlicher Kompetenz und sinnvoller Argumentation mal gar nichts zu tun, eher mit aufblasen der Kernaussage durch sinnloses "Fachblafase" die Compiler Optionen interessieren Joe Normalo mal überhaupt nicht, damit werden Leute eher abgeschreckt als das sowas weiterhilft.
IMHO hat jeder von uns der schon länger dabei ist, Kernel übersetzt oder make.confs angelegt und ausgearbeitet. Sei es unter Linux oder sonst nem Unixoiden System. Spielt überhaupt keine Rolle, egal wie man das Kind nennt Unix ist Unix ob GNU, BSD oder what ever.
Wenn die jeweilige Linuxmaschine ein Sparc oder Power maschine ist, weiss wohl jeder Depp das es kein x86 ist.
Bei Opteron/EMT64 kann sich auch jeder ausrechnen das entweder x64 oder x86 drauf rennt und AMD/Intel gemeint ist. Ob ich da jetzt march=pentiumpro oder pentium, u opteron = AMD64 interessiert nicht mal am Rande. Völlig andere Baustelle und anderes Problem.
Die Prozessorarchitektur ist in 90 Prozent aller Fälle so interessant wie ein Sack Reis in China, wichtiger sind die Daten die man sichern will oder gegebenenfalls wieder zurück zu spielen hat.
IMHO läuft Datensicherung auf allen Rechnerarchiteturen gleich, Platten sind auch überall gleich, die Sicherungskonzepte auch. ;)
Ich werde bestimmt nicht aufhören sachdienliche Hinweise zu geben, nur weil irgend ein Technophober sich davor fürchten könnte. Hör' endlich auf zu trollen.
Das ist zwar höchst wahrscheinlich, aber meistens ist es einfacher sowas neu aufzusetzen, (zumindest bei dem räudigen x86 Krempel) jedenfalls heute.Geht mir absolut nicht so. Ein gut laufendes System einfach nur auf veränderte Hardware umzustellen ist in den meisten Fällen sehr einfach.
Nur wenn man sein System speziell so auf eine bestimmte Hardware anpasst, dass man z.B. gcc mit -march=... zum Compilieren nimmt oder eben in der Kernel-Konfiguration CONFIG_X86_GENERIC aka. "Generic x86 support" deaktiviert, dann läuft das System schon bei geringen Abweichungen in der Hardware nicht mehr und das sind Fakten, die sich hervorragend als Beispiel eignen und daher liefere ich diese Hintergrundinformationen auch. Da kannst Du noch so viel behaupten, dass sie nix damit zu tun hätten. Wer sich auskennt sieht den Zusammenhang und wer nicht, der weiß jetzt wenigstens, dass es sowas gibt; auch wenn er mit dem Beispiel direkt vielleicht jetzt nix anfangen kann.
Bei Opteron/EMT64 kann sich auch jeder ausrechnen das entweder x64 oder x86 drauf rennt und AMD/Intel gemeint ist. Ob ich da jetzt march=pentiumpro oder pentium, u opteron = AMD64 interessiert nicht mal am Rande. Völlig andere Baustelle und anderes Problem.
Die Prozessorarchitektur ist in 90 Prozent aller Fälle so interessant wie ein Sack Reis in China, wichtiger sind die Daten die man sichern will oder gegebenenfalls wieder zurück zu spielen hat.Ach, jetzt ist plötzlich alles egal und nicht mehr wichtig... Du warst es doch, der behauptet hatte:
[...] da die Maschine wahrscheinlich hinüber ist nutzt die Ersatzplatte in Gebäude Xy praktisch auch nix mehr, da davon auszugehen ist das die neue Maschine eine andere Hardware hat.Komisch, dass da die Hardware noch wichtig war. Nun, da ich angeführt habe, dass sie nur wichtig ist, wenn man besondere Optimierungen benutzt (von denen Du selbst behauptest, sie "interessieren Joe Normalo mal überhaupt nicht") und man das komplette System im Backup gleich nutzen möchte, da ist sie auf einmal nicht mehr wichtig, oder was. Der Herr legt es sich wohl gerne so zurecht, wie es ihm Spaß macht, wie.
Entscheide Dich mal, solarix.
Ich werde bestimmt nicht aufhören sachdienliche Hinweise zu geben, nur weil irgend ein Technophober sich davor fürchten könnte. Hör' endlich auf zu trollen.
Trollen. :D
Wie kommst Du auf das schmale Brett harr.
:ugly:
Geht mir absolut nicht so. Ein gut laufendes System einfach nur auf veränderte Hardware umzustellen ist in den meisten Fällen sehr einfach.
Das hat auch keiner bestritten.
[qute]
Nur wenn man sein System speziell so auf eine bestimmte Hardware anpasst, dass man z.B. gcc mit -march=... zum Compilieren nimmt oder eben in der Kernel-Konfiguration CONFIG_X86_GENERIC aka. "Generic x86 support" deaktiviert, dann läuft das System schon bei geringen Abweichungen in der Hardware nicht mehr und das sind Fakten, die sich hervorragend als Beispiel eignen und daher liefere ich diese Hintergrundinformationen auch.
[/quote]
Nicht jeder geht diesen Weg, insbesondere wenn es ums Geld geht wird solcher Unfug sowieso nicht gemacht.
Da kannst Du noch so viel behaupten, dass sie nix damit zu tun hätten. Wer sich auskennt sieht den Zusammenhang und wer nicht, der weiß jetzt wenigstens, dass es sowas gibt; auch wenn er mit dem Beispiel direkt vielleicht jetzt nix anfangen kann.
Solche Beispiele sind gut aufgehoben in Büchern Fachartikeln aber nicht unbedingt in einem Forenbeitrag wenn jemand nur eine "verständliche" Lösung für sein Problem will. Zuviel Information kann auch verwirren, schon mal drüber nach gedacht?
Ach, jetzt ist plötzlich alles egal und nicht mehr wichtig... Du warst es doch, der behauptet hatte:Komisch, dass da die Hardware noch wichtig war. Nun, da ich angeführt habe, dass sie nur wichtig ist, wenn man besondere Optimierungen benutzt (von denen Du selbst behauptest, sie "interessieren Joe Normalo mal überhaupt nicht")
Optimierung interessieren ausser Gentoo(lern) sowies keinen. :D
Wenn jemand seine Platte klonen will interessieren gcc Build Options nicht wirklich, oder ?
und man das komplette System im Backup gleich nutzen möchte, da ist sie auf einmal nicht mehr wichtig, oder was. Der Herr legt es sich wohl gerne so zurecht, wie es ihm Spaß macht, wie.
Use the right tool for the right job. ;)
Was bist eigentlich so genervt?
Ich freue mich, dass ich es geschafft habe solch viele Gedanken anzuregen, allerdings ist es leider sehr off topic geworden...
Ich spezifiziere mal was genauer:
Es handelt sich um einen kleinen Büroserver mit einer einstelligen Anzahl an verbundenen Computern.
Der Hauptzweck der gespiegelten Festplatte ist menschlichen Fehlern vorzubeugen. Irgendjemand schafft es irgendwie das System zu zerschießen (vielleicht bootet es nach einen Stromausfall nicht mehr, vielleicht löscht jemand ein paar wichtige Systemdateien), ich bin nicht in der Nähe und jemand anderes, der etwas weniger Erfahrung hat soll jetzt erstmal das System so schnell wie möglich wieder ans laufen bekommen, bis das eigentliche Problem gelöst werden kann. Dann ist es natürlich sehr praktisch, wenn es eine gespiegelte Platte gibt und einfach nur Festplatte raus andere Platte rein und schon läuft erstmal das Notsystem.
Sollte der Computer mal wirklich in Flammen aufgehen, dann ist es natürlich auch noch ein super Nebeneffekt, dass es diese Backupplatte gibt von der noch einige Daten geholt werden können. Das ist allerdings eher ein cooler Nebeneffekt und so wörtlich war es - wie oziris richtig bemerkt hat - nicht gemeint.
Das liegt daran, dass (seit nicht allzu langer Zeit) die Partitionen in der /etc/fstab über eine ID angesprochen werden. Das alte System war:
/dev/sda1
/dev/sda2
/dev/sdb1
...
[..]
b) alles so lassen und im Ernstfall die ID auf der Austauschplatte ändern bevor sie benutzt werden kann (z.B. von einem Live-System booten, dort die ID anschauen, Platte mounten, /etc/fstab entsprechend ändern, speichern, unmounten, rebooten, Live-CD rausnehmen
Das habe ich versucht:
Dann habe ich auf dem clone noch in der /etc/fstab die links nach /dev/disk/by-id/... angepasst und das gleiche noch in der /boot/grub/menu.lst
Bevor ich das gemacht habe bekam ich nur die Meldung "Waiting vor ... to appear". Aber soweit bin ich noch alleine gekommen ;-).
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.