StaySafe Backup 1.3: universelles Backup-Tool für TYPO3 und WordPress-Projekte

staySave Backup für TYPO3 und WordPress Als Admin von verschiedenen TYPO3-Kunden-Installationen hat man es nicht immer einfach: Alle TYPO3-Projekte müssen gesichert werden – sowohl die Dateien als auch die Datenbank –, doch manche Seiten liegen auf verschiedenen Servern mit teilweise exotischen Konfigurationen: Die einen haben keine Shell, der andere wiederum eine externe Datenbank die nur von außen erreichbar ist. Klar, es gibt für alles individuelle Lösungen wie mysqldumper, shell-Befehle etc, aber wir wollten ein universelles Backup-Tool für TYPO3 und WordPress-Projekte das als Shell-Script läuft und verschiedenste Serverkonfigurationen abdecken kann. Voilà. Da ist es – staySafe Backup.

Was ist staySafe Backup?

staySafe Backup ist ein komplett in Bash geschriebenes Backup-Script für TYPO3 und WordPress-Projekte. Es kann über die Protokolle SFTP, SSH und FTP arbeiten. Auf dem zu sichernden Webservern müssten keine Tools oder Scripte installiert werden. Das Skript läuft auf allen UNIX-kompatiblen Betriebssystemen. Verschiedene Szenarien für Datenbank-Zugänge. Auf dem Backupserver werden an zentraler Stelle die Konfigurationsdateien für die Backup-Projekte abgelegt und automatisch abgearbeitet. Die aktuellen Datenbankzugänge holt sich staySafe Backup aus den jeweiligen CMS-Konfigurationsdateien (TYPO3: localconf.php, WordPress: wp-config.php).

Features

staySafe Backup hat folgende Features:
  • Zentrale Konfiguration des Backups für verschiedenste Servertypen
  • Kann automatisiert Dateien und Datenbanken von TYPO3 und WordPress sichern
  • Wenn sich Datenbank Zugänge (in der localconf.php oder der wp-config.php) ändern, merkt dies das Script
  • Inkrementelle BackupsBackup Rotation (täglich, wöchentlich, monatlich)
  • flexibel Schnittstelle zu den Servern (sftp/ssh/ftp)
  • Keine Software Abhängigkeiten seitens der Webserver. Das heißt auf dem Webserver muss keinerlei Backup-Software installiert sein
  • Ausschluss von Tabellen (ignore tables) möglich
  • Ausschluss von Dateien/Verzeichnissen möglich
  • Backup-Optionen: Datenbank+Dateien, nur Datenbank, nur Dateien
  • Testlauf/Integritätstest

Installation

Man muss staySafe Backup herunterladen und auf dem Backupserver entpacken. Dann in der Datei global_config die Rahmenbedinungen des Backup-Servers einstellen. Danach die Datei template duplizieren, umbenennen nach conf_projektname und das zu sichernde Projekt eintragen/konfigurieren. Jetzt könnte man bereits das erste Backup über den Befehl ./backup conf_projektname anstoßen.

Voraussetzungen

Voraussetzung ist ein Unix-basiertes System (Unix, Linux, Mac). Das Backup-Script benutzt FUSE (ist in der Regel vorhanden). Installiert werden müssen rdiff-backup und sshfs (sowie bei FTP-Clients auch curlftpfs).

Konfigurationen

Für jeden zu sichernden Webserver wird eine Konfigurationsdatei angelegt. In der Regel reichen die Angaben für
  • Projektname
  • SSH-User
  • Server
  • Pfad auf dem Server
  • Pfad zur localconf bzw. wp_config
Das Skript holt sich die benötigten Datenbankzugänge aus der localconf bzw. wp_config und ist so immer auf dem aktuellsten Stand.

Ignore Tables

Viele CMS beinhalten Tabellen die nicht gesichert werden müssen, z.B. Tabellen die nur für den Cache zuständig sind. Bei TYPO3 betrifft dies das Cachingframework und einige Tabellen für die Index-Suche. Sollte mal eine neue Tabelle dazukommen, muss dies nicht bei allen Konfigurationen geändert werden, sondern kann zentral in dem Ordner ignore_tables geschehen. Für TYPO3 wäre das dann die Datei ignore_typo3 im Ordner ignore_tabels.

