Wie sichert man einen Webauftritt?

[Tom]

Hello,

heute möchte ich das Thema "Webhosting" mal von einer anderen Seite zur Diskussion stellen. Bisher ist es mir zwar nur dreimal irl über den Weg gelaufen, aber jedes Mal ist was schief gegangen.

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?

Bestandsaufnahme. Welche Komponenten könnten beteiligt sein?

• Webserver, Typ und Version
• Konfiguration des Webserverers
• wie wird die Konfiguration verwaltet? Dateien, Plesk, Confixx, eZAd, ...
• Module und Externals
• Konfiguration von zusätzlichen Modulen, VirtHosts
• Datenbanken, welcher Typ, welche Version?
    wo liegen die Daten? Welche Art der Speicherung (ISAM, MyISAM, ...)
    Können die Daten als tarball gesichert und wiederhergestellt werden
    oder benutzt die DB einen eigenen HDD-Treiber?
• PHP als Modul oder als CGI
• PHP auch als CLI?
• Sicherheitsstrategie von PHP
• Perl, wie eingerichet?

usw.

Mir sind nun schon zum zweiten Mal solche Dinge, wie Symbolic Links, Application-Types für bestimmte Files (das Bild ist in Wirklichkeit ein Script) usw. verloren gegangen.

Außerdem fehlen nach dem Umzug die Rechte, denn was nützt es, den tarball mit "preserving rights" zu bauen, wenn auf dem neuen System die User und Gruppen anders heißen oder zumindest andere Usernummern haben?

Das sind bestimmt nicht alle Fragen, darum stelle ich das Thema hier mal generell zur Diskussion. Ich würde gerne mit Eurer Hilfe erstmal alle Fragen sammeln, um dann zu versuchen, die Antworten zu finden.

Übrigens ist es nicht unerheblich, ob ich eine MySQL-DB in maximal drei Minuten Offtime in ein anderes Verzeichnis kopiere, um sie dort seelenruhig in ein Tarball (auch zum Download) zu verpacken, oder ob ich sie dumpen lasse und das ggf. noch während des aktiven Betriebes. Bis zu welcher Version das möglich war? Weiß ich nicht wirklich!
Welche Stategien es hier gibt und welche "richtig" sind, würde ich gerne herausfinden.

Ich gehe davon aus, dass "normale" auch größere Webauftritte nicht auf SFT3-Systemen oder ähnlichen laufen und man sich sehr wohl Gedanken über die Sicherung machen muss.

Ein harzliches Glückauf

Tom vom Berg

http://bergpost.annerschbarrich.de
.

[Tom]

Hello,

*ui*
Keiner einer da, der sich so eine Frage auch schon mal gestellt hätte?

Ein harzliches Glückauf

Tom vom Berg

http://bergpost.annerschbarrich.de
.

[Marc Reichelt]

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/

[Tom]

Hello Marc,

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).

Spätestens hier spricht mein Zeitempfinden: Es dauert zu lange.

Es geht bei der Frage ja auch um regelmäßige Backups, um im Zweifelsfall dann sofort ein neues System aufziehen zu können. Da kann man nicht mehrere Stunden den Server runterfahren.
Ob incrementelle Backups so ungeheuer sicher sind bei MySQL ist mir suspekt.

3. Das neue Testsystem auf fehlende Komponenten prüfen und alles testen. Fehlendes nachinstallieren und falsche Konfigurationen abändern. Insbesondere hier gilt: Alles notieren.

Ok, das kann man regelmäßig tun, um gewappnet zu sein.

Die anderen von Dir genannten Punkte nehme ich mal in die Sammlung auf (stehen ja auch hier im Thread).

Mir macht zur Zeit am meisten Kopfzerbrechen, wie man regelmäßig für ein möglichst genaues Abbild sorgen kann, um für den unvorherbestimmbaren Zeitpunkt möglichst nah dran zu sein.

Die Minimierung der Downtime ist mir dabei wichtig.

Incrementelle Methoden erfordern meistens aufwändige und teure Software; wie geht es möglichst mit Bordmitteln und Überlegung (fast) genauso gut?

Dass Shellscripte oder Perlscripte notwendig werden, ist mir inzwischen schon so ziemlich klar geworden...

Ein harzliches Glückauf

Tom vom Berg

http://bergpost.annerschbarrich.de
.

[Sven Rautenberg]

Moin!

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).

Spätestens hier spricht mein Zeitempfinden: Es dauert zu lange.

Es geht bei der Frage ja auch um regelmäßige Backups, um im Zweifelsfall dann sofort ein neues System aufziehen zu können. Da kann man nicht mehrere Stunden den Server runterfahren.

Für Backups ist der Provider zuständig. Bei Webhosting-Standardangeboten sowieso.

Und dass es dir nicht um Ausfallsicherheit gehen kann, macht deine Fragestellung bzw. dein Einwand ja schon deutlich. Es dürfte irrelevant sein, ob ein Webangebot aufgrund seines Servers einen Tag oder eine Woche down ist. Weniger Zeit wirst du zur Herstellung eines Ersatzservers wohl nicht hinkriegen.

Außerdem ist es für die Beantwortung der Frage hinderlich, Szenarien zu mischen. Also bitte entscheide dich, was du willst: Einem bestehenden Webangebot einen neuen Server unterschieben, oder Backups, oder Sicherheit gegen Ausfälle?

Mir macht zur Zeit am meisten Kopfzerbrechen, wie man regelmäßig für ein möglichst genaues Abbild sorgen kann, um für den unvorherbestimmbaren Zeitpunkt möglichst nah dran zu sein.

Kann man nicht.

Die Minimierung der Downtime ist mir dabei wichtig.

