Pages Menu
TwitterRssFacebook
Categories Menu
Automatisches WordPress Backup richtig anlegen

Automatisches WordPress Backup richtig anlegen


Werbung

Heute möchte ich euch eine alternative Methode vorstellen um ein automatisches Backup eurer WordPress Installation zu erstellen. Hierfür werden keinerlei Plugins benötigt. Ihr benötigt allerdings SSH Zugriff auf eueren Webspace. Bislang hatte ich für das Backup meiner WordPress Netzwerkinstallation das Plugin BackWPup im Einsatz. Ich fand dieses Plugin sehr komfortabel, vor allem weil man hier einstellen konnte, wie viele Backups vorgehalten werden sollen?

Im laufe der Zeit, wurde mein WordPress-Ordner aber immer grösser und die Sicherungen damit auch. Mein kompletter Ordner, mit allen im WordPress-Netzwerk verwendeten Seiten, hat mitlerweile schon über 1,3 GB erreicht. Damit ging dann aber einher, das BackWPup nicht mehr vollständig ausgeführt wurde. Also musste ich mir was Anderes und vor allem, Sicheres einfallen lassen.

Richtiges WordPress Backup ist wichtig

WordPress Backup ist sehr sichtig. WordPress ist das meist verwendete CMS auf der Welt. Daher besteht natürlich auch eine Erhöhte Chance einem Hacker-Angriff zum Opfer zu fallen. Darum schnelle Vorsorge tätigen. Die meisten Backup-Plugin bieten keinen ausreichenden Schutz. Eine serverseitige Sicherung ist die erste Wahl.

Vollständiges Backup von WordPress per Cronjob

Ich habe daraufhin beschlossen, die Sicherung direkt vom Server per SSH durchführen zu lassen. Also ein tägliches Backup von WordPress per Cronjob, welches automatisiert die Datenbank sichert und im Anschluss den gesamten Ordner inklusive aller Dateien. Um das zu erreichen habe ich mir ein kleines Shell-Script gebastelt, das als erstes die MySQL Datenbank exportiert, im Anschluss den gesamten WordPress-Ordner auf dem Server als TAR-Archiv zusammengepackt und dann in einen separaten Backup-Ordner speichert.

Diese Methode ist dabei völlig unabhängig vom verwendeten CMS System. Ich habe diese Sicherung bereits bei einer Vielzahl von Drupal-Installationen erfolgreich eingesetzt.

Einziger Haken an dieser Methode ist allerdings, das man SSH Zugriff auf seinen Webaccount oder Webserver benötigt. Mein Blog ist derzeit auf einem größerem Shared Hosting Paket bei 1&1 gehostet. Dort funktioniert das Backup per SSH einwandfrei. Es sollte auch auf allen Linux Root oder Managed Servern funktionieren.

Backup Einrichtung Vorbereitung

Als erstes solltest du einen neuen Ordner in deinem Webaccount einrichten, wohin dann später das Backup gespeichert wird. Diesen Ordner solltest du oberhalb von deinem WordPress Ordner anlegen. Vorzugsweise im Hauptverzeichnis des Webaccounts oder wenn möglich außerhalb des Web-Verzeichnis.

Zur Sicherheit, solltes du hier zusätzlich eine htaccess-Datei erstellen, die den Zugriff des Webservers verbietet. Das ist aber nur erforderlich, wenn die Möglichkeit besteht, das ein Zugriff aus dem Internet auf dieses Verzeichnis erfolgen kann. Folgender Code muss in die .htaccess Datei eingetragen werden:

 

Server Pfad ermitteln

Als nächstes müssen wir den absoluten Verzeichnisspfad zu der WordPressinstallation ermitteln. Hierfür legen wir eine neue PHP Datei mit dem Namen „document_root.php“ an, in diese wir dann folgenden Code einfügen.

Diese Datei lädst du jetzt in den Hauptordner deiner WordPress-Installation und rufst diese dann mit folgendem Link in deinem Browser auf.

Jetzt wird dir auf dem Bildschirm der absolute Severpfad zur WordPress Installation angezeigt. Diesen solltest du dir jetzt kopieren und irgendwo zwischenspeichern oder aufschreiben, oder einfach nur das Browser-Fenster offen lassen. Wir brauchen den Pfad im Laufe dieser Anleitung noch.



Werbung

Server Script anlegen

Im nächsten Schritt erstellen wir jetzt das Backupskript. Dazu kannst du einen belibigen Texteditor nehmen und dort eine neue Datei mit dem Namen „backup.sh“ anlegen. Hier kommen jetzt folgende Linux Shell Befehle hinein. Die großgeschriebenen Worte musst du durch deine eigenen Daten ersetzen.

Als Erstes müssen wir in der ersten Zeile den Shell-Typ definieren. Dann schreiben wir in die nächste Zeile den Befehl für den Export der MySQL Datenbank. In der Befehlszeile musst du die Zugangsdaten für deine Datenbank angeben. Und du brauchst den vorhin ermittelten Server Pfad. Hier wird dann später die Exportdatei liegen.