File-Backup

Für das inkrementelle Sichern von Dateien wird rdiff-backup benutzt. Im Prinzip wird der Server lokal mit FUSE gemountet und tritt so wie ein lokaler Ordner in Erscheinung. Dieser wird dann von rdiff gesichert. Dadurch können im Prinzip auch andere Tool wie z.B. rsync benutzt werden. Dank rdiff (rdiff-backup.nongnu.org) sind ausführliche Statistiken zu jedem Dateibackup möglich. Die verschiedenen Snapshots sind in virtuelle Ordner unterteilt.

Datenbank Backup

Alle Datenbankbackups rotieren nach einem einstellbaren Prinzip. Die meisten Datenbanken sind nur über einen lokalen Port erreichbar. Das der Datenbankport von außen erreichbar ist ist eher die Ausnahme. Da möglichst viele Server abgedeckt werden sollen muss für beide Servertypen ein Möglichkeit gefunden werden. Es gibt zwei Möglichkeiten wie sich mit der Datenbank verbunden wird:
  1. SSH-Tunnel: Das heißt der Datenbankport des zu sichernden Servers wird bei dem Backupserver lokal erreichbar gemacht. Das Skript sucht einen freien Port ab 4000 und erstellt einen Tunnel. Das setzt voraus, das auf dem Server SSH verfügbar ist. Der Transport des Datenbankdumps erfolgt über diesen Tunnel und wird bereits auf dem Server komprimiert. Daher benötigt die Übertragung keine hohe Bandbreite und dank SSH ist die Verbindung verschlüsselt.
  2. Externe Verbindung: Ist die Datenbank von außen erreichbar wird sich einfach auf diesem Wege direkt verbunden.

Verwendung, Mitmachen, Weitermachen!

staySafe Backup ist ein Open-Source-Projekt von undkonsorten (Eike Starkmann). staySafe Backup ist auch einfach für andere Content-Management-Systeme wie Drupal, Joomla, oder Contao anpassbar. Macht mit! Wir freuen uns auf Feedback und Verbesserungen von Euch.

Updates

Version 1.3
  • Moodle Support
  • Backups können jetzt einzeln getestet werden
  • Statistiken werden jetzt wieder verschickt
  • Kleinere Bugfixes
Version 1.2
  • TYPO3 6.X Support
  • Best Practise im Wiki (Sammlung verschiedener Hoster)
  • Verbesserte Dokumentation
Version 1.1
  • Ein kleines Release, aber das Feature wollte ich euch nicht vorenthalten. Piwik wird jetzt unterstützt. Einfach ein neues Projekt anlegen, $CONFIG auf die piwik config.ini.php setzten und $CMS="piwik" setzen. Schon kann das gewünschte Piwik gesichert werden.
Version 1.0
  • Das Skript ist jetzt nach einem halben Jahr Beta stabil, so das wir die Version 1.0 freigeschaltet haben.
  • Einige Bugfixes sind hinzugekommen.
Version 0.9
  • Es ist jetzt möglich Test-Fälle für jedes Backup zu schreiben. Standardmäßig werden alle Datenbankdumps auf Größe, Datum und Inkonsistenz geprüft. Diese Parameter dafür können in der globalen Konfiguration eingestellt werden, oder in der jeweiligen Serverkonfiguration
Version 0.8
  • Detaillierte Statistiken können nun über stats für jedes Backups manuell aufgegeben werden.
  • Es kann ein Überblick über alle Server mit dem Befehl overview erstellt werden
  • Alte Backups werden jetzt gelöscht, die Parameter dafür sind in der globalen Konfiguration oder in der jeweiligen Serverkonfiguration einstellbar

Dokumentation

Dokumentation von staySave Backup für TYPO3 und WordPress @sourceforge. Die englische Dokumentation ist ausführlicher als die in Deutsch!

Download

https://sourceforge.net/p/staysave/

Kommentare

Hallo Micha,

nein das wird leider nicht passieren (es sei denn jemand beauftragt das ;-)), da wir das nicht benötigen.

Gruß, Eike

Super script, haben wir in ähnlicher weise auch so umgesetzt. Was mir noch fehlt (und der Grund für meine Suche im Netz war) ist eine grafische Oberfläche wie ininiteWP. (Leider nur Wordpress basierend.)

