Den eigenen Webauftritt sichern

Es soll den ein oder anderen geben, der seine Daten zwischendurch auf externe Medien wie Festplatte oder DVD sichert. Hierfür gibt es unzählige kostenpflichtige oder auch kostenlose Tools, manchmal reicht auch ein kleines Script um eine Sicherung seiner Daten anzulegen. Nur wie oft wird die eigene Internetseite gesichert? Natürlich kann man sich auf die backups seines Hostingproviders verlassen, nur kommt man da notfalls schnell ran und vor allem auch kostenlos? Für wordpress, contao etc gibt es Plugins die den Auftritt sichern, ich habe mir jedoch ein eigenes kleines Script geschrieben.

Die folgenden Variablen müssen hierfür befüllt werden:

# ftp Zugangsdaten
USERNAME=<username> //willi
PASSWORD=<passwort> //sogeheim
SERVER=<server> //www.meineseite.de
# aufruf der per htaccess php Datei
USER=<user>  // lieschen
PASSWORD2=<passwort> // auchgeheim
URL=<url zum Aufruf ohne dump.php Angabe> // www.meineseite.de/geheim
DATEIPFAD=<Pfad zur dump.php per ftp> // geheim

Hier werden die lokalen Backups abgelegt.

TARGET=/backup/${SERVER}/${DATE}

Als erstes wird der unter TARGET angegebene Ordner erstellt, im Anschluss werden alle Dateien per FTP heruntergeladen. Um Platz zu sparen werden die heruntergeladenen Dateien gepackt.
Damit ein mysqldump erstellt werden kann, muss die Datei dump.php auf der Internetseite hinterlegt werden. (Die dump.php muss per htaccess geschützt werden.) In dem Script wird die Datei über lynx aufgerufen, nach dem Aufruf wird der sqldump per ncftpget heruntergeladen. Der Abruf per ncftpget ist so gesetzt, das der sqldump nach erfolgreichem download gelöscht wird.

In der dump.php sind die Zugangsdaten für die Mysql Datenbank hinterlegt. Wenn mehrere Datenbanken unter dem Webhostingpaket verwendet werden, kann der php Code zum erstellen des Dumps auch öfters angegeben werden.

Download:Script

8 Gedanken zu „Den eigenen Webauftritt sichern

  1. dakira

    Ich würde für sowas ja eher einen Cronjob anlegen, der das per ssh/rsync auf einen anderen Rechner sichert. Vorher mit mysqldump ein paar backups ziehen.

    Warum? FTP ist unsicher (Passwörter im Klartext). Passwörter in irgendwelchen Skripten ablegen ist auch blöd. Das ganze sollte passwortlos über Zertifikate laufen. Und die MySQL-Zugangsdaten (root) legen Debians in /etc/mysql/debian.cnf ab. Das dump machst du dann mit

    mysqldump –defaults-extra-file=/etc/mysql/debian.cnf –skip-extended-insert –skip-comments db_name > db_name.sql

    Das geht super skriptgesteuert.

    Antworten
    1. Stefano

      Ich würde noch weiter gehen:
      Nicht der Hosting-Server schiebt sein Backup dorthin, sondern der Backupserver zieht sich das Backup vom Hostingserver. Dadurch gibt es vom Hostingserver keinen direkten Zugriff auf den Backupserver. Das hilft falls der Hostingserver kompromittieren werden würde. Bei deiner Variante könnte das Backup dann gleich mit kompromittieren werden.
      Man kann das natürlich auch anders rum drehen und sagen das wenn der Backupserver kompromittiert wird auch der Hostingserver in Gefahr schwebt. Ich glaube aber das für einen Hacker ein Hostingserver interessanter als ein Backupserver ist.

      Antworten
      1. hermann Beitragsautor

        Es war so angedacht der der Backupserver alle Dateien etc vom Hosting Server zieht. Natürlich wenn der Hosting Server kompromittiert ist, würde das mit ins Backup einlaufen. Das Problem hat man jedoch immer wenn ein Backup erstellt wird und das Ziel kompromittiert wurde.

        Antworten
  2. FreakErn

    Hallo Hermann,

    nun, für einen kleinen Blog wird das bestimmt gehen…

    Passwörter in Variablen zu speichern finde ich auf einem Lokalem System, je nach Information und Sensibilität, bedenklich! Ich würde eine Datei anlegen als Benutzer root und der die rechte chmod 600 geben. Diese kannst du dann per expect und im root-cron an ein Skript übergeben. Expect ist nicht wirklich schön, aber sehr funktional!

    Wenn jemand ein Bild mit in der Tabelle speichert oder mal seeeehr viele Datensätze hat, warum auch immer… läuft dir vom PHP der speicher voll (wenn erlaubt, dann ini_set mit „memory_limit“ und dann höher setzen, oder Zeile für Zeile schreiben (sehr hohe IO, bei einem vServer aber wohl nicht ganz so schlimm))

    Darüberhinaus kannst du das MySQL Backup nicht einspielen ohne die Tabelle vorher zu löschen oder sie zu leeren (Wenn du mal die bestehenden Daten überschrieben willst). Entweder die Tabelle ist schon vorhanden („CREATE TABLE“ schlägt fehl) oder du hast alle Datensätze doppelt (Wenn der PrimaryKey dir nicht nen strich durch die Rechnung macht). Wenn bei dem „CREATE TABLE“ ein „IF NOT EXISTS“ mit beisteht dann könntest du auch ein „REPLACE“ statt einem „INSERT“ nehmen, wobei man da auf Trigger aufpassen muss, je nachdem was die tun, weil ein „REPLACE“ ein „DELETE“ und danach ein „INSERT“ macht.

    Wenn du beim „INSERT“ bleibst, hast du, je nach Größe, dann ggf. noch das Problem das du an das Limit kommst das pro „INSERT“ erlaubt ist (glaube dieses Problem gibt es bei „REPLACE“ nicht, bin mir aber nicht ganz sicher).
    Vielleicht könnte in deiner PHP Schleife ein modulo gemacht werden auf anzahl x und das du danach dann ein neues Statement anfängst, was dir beim PHP-Speicher Problem ebenfalls helfen könnte.


    if($var % 500){
    // schreibe zeile in datei
    // fang neue zeile an
    // [ vielleicht noch ein sleep(1) ins sql einbauen, damit anfragen auf myisam sich nicht zu sehr aufstauen ]
    }
    </code)

    Antworten
    1. hermann Beitragsautor

      bei den Rechten stimme ich dir zu, das nur der root Benutzer es per Cron ausführen sollte.
      Das Script für den Dump sehe ich mir noch einmal an und werde es dann überarbeiten

      Antworten

Schreibe einen Kommentar zu Stefano Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert