Das Thema Backup sollte alle beschäftigen, die regelmäßig mit Computern arbeiten. Zu leicht treten Anwender-, Software- oder Hardwarefehler auf. Qualitativ hochwertige Hardware, RAID-Systeme und eine unterbrechungsfreie Stromversorgung können die Zuverlässigkeit der Hardware zwar erhöhen, schützen aber nicht vor Software- oder Anwenderfehlern, die sehr viel öfter die Ursache von Ausfällen sind.

Wichtig ist, zwischen den einzelnen Bereichen zu unterscheiden. Ein Backup sichert alle Daten zu einem festen Zeitpunkt (meist nachts). Idealerweise erfolgt die Sicherung in einem konsistenten Zustand auf ein externes Medium oder einen externen Server. Bei einer Synchronisation werden zwei TYPO3-Systeme regelmäßig miteinander abgeglichen. Sie sollte die Datenbank und die Dateien umfassen. Dabei ist allerdings selten eine Versionierung möglich. Wird ein Fehler nicht vor der automatischen Synchronisation bemerkt, wird er stillschweigend von der zweiten Instanz übernommen.

Eine Synchronisation ersetzt also kein Backup, bei dem mehrere Versionen der letzten Tage oder Wochen aufbewahrt wurden. Beim Backup findet in der Regel keine Archivierung statt: Um den Platzbedarf gering zu halten, wird es nach Tagen oder Wochen zyklisch überschrieben.

Bei allen Methoden ist es wichtig, zu testen, ob eine vollständige Wiederherstellung (Restore) einfach und zuverlässig möglich ist, denn, wie eingangs erwähnt, ist jedes Backup nur so gut wie der Restore. Ein zuverlässiges Backup kann mit Hilfe von Shellprogrammen einfach realisiert werden. Wer keinen Shell-Zugang besitzt, muss entweder auf Extensions zum Backup und zur Synchronisation zurückgreifen oder das Backup dem Hoster überlassen.

Eine Suche nach Extensions im TER mit den Begriffen „backup“, „import“, „export“ und „sync“ ergab mehr als ein Dutzend Treffer.

Die beiden Extensions „ed_lpesync“ und „df_t3sync“ sind nach Aussage ihrer Autoren veraltet, „wwsc_t3sync“ nach Auskunft des Entwicklers ohne vorhandene Dokumentation zu komplex. Die Extensions „backup“, „w4_backup“, „zor_backup“, „agprjmgm“ und „w4x_backup“ kamen auf dem Debian Sarge Testsystem nicht vollständig zum Laufen, zum Teil mit ähnlichen Problematiken. Stellvertretend wurde „w4x_backup“ auf vier unterschiedlichen Systemen erfolglos getestet, unter anderem auf zwei TYPO3-Standardinstallationen bei Hostern.

„treesync_base“ und „treesync“ wurden zusammengefasst, ebenso wie „dbsync“ und „doc_dbsync_fr“. Somit blieben die drei Extensions „ml_dbsync“, „treesyncc_base“ und „dbsync“ zum Test übrig. Getestet wurde mit der PHP-Version 4.3.10-20, MySQL-Version 4.0.24 und Apache-Version 2.0.54. Ein Grundproblem bei TYPO3/PHP-basierten Backup-Lösungen sind restriktive PHP-Einstellungen bei vielen Hostingpaketen. So ist zum Beispiel oft die „upload_max_filesize“ oder die „max_execution_time“ zu gering, um ein größeres Backup wieder vollständig einspielen zu können.

Mit Hilfe dieser Extension ist es möglich, aus Inhalten externer, TYPO3-fremder Datenbanken TYPO3-Seiten und -Seiteninhalte in der TYPO3-DB zu erzeugen. Im Backend wird die Extension im Modul Tools > DB Sync sichtbar.

Seiten, die aus der externen Datenbank erzeugt wurden, sind anhand eines speziellen Seiten-Icons sofort erkennbar. Wurden darauf zusätzlich neue Inhaltselemente per TYPO3 eingefügt, werden diese bei einer erneuten Synchronisation nicht überschrieben oder gelöscht. Verändert man allerdings später die von „ml_dbsync“ erzeugten Inhaltselemente per TYPO3, dann werden sie beim erneuten Synchronisieren wieder mit den externen DB-Werten überschrieben. Die Konfiguration zur Interpretation der externen Datenbankinhalte geschieht per XML, was für Ungeübte zwar gewöhnungsbedürftig, aber sehr flexibel ist.