Gibts ne chance, dass du ein Web-interface dazu bastelst irgendwann?

Gruß

Micha

Ja, das müsste problemlos laufen, die Hardware Anforderungen sind minimal und Debian liefert alles mit was das Script benötigt.

Interessantes Projekt, halt mich mal auf dem laufenden!

Wäre es denkbar, mit dem Script und einem Raspberry Pi eine Art universelle Backup-Maschine zusammen zu basteln?

Auf dem Raspberry läuft in der Regel ein Debian Wheezy, optimiert für ARM-Prozessoren.

Danke.

Ich merke gerade in der Dokumentation steht es auch nicht drin.

Ich hab es hier so eingerichtet:

Alle drei Tage um 23 Uhr für alle Server:

0 23 3,6,9,12,15,18,21,24,27,30 * * root /pfad/zum/script/backup all

Alle drei Tage um 23 Uhr für eine bestimmten Server (dateien und datenbank):

0 23 3,6,9,12,15,18,21,24,27,30 * * root /pfad/zum/script/backup conf_server

Ich lasse die Backups als root laufen. Das ist aber kein muss.

Alle drei Tage um 23 Uhr für eine bestimmten Server (nur datenbank):

0 23 3,6,9,12,15,18,21,24,27,30 * * root /pfad/zum/script/backup conf_server database

Alle drei Tage um 23 Uhr für eine bestimmten Server (nur dateien):

0 23 3,6,9,12,15,18,21,24,27,30 * * root /pfad/zum/script/backup conf_server file

Ich lasse die Backups als root laufen, das ist aber kein muss.

Tolles Skript! Nur den Cron-Job kriege ich nicht ans Laufen - wie könnte der denn beispielhaft aussehen?

Nein, keine Meldung ist eine schlechte Meldung. Es müsste dir den Pfad es Programms "sshfs" zurückgeben werden. sshfs wohl nicht installiert.

Kann dies nicht per ipkg nachinstalliert werden, kommst du wahrscheinlich ums compilieren nicht herum.

Es sei dir aber gesagt, das sshfs nur für die Dateien auf dem zu sichernden Server benötigt werden. Du kannst aber die Datenbanken jetzt schon sichern.

Dazu muss in der jeweiligen Konfiguration BACKUP="database" gesetzt werden.

Es ist eine DS410. Hier vorgestellt:

http://geotagging-blog.de/2011/01/neue-nas-synology-diskstation-ds410-hardware/

Ich kann per SSH auf das darin laufende Linux zugreifen.

der which sshfs Befehl gibt nichts zurück. Gilt hier "Keine Meldung ist gute Meldung?"

Ob ich das selbst kompilieren mache müsste ich dann schauen. Jetzt mache ich erst mal Backup per wget.

Ich kenne mich selber nicht mit Synology NAS aus, noch weiß ich welches Produkt du genau verwendest, aber ich gehe mal davon aus das Linux auf der Kiste läuft und das man einen Shellzugang hat.

Zunächst muss du sicherstellen, dass sshfs auch installiert ist, z.B. mit "which sshfs". Wenn nicht, was ich mal vermute, musst Du entweder das Paket installieren, oder den Quellcode compilieren.

http://www.synology-forum.de/showthread.html?8632-Mount-%FCber-SSH-%28SSHFS-Fuse%29/page2&s=f433414ffdd93f518719cafa6247bf74

Dort ist die Vorgehensweise beschrieben.

Auf dem zu sichernden Server muss kein sshfs laufen nur ein Shellzugang: NAS (sshfs,backupscript)< ----> Server (ssh)

Klingt echt super. Jetzt muss ich nur wissen ob das auch auf einer Synology NAS läuft. Von dort soll das Backup nämlich laufen.

curlftpfs gibt es nicht für die NAS.

Wie kann ich testen ob sshfs richtig läuft? Um das live zu machen müsste ich in den nächst höheren Hostingtarif mit SSH wechseln.

Ok, hört sich erstmal ziemlich klasse an. Wir werden das gleich mal testen ! Vielen Dank dafür das ihr das als Open Source veröffentlicht.

Tolle Sache! Ich bin gespannt und freue mich auf da ausprobieren.

LG

Ede


Kommentar schreiben

* Diese Felder sind erforderlich