Im zweiten Schritt müssen wir nun noch das gesamte Verzeichnis unserer WordPress Installation zu einem Datei-Archiv zusammenpacken. Hierfür verwenden wir den TAR Befehl von Linux. Mit diesem Befehl kann man unter Linux Dateien zu einem Archiv zusammenfassen und zusätzlich komprimieren. Ähnlich wie ZIP oder WINRAR unter Windows.

Im letzten Schritt musst du das Skript jetzt per FTP in den Backup-Ordner hochladen und anschließend einmal von Hand starten. Dazu logst du dich mit deinen SSH Zugangsdaten auf deinen Server ein und wechselst in das Backup-Verzeichnis. Jetzt musst du das Shell Skript manuell starten. Je nach Größe deines WordPress-Verzeichnis kann dieser Vorgang einige Zeit dauern. (Bei mir waren es fast 5min)

Wenn du alles richtig gemacht hast, solltest du jetzt 2 neue Dateien in deinem Backup Ordner finden, die .htaccess und die backup.sh .

Backup-Skript erweitern

Du kannst das Skript auch noch erweitern und verfeinern, in dem du mehrere Backups anlegst. Bislang ist es ja so, das das Backup täglich überschrieben wird. Um die Dateien nicht mehr täglich zu überschreiben musst du am besten das Datum an den Dateinamen des Backup-Files anhängen. Dann werden die Backupdateien nicht mehr überschrieben.

Jetzt tritt aber wieder ein neues Problem auf. Der Server müllt sich zu, denn es werden täglich neue Backupdateien in dem Verzeichnis gespeichert. Je nach dem wie groß dein  Wordpress mittlerweile ist, die das Backup schon ein paar Gigabyte umfassen.

Die Lösung des Problems ist hier das automatische Löschen von Backup-Dateien, die älter sind als 10 Tage. Hierfür kannst du die Linux Find-Anweisung nutzen. Bitte den nachfolgenden Befehl erst ohne  „-exec rm {} \;“ testen. Sonst könnte ausversehen mehr auf dem Server gelöscht werden als du eigentlich wolltest.

 

Im Folgenden findest du noch einmal das gesamte Backup-Skript um wirklich eine effektive Sicherung für dein WordPress einzurichten. Übrigens diese Methode geht auch für jegliches anderes Webprojekt wie Drupal, Joomla oder eigenen Projekten.

Die Nutzung des Skriptes erfolgt auf eigene Gefahr. Ich hafte nicht für Schäden. Bitte die Befehle vorher genau prüfen, ob die Funktion so gewünscht ist.

Cronjob anlegen

Zu guter Letzt müssen wir die eben angelegte Datei noch automatisiert über einen Cronjob ausführen lassen. Ich mache so etwas immer 1 mal in der Nacht, wo die Zugriffszahlen am geringsten sind und somit genug Rechenkapazität auf dem Server zur Verfügung steht. Bei mir ist das so gegen ca. 2:30 Uhr.

Um einen Neuen Cronjob anzulegen, rufen wir den Editor mit dem Befehl crontab -e auf. und tragen hier den Aufruf unseres Sicherungs-Skriptes ein. Wie man einen Cronjob anlegt, habe ich bereits in einem anderen Beitrag zum Thema Cronjob hier im Blog ausführlich erläutert.

Fazit

Wie ich hier gezeigt habe, ist es mit einfachen Bordmitteln relativ einfach möglich, eine vollständige Datensicherung für WordPress einzurichten. Dabei wird nicht nur die Datenbank gesichert, sondern auch der gesamte WordPress Ordner mit allen Dateien, Themes, Plugins und Bildern. Diese Datei lässt sich dann ganz bequem per FTP downloaden, so das man die Sicherung auf seinem heimischen PC speichern kann.

Diese Methode funktioniert auch bei sehr großen WordPress Installationen zuverlässig, weil man nicht von irgendwelchen Skript-Ausführzeiten abhängig ist. Ich würde mich darüber freuen, wenn Ihr eure Erfahrungen oder Anregungen zu dieser Anleitung im Kommentar postet.



Werbung