Die Synchronisation ist nur von der externen Dantenbank auf die TYPO3-Datenbank und nicht umgekehrt möglich, auch werden keine Dateien abgeglichen. Ein Backup kann so zwar nicht ermöglicht werden, die Datenbank-Synchronisations-Möglichkeiten sind aber mächtig und sehr flexibel. Der Import der Daten aus externen Datenbanken ist nur dann möglich, wenn diese einen Zugriff über das Netzwerk erlauben und der Datenbankbenutzer für externe Hosts freigegeben ist. Dies sollte bei Sicherheitsbetrachtungen berücksichtigt werden.

Eine Automatisierung ist mit Hilfe der Extension „gabriel“ [1] möglich. Dazu wird „gabriel“ in definierten Intervallen per Cron-Job aufgerufen. Eine Anleitung zur Konfiguration der Extension ist mit „ml_tut_gabriel“ im TER zu finden [2].

Zum Test lag die noch nicht veröffentliche Version 0.10.0 vor, die mittlerweile im TER verfügbar ist. „ml_dbsync“ bietet zusätzlich die sinnvolle Möglichkeit, während der Synchronisation alle Benutzer zu deaktivieren. Einzig eine Dokumentation war nicht zu finden, Hilfestellung bieten der T3N-Artikel (10.000 Seiten in 15 Minuten, Heft Nr. 6) sowie der Autor selbst. Insgesamt erwies sich die Lösung – speziell zum Import TYPO3-fremder Datenbank-Inhalte – als flexibel und mächtig.

Diese Extensions ermöglichen die Synchronisation zwischen zwei identischen TYPO3-Instanzen, beispielsweise einem Entwicklungs- und einem Livesystem. Dazu wird auf beiden Systemen die Extension „treesync_base“ benötigt, auf dem Entwicklungssystem muss zusätzlich „treesync“ installiert werden. Es ist nicht nur ein FTP-Server auf dem Livesystem notwendig, sondern beide Systeme müssen von Anfang an als genaue Kopie vorliegen.

Nun steht der Synchronisation in beide Richtungen nichts mehr im Wege. Diese erfolgt im Backendmodul Tools > Rsync über ein Dropdown durch die Auswahl von Export oder Import. Per Klick können die zu synchronisierenden Tabellen ausgewählt werden, was auch eine Teilsynchronisation möglicht macht. Um die Dateien abgzugleichen, sind alle Unterordner in „uploads“ und „fileadmin“ auch einzeln auswählbar.

Die Auswahl von „skip database content“ startet den ausschließlichen Abgleich der Dateien, die Auswahl von „save content to file“ im Dropdown den Backup der Inhalte in eine Datei. Bei der Benennung der Datei wird das Datum und die Zeit verwendet, so kann mit diesen Extensions auch ein Backup realisiert werden. Bei erfolgreicher Synchronisation werden alle Datenbankoperationen im Backend geloggt. Welche Einstellungen bei der Extension vorgenommen werden müssen, ist in der Dokumentation erklärt, ein paar weitere Informationen zu FTP-Server und -Rechten wären allerdings hilfreich gewesen. Die Verschlüsselung des FTP-Verkehrs per TLS wird unterstützt.

Kurz: (Teil-)Synchronisation in beide Richtungen inklusive der Dateien in „uploads“ und „fileadmin“ – eine gelungene Sache.

Durch diese Extensions wird nicht nur der Import kompletter Datenbanken, sondern auch der Import einzelner Tabellen leicht möglich. Auch ein Import innerhalb derselben Datenbank, zum Beispiel ein Import von „fe_users“ in „be_users“, ist möglich. Einen Abgleich von Dateien bietet diese Extension nicht, der Abgleich der Datenbank ist nur in eine Richtung vorgesehen.

Nach Installation der Extension, die in Abhängigkeit zu „api_macmade“ steht, ist diese über das Backendmodul Tools > DB Sync erreichbar. Nun können entweder die Tabellen anderer Datenbanken zum Import ausgewählt oder interne Tabelleneinträge importiert werden. Dabei kann man sich zwischen den Optionen „Add records to local tables“ und „Empty local tables before synchronisation“ entscheiden.
Beim Import von internen Tabelleneinträgen können diese nicht nur auf bestimmte Datensätze beschränkt werden, auch die Seite, der die Datensätze zugeordnet werden, ist frei wählbar.

