Server sichern

[Chris©]

Hallo Server-Profis,

unser "Admin" liegt leider immer noch im Krankenhaus. Darum habe ich jetzt das Vergnügen, die Daten und die Einrichtung eines Linux-Servers zu sichern, damit der mit einer neuen Version bespielt werden kann.

Eigentlich handelt es ich nur noch um PHP und HTML, MySQL ist schon nicht mehr benutzt worden. Allerdings muss es wohl auch ein paar Speuieleinstellungen geben, weil teilweise "Bilddateien" als PHP geparst werden, irgendwelche htaccess-Schmankerln bestehen müssen usw.

Wie krieg ich denn das nun am besten raus?
Ich dachte an eine Sicherung der Verzeichnisse als TAR-Ball inclusive Rechtesicherung. Aber das wird für spezielle Einstellungen in confixx (für vier Virtual Hosts) eventuell nicht reichen, oder?

Wie mach ich das, damit der mögliche Schaden gering bleibt?

LG
Chris©

[Marc Reichelt]

Hallo Chris©,

Ich dachte an eine Sicherung der Verzeichnisse als TAR-Ball inclusive Rechtesicherung. Aber das wird für spezielle Einstellungen in confixx (für vier Virtual Hosts) eventuell nicht reichen, oder?

Wie mach ich das, damit der mögliche Schaden gering bleibt?

Ein TAR-Ball ist schon mal kein schlechter Anfang.
Ich würde beispielsweise rsync zum Sichern verwenden, aber das bleibt dir überlassen.

Eine Sicherung der gesamten Platte (aus einem Live-System heraus) beispielsweise mittels dem Befehl "dd" kann sehr nützlich sein, weil du damit das alte System komplett wiederherstellen kannst.
Allerdings ist die Dateigröße hier je nach Partitionsgröße recht hoch - mittels gzip lässt sich hier wenigstens der Traffic übers Netzwerk reduzieren.
Unter http://www.lug-kr.de/wiki/PartImage oder http://board.protecus.de/t17221.htm stehen einige Beispiele. Im ersten Artikel wird "partimage" erwähnt.

Achtung: Die Befehle sind kritisch! Du solltest dir immer genau darüber im Klaren sein, was der Befehl macht, bevor du ihn ausführst.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Alexander (HH)]

Moin Moin!

Wenn der Server so gründlich verbastelt ist, würde ich die Finger davon lassen. Das ist die sicherste Lösung. Und es kommt noch eine Frage auf: Wie werden die Daten im Moment gesichert? Gibt es kein tägliches Backup? Dann würde ich mich mal dezent nach einem Admin umsehen, für den Backup kein Fremdwort ist.

Von einem Image-Backup (dd) im laufenden Betrieb würde ich dringend abraten, das ergibt in aller Regel ein inkonsistentes Image. Wenn Image, dann offline. dd_rescue hat übrigens eine Fortschrittsanzeige und macht keine Panik, wenn die Quellplatte ein paar Lesefehler hat.

rsync auf ein anderes System ist eine gute Idee, wenn das andere System mit hoher Bandbreite erreichbar ist. Ich benutze dafür folgendes Kommando:

rsync -avzuxH -e "ssh -l remoteuser" --progress --copy-unsafe-links --numeric-ids /src remotehost:/dest

Parameter: a=archive, v=verbose, z=Datenstrom komprimieren, u=update, x=one filesystem (verhindert, dass sich rsync in /proc oder /sys verirrt), H=hardlinks, e=rsh-Ersatz, --progress=ausführliche Statusmeldung zu jeder Datei, --copy-unsafe-links=auch "unsichere" Symlinks kopieren, --numeric-ids=uid und gid statt Namen benutzen

Statt eines anderen Systems reicht auch eine ausreichend große externe Festplatte, typischerweise USB 2.0, Firewire oder eSATA -- entsprechenden Support im Kernel bzw. als Modul vorausgesetzt. Dann entfällt der Parameter "-e "ssh -l remoteuser", aus remotehost:/dest wird /mnt/externeplatte, und vor dem rsync-Lauf muß man die Platte unter /mnt/externeplatte mounten. Nach dem rsync-Lauf (ggf. mehrere, einen pro eingebundenem Dateisystem) natürlich wieder unmounten, bevor man die Platte abzieht. Auf der externen Platte sollte ein unixoides Dateisystem vorhanden sein, damit die Attribute gesichert werden können -- ext2, ext3, reiserfs, jfs, xfs. FAT in allen Ausprägungen ist hier nicht brauchbar.

Alexander

[Marc Reichelt]

Hallo Alexander,

Wenn der Server so gründlich verbastelt ist, würde ich die Finger davon lassen. Das ist die sicherste Lösung. Und es kommt noch eine Frage auf: Wie werden die Daten im Moment gesichert? Gibt es kein tägliches Backup? Dann würde ich mich mal dezent nach einem Admin umsehen, für den Backup kein Fremdwort ist.

Da hast du natürlich Recht. Es ist wesentlich besser, ein laufendes System laufen zu lassen.
Wenn man dieses laufende System ersetzen möchte sollte man sich am Besten ein Testsystem anlegen, auf dem man das gleiche System aufsetzt, nur von Hand.
Dann ist man auf Probleme vorbereitet, wenn man das gleiche System nochmal (nur produktiv) aufbauen möchte.

Von einem Image-Backup (dd) im laufenden Betrieb würde ich dringend abraten, das ergibt in aller Regel ein inkonsistentes Image. Wenn Image, dann offline. dd_rescue hat übrigens eine Fortschrittsanzeige und macht keine Panik, wenn die Quellplatte ein paar Lesefehler hat.

