Hallo Tom,
Wie sichert man einen realen Webauftritt, der über Jahre gewachsen ist so, dass er bequem und gefahrlos von einem Linux-Host auf einen anderen umgezogen werden kann.
Insbesondere, wenn man ihn nicht selber aufgebaut und dokumentiert hat, wie geht man damit um?
Hier bereits der erste Punkt: Gefahrlos geht so etwas meistens nicht.
Genau daher sollte gründlich geplant und dokumentiert werden, um im Notfall alles parat zu haben.
Eine Downtime ist bei solchen Aktionen fast immer unvermeidlich. Daher sollte man die Downtime möglichst dann einplanen, wenn nicht mehr viele Nutzer auf den Server zugreifen (beispielsweise 2-6 Uhr morgens).
Ich empfehle folgendes:
1. Einige Wochen vor der geplanten Umstellung einen Testserver aufsetzen, der von der Hardware her genauso sein sollte wie der neue Server (das geht nie - aber zumindest die Rechnerarchitektur sollte übereinstimmen). Betriebssystem installieren (bspw. Debian Etch) und alle Komponenten des alten Servers (MySQL, Apache, SSH-Server, PHP, Mailserver, ...) via Paketsystem installieren. Mit dem Updater des neuen Systems die neuesten Sicherheitsupdates einspielen. Keine veralteten Versionen der Programme installieren, und nach Möglichkeit keine Fremdpakete - sonst macht einem der Server schneller Probleme als einem lieb ist. Alles GENAU DOKUMENTIEREN, sowohl Installation des Betriebssystems (Partitionierung etc.) als auch Installation der Pakete.
2. Nun werden Stück für Stück Informationen im alten System gesucht (Konfigurationsdateien, Dateien für's Web, Benutzer, Gruppen etc.) und auf den Testserver geschoben. Einen mysqldump aus dem laufenden Produktivsystem macht man am Besten via Konsole (--all-databases speichert alle Datenbanken, die Option --lock-all-tables sperrt die Tabellen). Mit "mysql [Optionen] < backup.sql" spielt man diesen dann in das Testsystem ein. Auch hier: Dokumentation!
3. Das neue Testsystem auf fehlende Komponenten prüfen und alles testen. Fehlendes nachinstallieren und falsche Konfigurationen abändern. Insbesondere hier gilt: Alles notieren.
4. Wenn sich das Testsystem nun so wie das alte System verhält: Glückwunsch! Der erste große Schritt ist getan. Eventuell noch mal von anderen testen lassen, um fehlende Dinge festzustellen.
5. Der große Zeitpunkt ist gekommen: Die Nacht der Umstellung. Alle Server-Programme (Apache, MySQL, Mailserver) werden heruntergefahren. Die Dateien des Servers sollten kopiert werden (rsync ist eine gute Hilfe dabei - die Option --one-file-system sollte definitiv verwenden werden).
Anschließend: Server herunterfahren, Live-System starten und aus diesem heraus die Festplatte(n) _komplett_ sichern (mit dd und mit Hilfe von gzip komprimiert). Man sollte dies vorher ein Mal auf einem nicht produktiven System üben, damit's hier klappt. Auch das Rückspielen des Festplatten-Images sollte bekannt sein.
6. Nun richtet man sich (mit dem Gewissen dass man die Backups gemacht hat und im Ernstfall das alte System wiederherstellen kann) den neuen Server ein - genau nach der Anleitung, wie man das Testsystem aufgesetzt hat.
Dies ist IMHO die beste Methode, um Server zu sichern.
Die meisten Probleme sollten beim Einrichten des Testservers entstehen. Hier hat man aber nicht den Stress eines produktiven Systems, sodass man die Probleme mit Zeit und vernünftigem Überlegen lösen kann.
Falls auf dem Produktivserver dann doch Probleme auftreten: Das kann immer passieren. Wenn die Probleme kritisch sind: Server ausschalten, Live-System starten und per dd und gzip die alte Sicherung zurückspielen.
Dies passiert aber i.d.R. selten, wenn man gut auf die bereits bekannten Probleme vorbereitet ist.
Grüße
Marc Reichelt || http://www.marcreichelt.de/
panic("Oh boy, that early out of memory?");
linux-2.2.16/arch/mips/mm/init.c
Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)