Die Horrorvorstellung eines jeden Homepage-Betreibers: Beim Provider kommt es durch technische Fehler und Pannen zum totalen Datenverlust.
Wer in dem Fall ohne eigene Datensicherung dasteht, der ist ganz schön angeschmiert. Bei einer privaten Homepage ist das "nur" ärgerlich, wenn mit der Seite aber Geld verdient wird, drohen mitunter erhebliche finanzielle Verluste. Darum sollte man sich nie ganz auf seinen Provider verlassen, sondern auch eigene Backups erstellen.
Bei einer Webseite, die nur aus HTML-Dateien oder einfachen PHP- und/oder CGI-Scripten besteht, geht das sehr leicht - man muss sich einfach nur das gesamte Verzeichnis per FTP herunterladen. In der Regel hat man diese Daten ja ohnehin auf der eigenen Festplatte, weil man sie selbst erstellt hat.
Aber auch SQL-Datenbanken lassen sich mit vertretbarem Aufwand sichern. Am komfortabelsten funktioniert es mit einem Telnet-, oder SSH-Zugang, dieser ist jedoch in den wenigsten Webspace-Paketen enthalten. Und phpMyAdmin, ansonsten ein unverzichtbares Werkzeug, ist zur Sicherung größerer Datenbanken nicht geeignet.
Darum gebe ich Euch hier 2 Scripte weiter, mit denen sich ganz leicht ein Datenbank-Backup erstellen und auch wieder zurückspielen lässt. Die Scripte sind nicht von mir, ich möchte mich da nicht mit fremden Federn schmücken. Voraussetzung für die Nutzung sind ein Unix- oder Linux-Server mit GZIP-Unterstützung (das dürfte bei 99,9% der Hoster zutreffen). Die Funktionen exec() und mySQL-Dump müssen ebenfalls vom Provider aktiviert sein. Ob das zutrifft, kann der Support des Providers in der Regel beantworten.
Und so funktioniert das Ganze:
Zuerst wird auf dem Webserver ein Verzeichnis angelegt, in dem die Scripte abgelegt werden. Damit niemand unbefugt darauf zugreifen kann, sollte es z.B. mit htaccess geschützt werden (wie das geht, ist hier sehr gut beschrieben).
Damit die Scripte später funktionieren, müssen die Rechte für das Verzeichnis mit dem chmod-Befehl auf 777 gesetzt werden. Nahezu jeder FTP-Client kann das, nur ist der Befehl unterschiedlich gut versteckt
- meist hilft ein Rechtsklick auf das Verzeichnis.
Nun die angehängte ZIP-Datei entpacken und die Dateien bearbeiten. Wie das geht, ist in den Kommentarzeilen der Scripte recht gut beschrieben, daher an dieser Stelle nur zwei Hinweise:
Bei "$pfad:" wird der absolute lokale Pfad auf dem Server eingetragen (ohne "/" am Ende, ganz wichtig!) - wenn dieser nicht bekannt sein sollte, die Datei root.php3 in das eben erstellte Verzeichnis laden und im Browser aufrufen - sie liefert als Ausgabe den korrekten Pfad zurück. (Wenn der Pfad bekannt ist, wird die root.php3 nicht gebraucht).
Bei "$download_url:" wird die normale Web-Url des vorher angelegten Verzeichnisses (mit "/" am Ende, ebenfalls wichtig!) angegeben, unter der das Script liegt.
Nun werden die Dateien db_backup.php3, db_restore.php3 und error.txt in das neu erstelle Verzeichnis hochgeladen. Die Rechte der error.txt müssen ebenfalls per chmod auf 777 gesetzt werden.
Um die Datenbank zu sichern, muss jetzt nur noch die db_backup.php3 im Browser aufgerufen werden.
Um ein Backup wieder einzuspielen, muss die vorhandene Datei in "backup.sql.gz" umbenannt und anschliessend die db_restore.php3 im Browser aufgerufen werden. Sollte die Endung .php3 bei Deinem Provider nicht unterstützt werden, können die Scripte gefahrlos in .php umbenannt werden.
Die Scripte sind sehr einfach gestrickt und geben fast immer eine Erfolgsmeldung aus, auch im Fehlerfall. Typische Fehler sind:
Backup oder Restore laufen in Sekundenschnelle durch, ohne daß ein Ergebnis produziert wird.
In diesem Fall nochmal die chmod-Rechte prüfen - in 99% der Fälle liegt es daran. Wenn es das ganz sicher nicht ist, kommt noch ein falscher bzw. fehlender Pfad zur mysql-Programmdatei in Frage. Dieser muss dann vollqualifiziert in der Variable "$programm" eingetragen werden. Auskunft darüber kann wiederum nur der Support des Providers geben.
Das Backup ist unvollständig oder das Restore bricht mittendrin ab
Bei großen Datenbanken kann es zu einem Timeout kommen - die Provider stellen die Werte dafür mitunter sehr restriktiv ein. Außer beim Provider betteln kann man da nichts tun, und die Aussichten auf Erfolg sind gering. Zumindest beim Restore kann der Support aber helfen - was er sich jedoch meist bezahlen lässt.
Desweiteren finden sich etwaige Fehlermeldungen in der Datei error.txt oder in den Logfiles des Webservers - die meisten Provider gewähren ja inzwischen Zugriff darauf.
Und wenn gar nichts mehr geht, dann sind wir ja auch noch da - also einfach fragen
Wer in dem Fall ohne eigene Datensicherung dasteht, der ist ganz schön angeschmiert. Bei einer privaten Homepage ist das "nur" ärgerlich, wenn mit der Seite aber Geld verdient wird, drohen mitunter erhebliche finanzielle Verluste. Darum sollte man sich nie ganz auf seinen Provider verlassen, sondern auch eigene Backups erstellen.
Bei einer Webseite, die nur aus HTML-Dateien oder einfachen PHP- und/oder CGI-Scripten besteht, geht das sehr leicht - man muss sich einfach nur das gesamte Verzeichnis per FTP herunterladen. In der Regel hat man diese Daten ja ohnehin auf der eigenen Festplatte, weil man sie selbst erstellt hat.
Aber auch SQL-Datenbanken lassen sich mit vertretbarem Aufwand sichern. Am komfortabelsten funktioniert es mit einem Telnet-, oder SSH-Zugang, dieser ist jedoch in den wenigsten Webspace-Paketen enthalten. Und phpMyAdmin, ansonsten ein unverzichtbares Werkzeug, ist zur Sicherung größerer Datenbanken nicht geeignet.
Darum gebe ich Euch hier 2 Scripte weiter, mit denen sich ganz leicht ein Datenbank-Backup erstellen und auch wieder zurückspielen lässt. Die Scripte sind nicht von mir, ich möchte mich da nicht mit fremden Federn schmücken. Voraussetzung für die Nutzung sind ein Unix- oder Linux-Server mit GZIP-Unterstützung (das dürfte bei 99,9% der Hoster zutreffen). Die Funktionen exec() und mySQL-Dump müssen ebenfalls vom Provider aktiviert sein. Ob das zutrifft, kann der Support des Providers in der Regel beantworten.
Und so funktioniert das Ganze:
Zuerst wird auf dem Webserver ein Verzeichnis angelegt, in dem die Scripte abgelegt werden. Damit niemand unbefugt darauf zugreifen kann, sollte es z.B. mit htaccess geschützt werden (wie das geht, ist hier sehr gut beschrieben).
Damit die Scripte später funktionieren, müssen die Rechte für das Verzeichnis mit dem chmod-Befehl auf 777 gesetzt werden. Nahezu jeder FTP-Client kann das, nur ist der Befehl unterschiedlich gut versteckt
- meist hilft ein Rechtsklick auf das Verzeichnis. Nun die angehängte ZIP-Datei entpacken und die Dateien bearbeiten. Wie das geht, ist in den Kommentarzeilen der Scripte recht gut beschrieben, daher an dieser Stelle nur zwei Hinweise:
Bei "$pfad:" wird der absolute lokale Pfad auf dem Server eingetragen (ohne "/" am Ende, ganz wichtig!) - wenn dieser nicht bekannt sein sollte, die Datei root.php3 in das eben erstellte Verzeichnis laden und im Browser aufrufen - sie liefert als Ausgabe den korrekten Pfad zurück. (Wenn der Pfad bekannt ist, wird die root.php3 nicht gebraucht).
Bei "$download_url:" wird die normale Web-Url des vorher angelegten Verzeichnisses (mit "/" am Ende, ebenfalls wichtig!) angegeben, unter der das Script liegt.
Nun werden die Dateien db_backup.php3, db_restore.php3 und error.txt in das neu erstelle Verzeichnis hochgeladen. Die Rechte der error.txt müssen ebenfalls per chmod auf 777 gesetzt werden.
Um die Datenbank zu sichern, muss jetzt nur noch die db_backup.php3 im Browser aufgerufen werden.
Um ein Backup wieder einzuspielen, muss die vorhandene Datei in "backup.sql.gz" umbenannt und anschliessend die db_restore.php3 im Browser aufgerufen werden. Sollte die Endung .php3 bei Deinem Provider nicht unterstützt werden, können die Scripte gefahrlos in .php umbenannt werden.
Die Scripte sind sehr einfach gestrickt und geben fast immer eine Erfolgsmeldung aus, auch im Fehlerfall
. Typische Fehler sind:Backup oder Restore laufen in Sekundenschnelle durch, ohne daß ein Ergebnis produziert wird.
In diesem Fall nochmal die chmod-Rechte prüfen - in 99% der Fälle liegt es daran. Wenn es das ganz sicher nicht ist, kommt noch ein falscher bzw. fehlender Pfad zur mysql-Programmdatei in Frage. Dieser muss dann vollqualifiziert in der Variable "$programm" eingetragen werden. Auskunft darüber kann wiederum nur der Support des Providers geben.
Das Backup ist unvollständig oder das Restore bricht mittendrin ab
Bei großen Datenbanken kann es zu einem Timeout kommen - die Provider stellen die Werte dafür mitunter sehr restriktiv ein. Außer beim Provider betteln kann man da nichts tun, und die Aussichten auf Erfolg sind gering. Zumindest beim Restore kann der Support aber helfen - was er sich jedoch meist bezahlen lässt.
Desweiteren finden sich etwaige Fehlermeldungen in der Datei error.txt oder in den Logfiles des Webservers - die meisten Provider gewähren ja inzwischen Zugriff darauf.
Und wenn gar nichts mehr geht, dann sind wir ja auch noch da - also einfach fragen