Ich meinte ja, dass man dies nur aus einem Live-System heraus machen sollte. Beispielsweise ein einfaches Rescue-System (die großen Server-Anbieter bieten das ja alles).

rsync auf ein anderes System ist eine gute Idee, wenn das andere System mit hoher Bandbreite erreichbar ist. Ich benutze dafür folgendes Kommando:
[...]
Statt eines anderen Systems reicht auch eine ausreichend große externe Festplatte, typischerweise USB 2.0, Firewire oder eSATA -- entsprechenden Support im Kernel bzw. als Modul vorausgesetzt. Dann entfällt der Parameter "-e "ssh -l remoteuser", aus remotehost:/dest wird /mnt/externeplatte, und vor dem rsync-Lauf muß man die Platte unter /mnt/externeplatte mounten. Nach dem rsync-Lauf (ggf. mehrere, einen pro eingebundenem Dateisystem) natürlich wieder unmounten, bevor man die Platte abzieht. Auf der externen Platte sollte ein unixoides Dateisystem vorhanden sein, damit die Attribute gesichert werden können -- ext2, ext3, reiserfs, jfs, xfs. FAT in allen Ausprägungen ist hier nicht brauchbar.

Man sollte auch beachten, dass der Parameter "x" (one-file-system) für rsync hier auf jeden Fall gesetzt sein sollte.
Ich hatte meine USB-Platte mal unter /mnt/backup eingebunden und rsync auf dem root-Verzeichnis _ohne_ den Parameter x gestartet. Die Folge war (ihr könnt es euch sicherlich schon denken), dass rsync einige Daten von / gesichert hat, um danach in /mnt/backup abzusteigen und alle dort bereits gesicherten Dateien nochmals zu sichern. Der Fehler passiert einem sicherlich nur ein Mal, trotzdem die Warnung hier.
Leute, die ihr System auf unterschiedliche Partitionen auslagern, müssen rsync mit dem Parameter "x" auch mehrmals starten (beispielsweise ein Mal auf /, ein Mal auf /var/log, wenn sich die auf eigenen Partitionen befinden).
Oder man verzichtet auf den Parameter "x" und gibt die zu sichernden Verzeichnisse manuell an - und lässt dabei "proc", "sys" und "mnt" weg.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Chris©]

Guten Morgen,

Wenn der Server so gründlich verbastelt ist, würde ich die Finger davon lassen. Das ist die sicherste Lösung. Und es kommt noch eine Frage auf: Wie werden die Daten im Moment gesichert? Gibt es kein tägliches Backup? Dann würde ich mich mal dezent nach einem Admin umsehen, für den Backup kein Fremdwort ist.

Vielleicht hätte ich es noch ausführlicher beschreiben müssen, aber der agressive Ton stört mich schon wieder. Unser Admin hat das mit dem Provider geregelt. Der macht täglich in einer Offtime eine Vollsicherung. Wir haben Zugriff auf T-1 bis T-3 und können uns die von dort dann selber in komprimierter Form herunterziehen.

Das nützt mir aber nichts, weil ich nicht das ganze System benötige, sondern nur unsere Programmen, Nutzdaten und Einstellungen. Ich weiß nur leider nicht, an welche Einstellungen ich denken muss. Es gibt noch vier Domains auf dem Server.

Gedacht habe ich bisher an:

www-Verzeichnisse

home-Verzeichnisse

mysql-Verzeichnis, da weiß ich nicht, ob ich es einfach so übermnehmen kann.
Es soll doch die DBMS-Version von 4 auf 5 geändert werden

aus etc die HTTP-Server-Einstellungen. Da werde ich basteln müssen, weiß aber noch nicht wie. Die stehen doch irgendwie in dieser doofen Confixx-Datenbank

Mailkonten nebst nicht abgeholter Mails

Benutzerrechte

Also nochmal: eine Vollsicherung bringt mir nicht wirklich etwas, zumindest darf ich sie nicht einfach wieder einspielen lassen, dann würde ich doch die neue Installation zerstören.

LG
Chris©

[Chris©]

Nochmal ich, hallo Ihr,

den TAR-Ball zu bauen, ist kein problem. Es ist auch noch genügend Platz auf der alten Kiste. Meine Frage ist aber nun noch folgende:

Wie stelle ich sicher, dass nach der Wiederherstellung der Tar-Balls auf einem frisch installierten neuen Server die User und Gruppen wieder vorhanden sind? Es reicht doch sicher nicht hin, im Tar-Ball die Rechte nur mitzusichern. Es müssen doch auch die Usernummern und die Gruppennummern wieder dazu passen. Wie mache ich das?

LG
Chris©

[Marc Reichelt]

Hallo Chris©,

den TAR-Ball zu bauen, ist kein problem. Es ist auch noch genügend Platz auf der alten Kiste. Meine Frage ist aber nun noch folgende:

Wie stelle ich sicher, dass nach der Wiederherstellung der Tar-Balls auf einem frisch installierten neuen Server die User und Gruppen wieder vorhanden sind? Es reicht doch sicher nicht hin, im Tar-Ball die Rechte nur mitzusichern. Es müssen doch auch die Usernummern und die Gruppennummern wieder dazu passen. Wie mache ich das?

Du sicherst den Ordner /etc mit.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Chris©]

Hallo Marc,

Du sicherst den Ordner /etc mit.

Ja, danke.

Soweit war ich inzwischen auch. Bleibt mir dann wahrscheinlich nichts anderes übrig, als die ganzen Eintellungen auf dem neuen Server alle wieder per Hand einzustellen. Die müssen doch wieder in die Confixx-Datenbank rein. Ich hasse dieses Confixx, aber es gehört bei diesem Provider nun mal zwingend dazu.

Blieben dann noch die Mailverzeichnisse und die Mailkonten...

LG
Chris©