15 Kommentare

  1. Da hat wohl der Fehlerteufel zugeschlagen 😉 Sollte sicherlich „deny from all“ werden.

    Gruß Torsten

    • Danke für die Info. Ich habe es berichtigt.

  2. Hallo,
    ich habe alles wie beschrieben eingegeben, jedoch kommt bei der manuellen Ausführung des Scripts folgende Fehlermeldung:

    Befehl ‚“./backup.sh“‚
    fehlgeschlagen mit Beendigungscode 127 und Fehlernachricht
    -bash: line 24: ./backup.sh: No such file or directory.

    Was hab ich falsch gemacht?!

    • Ich denke, der Wurm steckt hier im Detail. Nochmal die Pfade überprüfen. Ist das eine 1und1 Server oder Shared-Hosting Account?

    • Ist ein Hosting Account von 1&1

    • Also bei mir funktioniert das. Bei einem meiner Hosting Accounts sieht der Pfad so aus. Das ist auch ein großes Paket mit SSH und Cronjob.

    • Habe ich alles genau so, auch das Paket mit SSH und Cronjobs. Funktioniert einfach nicht..

    • Es spielt eine Rolle wo das Script aufgerufen wird. Vielleicht einmal das Script direkt von der Root Ebene nach dem Login aufrufen. Ich ann mich noch erinnern, das ich auch mal so ein ähnliches Problem hatte. Als erstes einen der beiden Befehle in der Datei auskommentieren, damit man weiß, bei welchem Befehl das Problem besteht.

    • Welches SSH Programm nutzt du denn?

    • Ich mache das mit dem kostenlosen Terminal Programm Putty. Geht einwandfrei.

  3. Hallo Thomas,

    schön erklärt. Meiner Meinung nach fehlt aber noch die Erklärung wie man zurücksichert.

    Nebenbei bemerkt sollte aber jemand, der solche Rechte hat, sich auch damit auskennen 😉

    Gruß
    Matthias

    • Hallo Matthias,
      Ja du hast recht. Man sollte sich damit sicherlich auskennen oder das jemanden machen lassen, der sich damit auskennt. Wenn man z.B. einen 1&1 Account besitzt, der SSH zulässt, kann das problemlos machen. Wenn man damit Schaden anrichtet, dann nur in seinem eigenen Webaccount. Auf andere Bereich des Servers hat man keinen Zugriff.

      Und Danke für die Info, ich werden das Thema Rücksicherung entweder noch mit dranhängen oder demnächst noch einen Beitrag dazu verfassen. Hier schon mal die Kurzform:
      Man kann sich das gesamte Archiv per FTP runterladen und dann problemlos mit WIN-Rar auf seiner lokalen Festplatte entpacken. Hier findet man dann alle Dateien vor und kann diese dann, wenn benötigt auch einzeln, per FTP auf den Server zurück laden.

      Das macht sich vor allem dann gut, aus versehen einzelne Daten gelöscht oder überschrieben wurden.

  4. Ich empfehle nur jedem der ein Blog aufsetzt, die Sicherung und Rücksicherung zu testen wenn noch kaum Inhalt vorhanden ist. Sollte der Blog schon intensiv genutzt werden, dann eine neue leere Datenbank anlegen mit neuer WordPress-Installation (anderem Ordner) und es dort testen. Ob 1 Inhalt gesichert wird oder 1000 ist egal, der Ablauf ist der selbe.

    Viele wiegen sich in Sicherheit weil gesichert wird. Ich habe schon oft erlebt, dass Sicherungen unbrauchbar waren was aber erst dann auffällt wenn man sie braucht. Und dann ist es oft zu spät.

    WordPress ist Ordner und Datenbank, also Datenbankrücksicherung in Deinem Blog nicht vergessen.

    (Aktuell sichere ich jede Stunde indem ich die Stunde als Variable hinterlege und als Ziel abspeichere, so habe ich immer die letzten 24 Stunden zur Verfügung da meine Freundin gerade mit WordPress anfängt und gerne wieder ein Schritt zurück will.) Kann man natürlich auch mit Wochentag machen, Stichwort ‚date +%u‘

    • Ja, da hast du einen sehr gute Empfehlung gemacht. So mache ich das selber bei meinen Drupal Installationen. Man muss allerdings auf dem zur Verfügung stehenden Webspace aufpassen. Wenn der Webspace auf Grund der vielen Sicherungen voll ist wird selbst WordPress nicht mehr funktionieren und mit einer Fehlermeldung abbrechen. (z.B. wenn ein eingesetztes Cache Plugin nicht mehr auf die Platte schreiben kann oder bei einem Update von WordPress.) Als Beispiel habe ich noch einen Blog, der auf einem Shared Hosting Paket läuft. Der WordPress Ordner hat insgesamt fast 1GB Umfang. Der Webspace umfasst aber nur 5GB. Also ist rein rechnerisch bei 4 Sicherungen Schluss. Das sollte man auf jeden Fall vorher prüfen.

      Grundsätzlich hast du aber recht, mit mehreren Sicherungen. Wenn man sich damit nicht wirklich auskennt, sollte man auf jeden Fall einen IT-Dienstleister oder Admin zu Hilfe nehmen. Die Inhalte des Blogs oder der Webseite sind auch sehr wertvoll.

      Ich werde das Thema Datenrücksicherung und auch das Thema Mehrfachsicherung mit aufnehmen.

  5. Ok, dann ist das Paket für Deinen Beitrag ja komplett. 😉

    Das mit Begrenzung etc. kenne ich nicht, da ich selber root-server habe und alles darf 😉 Aber in Deinem Beitrag solltest Du natürlich von Anbietern ausgehen die Begrenzungen beim Platz und den Rechten haben.

Kommentar absenden

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

Pin It on Pinterest

Share This