Hot-Standby-Lösungen existieren - für das entsprechende Kleingeld.

Incrementelle Methoden erfordern meistens aufwändige und teure Software; wie geht es möglichst mit Bordmitteln und Überlegung (fast) genauso gut?

Es geht nicht. Dein Szenario ist aufwendig und komplex, und kann nie mit einer Standardlösung erschlagen werden, sondern erfordert individuelle Maßnahmen.

- Sven Rautenberg

[Tom]

Hello,

Außerdem ist es für die Beantwortung der Frage hinderlich, Szenarien zu mischen. Also bitte entscheide dich, was du willst: Einem bestehenden Webangebot einen neuen Server unterschieben, oder Backups, oder Sicherheit gegen Ausfälle?

Ok, das ist doch schon mal ein Ansatzpunkt.

Also gibt es zwei Szenarien:

• Der Host kann in Originalform wieder hergestellt werden oder ist gar nicht
    ganzheitlich betroffen, es sind "nur" Fehler im Webauftritt (z.B. Datenbank geschreddert)
    aufgetreten

• Der Host ist explodiert und hat selbstverständlich die Originaldaten des Web mit ins
    Nirwana gerissen. Der Provider (oder eben man selbst) muss nun neinen neuen Host
    aufbauen, der dem alten möglichst gleicht.

-- Allerdings wird man hier
---- Neue OS-Version haben wollen
---- neue Datenbankversion haben wollen
---- neue Scripting-Bases für PHP, Perl, usw. haben wollen
---- ...

Dabei wird die Neuinstallation z.B. schon für die Basisdienste andere Usernummern
   vergeben, wenn man nicht ganz genau hinschaut.

• Drittes Szenario: man will das Web einfach nur umziehen und hat Zeit dafür.

Was muss man also auf jeden Fall sichern?

• Stumpf das ganze etc-Verzeichnis?

• Datenbank: kann man bei MySQL 5.0 noch die Tabellen übertragen?
        Ich habe das bisher nicht hinbekommen, allerdings auch noch
        nicht genug Ausdauer gezeigt, um herauszufinden, wo der Fehler lag

• Virt-Host-Konfigurationen

• PHP- und Perl-Basiskonfigurationen

• PHP- und Perl-Spezialkonfigurationen

• ???

• Die Webverzeichnisse

• Logverzeichnisse? Welche könnten wichtig sein?

• Benutzer-Datenbanken/Dateien

Was fehlt?

Die Minimierung der Downtime ist mir dabei wichtig.

Hot-Standby-Lösungen existieren - für das entsprechende Kleingeld.

Das war mein Denkansatz. Linux hat soviel Möglichkeiten, dass es doch eigentlich auch für Kleingeld gehen müsste.

Ein harzliches Glückauf

Tom vom Berg

http://bergpost.annerschbarrich.de
}

[Vinzenz Mai]

Hallo Tom,

Also gibt es zwei Szenarien:

• Der Host kann in Originalform wieder hergestellt werden

was meinst Du damit?

oder ist gar nicht
  ganzheitlich betroffen, es sind "nur" Fehler im Webauftritt (z.B. Datenbank geschreddert)
  aufgetreten

das ist doch "einfach": Backup der Datenbank einspielen.

• Der Host ist explodiert und hat selbstverständlich die Originaldaten des Web mit ins
    Nirwana gerissen. Der Provider (oder eben man selbst) muss nun neinen neuen Host
    aufbauen, der dem alten möglichst gleicht.

-- Allerdings wird man hier
---- Neue OS-Version haben wollen

die irgendwelche undokumentierten Aufrufe externer Anwendungen bricht.

---- neue Datenbankversion haben wollen

die alten Code, der undokumentiert über viele Skripte verteilt ist, bricht.

---- neue Scripting-Bases für PHP, Perl, usw. haben wollen

die alten Code, der undokumentiert über viele Verzeichnisse verteilt ist, brechen ...

Dabei wird die Neuinstallation z.B. schon für die Basisdienste andere Usernummern
   vergeben, wenn man nicht ganz genau hinschaut.

Ja, und? Das ist bestimmt das geringere aller Probleme.

• Drittes Szenario: man will das Web einfach nur umziehen und hat Zeit dafür.

Da ist kein Unterschied zu Fall 2, außer dass man in aller Ruhe durchtesten kann :-) Und wenn Du Szenario 2 nicht z.B. wie von Marc beschrieben durchgespielt - und dokumentiert - hast, dann wirst Du auf die Nase fallen.

Grundsätzlich gehe ich davon aus, dass Du in Deinen Szenarien voraussetzt, dass Du root-Zugriff hast.

Freundliche Grüße

Vinzenz

[Tom]

Hello Vinzenz,

das ist doch "einfach": Backup der Datenbank einspielen.

Danke für den Link. habe ich gleich was zu lesen :-)

Grundsätzlich gehe ich davon aus, dass Du in Deinen Szenarien voraussetzt, dass Du root-Zugriff hast.

Ja, als Ersteller der bnötigten Backup-Scripte schon.
Die laufen nachher unter dem Owner des Erstellers.
Der Verwender soll später nur auf einen (geschützen) Link klicken (oder der Cron macht das für ihn), sich dann ca. drei bis vier Minuten später seinen Tar-Ball runterladen können, was ruhig eine Stunde dauern darf.

Der muss aber auch wieder uploadbar sein im Notfall, wenn er denn in der Sicherungshistorie des Providers auch nicht mehr da ist. Und dann muss der nach noch festzulegenden Regeln wieder einspielbar sein, notfalls auch auf einem neuen Hostsystem.

Ein harzliches Glückauf

Tom vom Berg

http://bergpost.annerschbarrich.de
.