Hallo Leute.
Ich hab hier ein System (hauptsächlich Mailserver) mit zwei identischen
Platten, und ich würde gerne regelmäßig die eine Platte auf die andere
spiegeln. Um Zugriffe von außen auszuschließen dachte ich, ich mach das im
singleuser-mode.
Nehmen wir also so ein Skript:
init 1
dd if=/dev/hda of=/dev/hdc
init 3
Nur funktioniert das natürlich nicht, weil init 1 mit ner Paßwortabfrage
abschließt, und weil dd schon anfängt zu laufen, während noch der Runlevel
gewechselt wird.
Gibt es eine Möglichkeit, wie ich trotzdem den Runlevel wechseln kann, bevor
ich spiegle, sodaß ich das ganze in einen cronjob für Samstag nacht oder so
packen kann?
--
Andreas Feile
Hallo Andreas, * On Sat, 23 Feb 2002 at 10:19 +0100, Andreas Feile wrote:
Ich hab hier ein System (hauptsächlich Mailserver) mit zwei identischen Platten, und ich würde gerne regelmäßig die eine Platte auf die andere spiegeln. Um Zugriffe von außen auszuschließen dachte ich, ich mach das im singleuser-mode. Nehmen wir also so ein Skript:
init 1 dd if=/dev/hda of=/dev/hdc init 3
Nur funktioniert das natürlich nicht, weil init 1 mit ner Paßwortabfrage abschließt, und weil dd schon anfängt zu laufen, während noch der Runlevel gewechselt wird.
Wieso willst du die Platte eigentlich auf diese Art spiegeln? Ich würde auf jeden Fall ein Software RAID1 verwenden, da 1. das Spiegeln erfolgt kontinuierlich im Betrieb 2. bei Ausfall einer Platte, läuft das System unbehindert weiter --> erhöhte Ausfallssicherheit
Gibt es eine Möglichkeit, wie ich trotzdem den Runlevel wechseln kann, bevor ich spiegle, sodaß ich das ganze in einen cronjob für Samstag nacht oder so packen kann?
-- Grüsse, Jürgen Ken Thompson has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gage, nor any of the numerous idiot lights which plague the modern driver. Rather, if the driver makes any mistake, a giant "?" lights up in the center of the dashboard. "The experienced driver", he says, "will usually know what's wrong."
At Samstag, 23. Februar 2002 10:46 Juergen Dattl wrote:
Wieso willst du die Platte eigentlich auf diese Art spiegeln? Ich würde auf jeden Fall ein Software RAID1 verwenden, da 1. das Spiegeln erfolgt kontinuierlich im Betrieb 2. bei Ausfall einer Platte, läuft das System unbehindert weiter --> erhöhte Ausfallssicherheit
RAID hilft aber nicht dagegen, daß ein Prozeß Blödsinn schreibt. Dies würde
sich dann sofort auf beiden Platten niederschlagen. Bei meiner Strategie
stünden hingegen die Chancen gut, daß ich den Blödsinn mitkriege, noch bevor
die Platte das nächste Mal gespiegelt wird. Dann könnte ich mit der
gespiegelten Platte weiterarbeiten, bzw. ein dd if=/dev/hdc of=/dev/hda
machen.
--
Andreas Feile
* On Sat, 23 Feb 2002 at 11:09 +0100, Andreas Feile wrote:
At Samstag, 23. Februar 2002 10:46 Juergen Dattl wrote:
Wieso willst du die Platte eigentlich auf diese Art spiegeln? Ich würde auf jeden Fall ein Software RAID1 verwenden, da 1. das Spiegeln erfolgt kontinuierlich im Betrieb 2. bei Ausfall einer Platte, läuft das System unbehindert weiter --> erhöhte Ausfallssicherheit
RAID hilft aber nicht dagegen, daß ein Prozeß Blödsinn schreibt. Dies würde sich dann sofort auf beiden Platten niederschlagen. Bei meiner Strategie stünden hingegen die Chancen gut, daß ich den Blödsinn mitkriege, noch bevor die Platte das nächste Mal gespiegelt wird. Dann könnte ich mit der gespiegelten Platte weiterarbeiten, bzw. ein dd if=/dev/hdc of=/dev/hda machen.
Andere Variante: Nimm die zweite Platte als Container für Backups[1]; in Deinem Skript stoppst Du einfach alle relevanten Dienste (rcxxx stop), machst mit tar/cpio/afio ein "Backup" auf die zweite Platte, und startest den Krempel wieder. Dann kannst Du - sofern Platz ist - auch noch ein paar inkrementelle Backups unterbringen, was wiederum Deine Chancen erhöht :-) [1] Soetwas praktiziere ich auch mit meinem /home - wöchentlich ein volles Backup auf Platte, täglich ein Inkrementelles. -- Adalbert PGP welcome, request public key: mailto:adalbert+key@lopez.at
At Samstag, 23. Februar 2002 11:06 Adalbert Michelic wrote:
Andere Variante: Nimm die zweite Platte als Container für Backups[1]; in Deinem Skript stoppst Du einfach alle relevanten Dienste (rcxxx stop), machst mit tar/cpio/afio ein "Backup" auf die zweite Platte, und startest den Krempel wieder.
Das ist ein Weg, den ich auch schon erwogen habe. M.E. spricht aber dagegen,
daß ich im Falle des Plattencrashes der Hauptplatte nicht einfach mit der
anderen Platte weitermachen kann, sondern erst langwierig eine neue Platte
partitionieren, bootfähig machen usw. muß.
Wie gesagt, das ist ein Mail-, time- und dhcp-Server, bei dem es nicht darauf
ankommt, daß ich jeden beliebigen Tagesstand wiederherstellen kann. Was
gesichert werden soll ist die laufende und lauffähige Konfiguration. Ob ein
paar Mails hops gehen ist völlig egal.
--
Andreas Feile
* On Sat, 23 Feb 2002 at 11:33 +0100, Andreas Feile wrote:
At Samstag, 23. Februar 2002 11:06 Adalbert Michelic wrote:
Andere Variante: Nimm die zweite Platte als Container für Backups[1]; in Deinem Skript stoppst Du einfach alle relevanten Dienste (rcxxx stop), machst mit tar/cpio/afio ein "Backup" auf die zweite Platte, und startest den Krempel wieder.
Das ist ein Weg, den ich auch schon erwogen habe. M.E. spricht aber dagegen, daß ich im Falle des Plattencrashes der Hauptplatte nicht einfach mit der anderen Platte weitermachen kann, sondern erst langwierig eine neue Platte partitionieren, bootfähig machen usw. muß.
Wie gesagt, das ist ein Mail-, time- und dhcp-Server, bei dem es nicht darauf ankommt, daß ich jeden beliebigen Tagesstand wiederherstellen kann. Was gesichert werden soll ist die laufende und lauffähige Konfiguration. Ob ein paar Mails hops gehen ist völlig egal.
Naja, dann stopp einfach die Dienste, und dd die Platte rüber. Am besten wäre es, wenn Du die Platte vor dem Kopieren read-only mounten kannst. Ansonsten würde ich mir überlegen, obs nicht besser ist, das Backup fileweise rüberzuspielen; wenn du ein dd aus einem rw gemounteten FS ziehst, kann das massiv in die Hose gehen. Du verwendest ja nicht zufälligerweise den LVM, oder? Da würde es ein super Feature namens "Snapshot" geben - damit kannst Du im Betrieb einen Schnappschuß eines lvs erzeugen - Zum backuppen greifst Du auf den snaphsot zu; wenn währenddessen das echte lv verändert wird, ändert sich der snapshot trotzdem nicht. -- Adalbert PGP welcome, request public key: mailto:adalbert+key@lopez.at
At Samstag, 23. Februar 2002 11:30 you wrote:
Am besten wäre es, wenn Du die Platte vor dem Kopieren read-only mounten kannst.
Kann ich das, einfach während des laufenden Systems die Dateisysteme umounten und als RO wieder einhängen?
Ansonsten würde ich mir überlegen, obs nicht besser ist, das Backup fileweise rüberzuspielen; wenn du ein dd aus einem rw gemounteten FS ziehst, kann das massiv in die Hose gehen.
Ja, fileweise wäre an sich nicht schlecht, bzw. mir auch lieber, wegen der Möglichkeit der Generationenbildung. Aber wie komme ich denn im Fall des Falles wieder ein laufendes System? Sagen wir, ich kaufe eine neue Festplatte, dann muß ich die doch wieder partitionieren usw., dann die Files wieder zurückziehen, dann noch irgendwie bootfähig machen usw. Sehr mühsam.
Du verwendest ja nicht zufälligerweise den LVM, oder? Da würde es ein super Feature namens "Snapshot" geben - damit kannst Du im Betrieb einen Schnappschuß eines lvs erzeugen - Zum backuppen greifst Du auf den snaphsot zu; wenn währenddessen das echte lv verändert wird, ändert sich der snapshot trotzdem nicht.
Ich kenne LVM nicht, kann ich das nachträglich noch einsetzen?
--
Andreas Feile
* On Sat, 23 Feb 2002 at 12:44 +0100, Andreas Feile wrote:
At Samstag, 23. Februar 2002 11:30 you wrote:
Am besten wäre es, wenn Du die Platte vor dem Kopieren read-only mounten kannst.
Kann ich das, einfach während des laufenden Systems die Dateisysteme umounten und als RO wieder einhängen?
Solange niemand drauf schreiben möchte, ja. syslog wäre da ein Kandidat. Mit lsof kannst Du das herausfinden, gefährlich sind Files, die in der Spalte FD ein u (read+write) oder w (nur write) haben. Aber nicht unmounten, nur remounten! mount -o remount,ro /usr
Ansonsten würde ich mir überlegen, obs nicht besser ist, das Backup fileweise rüberzuspielen; wenn du ein dd aus einem rw gemounteten FS ziehst, kann das massiv in die Hose gehen.
Ja, fileweise wäre an sich nicht schlecht, bzw. mir auch lieber, wegen der Möglichkeit der Generationenbildung. Aber wie komme ich denn im Fall des Falles wieder ein laufendes System? Sagen wir, ich kaufe eine neue Festplatte, dann muß ich die doch wieder partitionieren usw., dann die Files wieder zurückziehen, dann noch irgendwie bootfähig machen usw. Sehr mühsam.
Du kannst ja mal, wenn das System funktioniert, es z.B. aus dem Rettungsystem duplizieren, dann ist die zweite Platte gleich der ersten. Danach mountest Du aus Deinem Skript alle Partitionen, kopierst die Files rüber und unmountest dem Krempel wieder. Ich nehme an, /boot ist ein eigenes Filesystem, das würde ich nicht anrühren, sonst macht lilo eventuell Probleme. Mit dd solltest Du wirklich _nur_ ro gemountete Filesysteme kopieren, wenn Du ein FS kopierst, das in Verwendung ist, kann es sein, daß Du nachher massive Probleme hast, die Kopie zu verwenden (FS-Check musst Du sowieso machen, _auch_ bei ReiserFS) - der Kopiervorgang wird sicher ein paar Minuten dauern, in diesem Zeitraum kann sich viel ändern, bzw. kann es Dir passieren, daß ein Bitmap-Block geändert wird, während er gelesen wird, dann passen Anfang und Ende nciht mehr zusammen. Welches Filesystem verwendest Du eigentlich?
Du verwendest ja nicht zufälligerweise den LVM, oder? Da würde es ein super Feature namens "Snapshot" geben - damit kannst Du im Betrieb einen Schnappschuß eines lvs erzeugen - Zum backuppen greifst Du auf den snaphsot zu; wenn währenddessen das echte lv verändert wird, ändert sich der snapshot trotzdem nicht.
Ich kenne LVM nicht, kann ich das nachträglich noch einsetzen?
Sofern Du genügend Platz zum herumschieben der Files hast, ja. In Deinem Fall müsste es gehen, da Du ja eine "freie" Platte hast. D.h.: Auf zweiter Platte pv, vg und lvs anlegen, Zeug kopieren, ummounten, ganzen Krempel auf erster Platte einrichten, zurückkopieren und wieder zurückmounten. Bzgl. Einrichtung des LVM - da gibt ein gutes Howto, das würde ich mir mal reinziehen. Ich weiß aber nicht wie es mit snapshots+ReiserFS momentan aussieht, bei LVM 0.8final + ReiserFS 3.5.33 gehts nicht. Liegt IIRC am LVM. Allerdings ist zumindest mein LVM schon sehr alt, also bestehen Chancen. Das Problem ist, daß ReiserFS beim Mounten das Journal abspielen will, dies aber nicht kann, da der snapshot nur read-only ist. PS: Bitte schick die Mails _nur_ an die Liste und nicht noch ein zweites an mich, ich lese mit. -- Adalbert PGP welcome, request public key: mailto:adalbert+key@lopez.at
At Samstag, 23. Februar 2002 16:31 Adalbert Michelic wrote:
Du kannst ja mal, wenn das System funktioniert, es z.B. aus dem Rettungsystem duplizieren, dann ist die zweite Platte gleich der ersten.
OK, Du meinst also aus dem Rettungssystem heraus dd etwa so starten: dd if=/dev/hda of=/dev/hdc
Danach mountest Du aus Deinem Skript alle Partitionen, kopierst die Files rüber und unmountest dem Krempel wieder. Ich nehme an, /boot ist ein eigenes Filesystem, das würde ich nicht anrühren, sonst macht lilo eventuell Probleme.
Dann brauch ich doch eigentlich nur noch diejenige Partition mounten, die (in der Produktivplatte) in / eingehängt ist. Denn /swap wird mich doch kaum interessieren. Kopiert man das am besten mit cp, oder gäbs da bessere MÖglichkeiten?
Welches Filesystem verwendest Du eigentlich?
Also in / ist ein ReiserFS eingehängt.
--
Andreas Feile
* On Sun, 24 Feb 2002 at 0:05 +0100, Andreas Feile wrote:
At Samstag, 23. Februar 2002 16:31 Adalbert Michelic wrote:
Du kannst ja mal, wenn das System funktioniert, es z.B. aus dem Rettungsystem duplizieren, dann ist die zweite Platte gleich der ersten.
OK, Du meinst also aus dem Rettungssystem heraus dd etwa so starten:
dd if=/dev/hda of=/dev/hdc
Ja, genau das.
Danach mountest Du aus Deinem Skript alle Partitionen, kopierst die Files rüber und unmountest dem Krempel wieder. Ich nehme an, /boot ist ein eigenes Filesystem, das würde ich nicht anrühren, sonst macht lilo eventuell Probleme.
Dann brauch ich doch eigentlich nur noch diejenige Partition mounten, die (in der Produktivplatte) in / eingehängt ist. Denn /swap wird mich doch kaum interessieren. Kopiert man das am besten mit cp, oder gäbs da bessere MÖglichkeiten?
IIRC macht cp manchmal troubles, ich würde es so machen: cd / && tar c -l . | ( cd /mnt/root_backup && tar x ) -> 1. Ins root wechseln 2. Tar Archiv erstellen, Ausgabe auf Standard-Ausgabe Parameter -l: Nur dieses eine Filesystem kopieren (damit /mnt/root_backup nicht rekuriv wieder wird - und wieder, und wieder ....) 3. Das ganze in eine neue Shell pipen, die zuerst das Verzeichnis wechselt, und dann Krempel entpackt. Ich habe angenommen, daß das / Deiner Backup-Platte nach /mnt/root_backup gemountet ist.
Welches Filesystem verwendest Du eigentlich?
Also in / ist ein ReiserFS eingehängt.
Aha. -- Adalbert PGP welcome, request public key: mailto:adalbert+key@lopez.at
At Sonntag, 24. Februar 2002 00:06 Adalbert Michelic wrote:
cd / && tar c -l . | ( cd /mnt/root_backup && tar x )
-> 1. Ins root wechseln 2. Tar Archiv erstellen, Ausgabe auf Standard-Ausgabe Parameter -l: Nur dieses eine Filesystem kopieren (damit /mnt/root_backup nicht rekuriv wieder wird - und wieder, und wieder ....) 3. Das ganze in eine neue Shell pipen, die zuerst das Verzeichnis wechselt, und dann Krempel entpackt.
Puh, das ist sehr trickreich. Muß mir das mal genauer reinziehen... Hab
jedenfalls vielen Dank für die Hilfe.
--
Andreas Feile
At Sonntag, 24. Februar 2002 00:06 Adalbert Michelic wrote:
cd / && tar c -l . | ( cd /mnt/root_backup && tar x )
-> 1. Ins root wechseln 2. Tar Archiv erstellen, Ausgabe auf Standard-Ausgabe Parameter -l: Nur dieses eine Filesystem kopieren (damit /mnt/root_backup nicht rekuriv wieder wird - und wieder, und wieder ....)
Man kapierts ja doch recht schnell... D.h. also wegen -l brauch ich mich auch
nicht darum zu kümmern, daß /boot und /swap unangetastet bleiben. Richtig?
Mir ist noch nicht ganz klar, wozu der . zwischen -l und | gut ist. Führt er
dazu, daß tar alles innerhalb des Filesystems erfaßt?
Und was wird tar tun, wenn manche Dateien im Zielsystem schon existieren? Da
find ich nix zu in man tar.
--
Andreas Feile
* On Sun, 24 Feb 2002 at 13:33 +0100, Andreas Feile wrote:
At Sonntag, 24. Februar 2002 00:06 Adalbert Michelic wrote:
cd / && tar c -l . | ( cd /mnt/root_backup && tar x )
-> 1. Ins root wechseln 2. Tar Archiv erstellen, Ausgabe auf Standard-Ausgabe Parameter -l: Nur dieses eine Filesystem kopieren (damit /mnt/root_backup nicht rekuriv wieder wird - und wieder, und wieder ....)
Man kapierts ja doch recht schnell... D.h. also wegen -l brauch ich mich auch nicht darum zu kümmern, daß /boot und /swap unangetastet bleiben. Richtig?
Ja, genau.
Mir ist noch nicht ganz klar, wozu der . zwischen -l und | gut ist. Führt er dazu, daß tar alles innerhalb des Filesystems erfaßt?
Der Punkt ist einfach das aktuelle Verzeichniss, also / . Eigentlich müsste es auch funktionieren, wenn Du "tar c -l /" machst, weil dann tar IIRC automatisch einen Punkt an den Anfang der Pfade stellt (damit die Pfade nicht absolut sind, sondern würde es beim auspacken wieder genau dorthin kommen, wos her ist)
Und was wird tar tun, wenn manche Dateien im Zielsystem schon existieren? Da find ich nix zu in man tar.
Überschreiben. Probleme treten u.U. auf, wenn Du Files löscht, da dann die Ziel-files nicht automatisch versschwinden. Dem könntest Du entgegenwirken, indem Du das Ziel-FS vor dem Kopieren komplett löscht, es wird ja eh dann alles kopiert. -- Adalbert PGP welcome, request public key: mailto:adalbert+key@lopez.at
Hallo Frank, * On Sat, 23 Feb 2002 at 11:19 +0100, Andreas Feile wrote:
At Samstag, 23. Februar 2002 11:06 Adalbert Michelic wrote:
Andere Variante: Nimm die zweite Platte als Container für Backups[1]; in Deinem Skript stoppst Du einfach alle relevanten Dienste (rcxxx stop), machst mit tar/cpio/afio ein "Backup" auf die zweite Platte, und startest den Krempel wieder.
Das ist ein Weg, den ich auch schon erwogen habe. M.E. spricht aber dagegen, daß ich im Falle des Plattencrashes der Hauptplatte nicht einfach mit der anderen Platte weitermachen kann, sondern erst langwierig eine neue Platte partitionieren, bootfähig machen usw. muß.
Dein Image setzt aber voraus, dass du mindestens eine Platte mit gleicher Grösse besitzt. Adalbert's bzw. meine Lösung setzt dies nicht voraus.
Wie gesagt, das ist ein Mail-, time- und dhcp-Server, bei dem es nicht darauf ankommt, daß ich jeden beliebigen Tagesstand wiederherstellen kann. Was gesichert werden soll ist die laufende und lauffähige Konfiguration. Ob ein paar Mails hops gehen ist völlig egal.
Ok, und was passiert, wenn du während deinem Synchronisationsvorgang einen Stromausfall hast, das / oder /usr Filesystem auf deiner 'Produktivplatte' Fehler bekommt und nicht wiederhergestellt werden kann? Dann hast du ein unkomplettes Image auf der 'Backupplatte' und ein kaputtes Produktivsystem. -- Grüsse, Jürgen The law will never make men free; it is men who have got to make the law free. -- Henry David Thoreau
Hallo Frank, * On Sat, 23 Feb 2002 at 10:54 +0100, Andreas Feile wrote:
At Samstag, 23. Februar 2002 10:46 Juergen Dattl wrote:
Wieso willst du die Platte eigentlich auf diese Art spiegeln? Ich würde auf jeden Fall ein Software RAID1 verwenden, da 1. das Spiegeln erfolgt kontinuierlich im Betrieb 2. bei Ausfall einer Platte, läuft das System unbehindert weiter --> erhöhte Ausfallssicherheit
RAID hilft aber nicht dagegen, daß ein Prozeß Blödsinn schreibt. Dies würde sich dann sofort auf beiden Platten niederschlagen.
stimmt.
Bei meiner Strategie stünden hingegen die Chancen gut, daß ich den Blödsinn mitkriege, noch bevor die Platte das nächste Mal gespiegelt wird. Dann könnte ich mit der gespiegelten Platte weiterarbeiten, bzw. ein dd if=/dev/hdc of=/dev/hda machen.
Gut, stimmt. Ich bin auch nicht davon ausgegangen, dass du die zweite Platte sozusagen als Backup verwenden willst. In diesem Fall würde ich sie trotzdem aber nicht direkt spiegeln, da ich so nur eine Generation habe. Sinnvoller wäre es imho zb * mit tar -c . | (cd /wodieplattehingemountetwurde && tar -xv) einen aktuellen Stand der Filesysteme anlegen * per cronjob dann täglich ein diff dazu und davon ein paar Generationen 'aufheben' Mit dieser Lösung kannst du, wenn du den Fehler nicht gleich bemerkst auch noch nach ein paar Tagen dein Filesystem wiederherstellen bzw. möglicherweise nach einem Einbruch, Spuren eines Hackers finden. -- Grüsse, Jürgen It is not true that life is one damn thing after another -- it's one damn thing over and over. -- Edna St. Vincent Millay
participants (3)
-
Adalbert Michelic -
Andreas Feile -
Juergen Dattl