Im Fall des Imports von „fe_users“ in „be_users“ müssen die Quell- und Zielfelder einander zugeordnet werden. Die Extension bietet sinnvolle Voreinstellungen an, die Felder können ansonsten per Dropdown frei zugeordnet werden. Ein Haken bei „Do not include deleted records“ schließt gelöschte Datensätze aus. Die knappe Dokumentation ist ausreichend und durch „doc_dbsync_fr“ auch in französischer Sprache verfügbar.

Auch bei diesen Extensions ist der Import aus einer externen Datenbank nur möglich, wenn diese einen Zugriff über das Netzwerk erlaubt und der Datenbankbenutzer für externe Hosts freigegeben ist. Zusammengefasst: Kein Abgleich von Dateien, aber zum einen ein schneller Datenbank-(Komplett-)Import und zum anderen die Möglichkeit des Abgleichs zweier andersartiger interner Tabellen – ein gut durchdachtes System.

Wer keinen Shell-Zugang zur Verfügung hat, kann eine System-Extension oder Backups des Hosters nutzen. Ist ein Shell-Zugang vorhanden, können diverse externe Tools zum flexiblen eigenen Backup verwendet werden.

TYPO3 bringt durch die Systemextension „impexp“ schon von Haus aus die Möglichkeit zum Backup mit. Über das Klickmenu unter „More options…“ kann durch Auswahl von „Import from .t3d“ oder „Export to t3d“ der Im- oder Export bewerkstelligt werden. Hier können zwar ebenfalls keine Extensions abgeglichen werden, es existiert aber unter dem Reiter „Advanced Options“ die Möglichkeit zu vermerken, welche Extensions auf dem Zielsystem vorhanden sein müssen. Beim Import wird dann eine dementsprechende Meldung angezeigt.

Es ist möglich, (Teil-)Bäume zu exportieren und Dateien im Export mit einzuschließen. Jedes einzelne Inhaltselement oder jeder Link kann flexibel aus dem Export ausgeschlossen, Relationen können automatisch aufgelöst und mit exportiert oder als statische Verweise exportiert werden. Nach Betätigung des Update-Knopfs wird sofort durch rote Nachrichten erkennbar, ob und wo die Einstellungen zu Fehlern führen.

Mehrfach verwendete Exporteinstellungen können als Voreinstellung über einen eigenen Save- bzw. Load- Button gespeichert bzw. geladen werden. Diese Voreinstellungen können an Personen gebunden werden und stehen dann keinem anderen Backend-User zur Verfügung, selbst wenn es sich um einen Admin handelt.
Um die Exportdateien voneinander unterscheiden zu können, ist die Angabe von diversen Metainformationen möglich. Die Dateien können entweder in „fileadmin“ oder auf der lokalen Platte gesichert werden und erhalten, wenn keine eigenen Angaben gemacht werden, vom System einen Dateinamen der Form „T3D__19-07-10-27-09-z.t3d“. Ebenso können Dateien aus fileadmin oder der lokalen Platte importiert werden. Missverständlich ist allerdings, dass beim Import nach optionaler Definition der Einstellungen und Betätigung des Preview-Knopfs der Import- zum Update-Knopf wird und somit für Verwirrung sorgt.

Kurz: (Teil-)Export und Import, mächtige Einstellungsmöglichkeiten, Einschluss aller benötigten Dateien, aber nicht der Extensions, Backup durch das Speichern in eine Datei möglich – es bleiben kaum Wünsche übrig.

Falls das TYPO3-Paket bei einem TYPO3-Hoster gemietet wurde, ist ein Backup oft im Paketpreis enthalten. Einige Hoster haben uns Auskunft über ihre Backupstrategien gegeben. Alle erzeugen einen täglichen Dump der Datenbank ins Filesystem und führen dann ein Filesystembackup durch.

elios.de	4 Tage Fullbackup extern, auf Wunsch auch länger und redundant auf ein externes Rechenzentrum.
jweiland.net	7 Tage Fullbackup lokal, das Backupskript kann vom Benutzer erweitert werden. Zusätzlich 3 Tage Fullbackup extern, hier ist der Restore allerdings kostenpflichtig.
mittwald.de	10 Tage Fullbackup extern, Restore kostenpflichtig. Auf Wunsch Sicherung aller Daten in den Kunden-Webspace.
punkt.de	14 Tage inkrementelles Backup extern, auf Wunsch auch länger oder auf ein weiteres System.

