Baremetal Restore mit Bordmitteln

[tkreutz]

Hallo Zusammen,

dass man ein bestehendes Live-System leicht virtualisieren und in eine VM migrieren kann, ist klar. Mit entsprechenden Tools ist auch ein Bare Metal Restore auf geänderter Hardware möglich. Meine Frage in diesem Zusammenhang - gibt es auch Bordmittel, mit denen ein Bare Metal Restore möglich wäre zur Übertragung eines Komplettsystems auf veränderter Hardware. Oder würdet ihr in diesem Fall das System generell von Grund auf immer komplett neu aufsetzen und von einem Netzwerkspiegel gleich die Aktualisierungen laden ?

Hintergrund ist die Überlegung für ein opensourcebasiertes Warenwirtschaftssystem (Adempiere) und ein damit verbundenes Backup- Restorekonzept bei dem Einsatz eben auf nicht virtualisierten Systemen, wenn es schnell gehen soll und genau der Stand wiederhergestellt werden soll, der gerade im Einsatz war. Klar, dass der Einsatz von Virtualisierungssystemen dann die Alternative ist und klar, dass man auch relativ schnell ein System neu aufsetzen kann. Aber es würde mich halt einfach mal interessieren - ist ja möglich, dass es da schon was gibt.

Die Variante, immer ein Image anzufertigen und im Bedarfsfall wieder zurück zu spielen, ist natürlich auch bekannt. Aber wie der Teufel es so will, ändert sich ja die Hardware auch mal in kleinen Details und dann käme eben "Kernel Panic". Deswegen die Frage.

Danke.

Gruss
Thorsten

[pferdefreund]

Also das mit dem Image sollte eigentlich kein Problem sein, weil ja im normalen Kernel alle notwendigen Module für alle Hardware vorhanden sind(gleiche Architektur vorausgesetzt). Ich habe schon oft - auch zum Testen der Sicherung mein System komplett per tar gesichert und einfach mit ner LIve-Rescue-CD in einer Vm wieder entpackt. Bootloader neu geschrieben (in der VM) - Maschine gestartet und alles lief, wie es sein sollte. Das einzige Problem sind dann eventuell unfreie Grafiktreiber die fehlen - aber die freien sollten - mal von Spielen - für ein Warenwirtschaftssystem völlig ausreichen.
Natürlich sollte während der Sicherung keine Datenbank oder sowas aktiv sein - aber das versteht sich ja von selbst. Es kann höchstens mal sein, das unter /var/run noch ne alte PID mitgesichert wurde, die dann den Start eines Dienstes verhindert - aber das ist mir bisher nicht vorgekommen und läßt sich durch manuelles Entsorgen und Starten des Dienstes problemlos regeln. Die Datenbanken - z. B Postgreqsl sichert man eh dann extra per pg_dumpall > /irgend/wo/hin direkt vor dem Backup oder man beendet die Datenbank vor dem Backup - dann kann man die gleich mitsichern.
Einmal hab ich dabei erlebt, dass wohl udev gesponnen hat - ob wegen der VM - keine Ahnung aber nach einem erneuten Neustart hat sich das von alleine geregelt und alles war gut.

[tkreutz]

Ah super - dann probier ich dass auch mal. Klar - für Warenwirtschaft und Datenbank selbst gibt es natürlich entsprechende eigenständige Sicherungsjobs. Danke.

[TRex]

Ich glaube, dass sich udev die Netzwerkkarten merkt und darum hättest du im wiederhergestellten System vermutlich eth1 statt eth0. Um dem entgegenzuwirken, kannst du /etc/udev/rules.d/70-persistent-net.rules löschen oder die Definition in der interfaces(5) korrigieren.

[tkreutz]

Ich glaube, dass sich udev die Netzwerkkarten merkt und darum hättest du im wiederhergestellten System vermutlich eth1 statt eth0. Um dem entgegenzuwirken, kannst du /etc/udev/rules.d/70-persistent-net.rules löschen oder die Definition in der interfaces(5) korrigieren.

Das ist eine gute Anmerkung - Versuch macht klug.