Ist ein Zugang zur Shell des Webservers möglich, kann auf klassische Backupmethoden zurückgegriffen werden. In der Regel sollte hier ein Dump der (MySQL-)Datenbank im Filesystem abgelegt und anschließend ein Backup des Filesystems durchgeführt werden. Umfassende Informationen dazu sind zum Beispiel im neu aufgelegten Buch „Backup & Recovery“ von O’Reilly zu finden.

Um einen möglichst konsistenten Dump der Datenbank zu erzeugen, sollten die Tabellen während des Dumps nicht beschreibbar sein („–lock-all-tables“ für MyISAM-Tabellen bzw. „–single-transaction“ für InnoDB-Tabellen). Dies kann allerdings zu kurzzeitigen Timeouts bei schreibenden Datenbankzugriffen der TYPO3-Instanz(en) führen.

Statt eines Dumps können auch die MySQL-Datenbankdateien direkt gesichert werden. Auch hier muss sichergestellt werden, dass kein schreibender Zugriff erfolgt und alle Datenbankenindizes auf die Festplatte geschrieben wurden. Für MyISAM-Tabellen automatisiert das Perlskript „mysqlhotcopy“ alle notwendigen Schritte [3].

Das Backup der Dateien kann dann entweder mit klassischer Backup-Software (im Open-Source-Bereich z. B. „amanda“ oder „bacula“) oder aber als einfaches disk-to-disk-Backup mit „rsync“ auf eine zweite Platte oder einen Backupserver erfolgen. Ein sehr hilfreiches und einfach zu konfigurierendes Tool für rsync-basierte Backups inklusive Versionierung ist „dirvish“ [4]. Dieses Tool nutzt für seine Versionierung Hardlinks, sodass unveränderte Dateien nicht mehrfach gespeichert werden, obwohl für jeden Backupzeitpunkt ein vollständiges Abbild des Dateibaums vorhanden ist. Der Restore erfolgt einfach per „rsync“ oder „cp“.

Ist im Hostingpaket ein externer FTP-Backupbereich vorgesehen, können mit dem c’t-Tool „ftplicity“ [5] komfortabel Backups ermöglicht werden, die in handliche Dateien aufgeteilt und verschlüsselt auf dem FTP-Server abgelegt werden.

Alle Schritte des Backups werden automatisiert über Cron-Jobs ausgeführt und sollten regelmäßig auf ihre Vollständigkeit und Funktionsfähigkeit überprüft werden (z. B. durch ein Restore auf einem Testsystem).
Datenbank-Dumps können auch mit phpMyAdmin (z. B. in TYPO3 integriert) durchgeführt werden, hier sind jedoch die oben erwähnten PHP-Einschränkungen zu berücksichtigen.

Leider kann keine der Extensions ein vollständiges Backup der TYPO3-Installation (inklusive Extensions und Sources) bieten. Ebenfalls bringt keine Extension von Haus aus eine Automatisierung mit. Die externen Extensions decken eher Spezialfälle ab. Die Systemextension kann bei einmaligen Backups oder Synchronisationen hilfreiche Dienste leisten, besonders wenn Teilbäume exportiert werden sollen. Für ein zuverlässiges, vollständiges, automatisiertes Backup sind also entweder der Hoster oder eigene Shellskripte gefragt. Wird auf eine Archivierung Wert gelegt, kommt man um eine eigene Shell-Lösung nicht herum. Zukünftig könnte in Bezug auf Extensions über die integrierte Automatisierung (vielleicht sogar ohne Cron-Job) und das Verschicken einer Fehlermeldung per E-Mail nachgedacht werden.

Das Extension Comparison Team [6] hat sich die Aufgabe gestellt, die Auswahl von Extensions zu erleichtern und die Anwender bei der Suche nach der für sie am besten geeigneten Extension zu unterstützen. Der Aufruf im letzten T3N Magazin hat uns bereits weitere Mitstreiter eingebracht, aber wir würden gern noch einige Aktive für unsere Arbeit gewinnen, um langfristig nicht nur im Magazin, sondern eventuell auch an anderer Stelle systematische Extensionvergleiche zur Verfügung zu stellen. Wir freuen uns auch über Feedback, konkrete Anregungen und Kritik zu den bisherigen Artikeln. Bitte per E-Mail an: extcomp@googlemail.com