Was erwartet dich in diesem Beitrag?
- Wir erklären dir, welche Dateien für ein Contao-Backup überhaupt relevant sind.
- Du erfährst, was du unbedingt vor einem Bugfix-Update sichern solltest?
- Wir geben dir Tipps, wie du ein Backup durchführen und automatisieren kannst.
Inhaltsverzeichnis
Was gehört in ein vollständiges Contao-Backup?
Grundsätzlich besteht eine Sicherung aus bestimmten Verzeichnissen, Dateien und einem Export der Datenbank.
Damit du besser nachvollziehen kannst, welche Dateien und Verzeichnisse du sichern solltest, erklären wir dir zunächst die Verzeichnisstruktur einer typischen Contao-Installation.
(siehe auch: Developer Documentation)
Struktur einer Contao 4.13 Installation durchgeführt per Contao Manager
| Datei / Verzeichnis | Erklärung | Backup nötig |
|---|---|---|
assets/ |
JavaScript, Bilder, CSS-Dateien von Contao und Erweiterungen | Nein |
config/ |
Konfigurationsdateien der Applikation | Ja |
contao-manager/ |
Konfiguration, Cache und Logfiles des Contao Managers | Bei Bedarfusers.json |
files/ |
Alle Dateien die über den Dateimanager von Contao verwaltet werden | Ja |
system/ |
Nötig für die Contao 3 Kompatibilität | nur teilweiseconfig/localconfig.php |
templates/ |
Angepasste Contao Templates | Ja |
var/ |
Automatisch generierte Dateien, wie der Anwendungscache und Protokolldateien | Nein |
vendor/ |
Composers Vendor-Verzeichnis beinhaltet alle Pakete und benötigten Abhängigkeiten (inkl. Contao-Core, Symfony und Contao-Erweiterungen) | Nein |
public/ bzw. web/ |
Öffentlicher Dokument-Root und Einstiegspunkt. Beinhaltet Symlinks und andere öffentliche Ressourcen | Nein |
composer.json |
Projekt-Konfiguration legt fest, welche Pakete und Versionen zur Contao Installation gehören und installiert werden dürfen | Ja |
composer.lock |
Wird durch «composer update» bzw. der Composer Cloud erzeugt und beinhaltet eine vollständige Liste aller Pakete und Abhängigkeiten mit exakter Versionsangabe, welche installiert sind. Per «composer install« wird diese Datei verarbeitet | Ja |
Weitere relevante Dateien und Verzeichnisse, die ggf. manuell erstellt wurden und nicht in jeder Installation vorhanden sind
| Datei / Verzeichnis | Erklärung | Backup nötig |
|---|---|---|
contao/ |
Anpassungen an Contao (z. B. DCA-Felder, Sprachdateien) | Ja |
src/ |
Individuelle Programmierungen für Contao | Ja |
system/modules/* |
Alte Contao 3 Module | Prüfen Nur Module, die manuell per SFTP installiert wurden, keine Symlinks! |
public/ bzw. web/ |
Öffentlicher Dokument-Root und Einstiegspunkt. Beinhaltet Symlinks und andere öffentliche Ressourcen | Prüfen Nur manuell hinzugefügte oder veränderte Dateien z. B. .htaccess |
Zusammenfassung
Für ein vollständiges Backup benötigst du die Verzeichnisse: «config», «files», «templates» sowie die Dateien «localconfig.php», «composer.json» und «composer.lock».
Solltest du in deinem Projekt noch alte Contao 3 Module nutzen, dann musst du die entsprechenden Module aus dem Verzeichnis «/system/modules» sichern.
Falls individuelle Anpassungen vorgenommen wurden, solltest du auch die Verzeichnisse «contao» und «src» sichern.
Wenn du manuell Änderungen an der «.htaccess» vorgenommen hast, ist es ratsam diese ebenfalls zu sichern.
Wenn du willst, kannst du zudem die «users.json» des Contao Managers sichern. Das ist allerdings nur wichtig, wenn du die Zugangsdaten zum Contao Manager nicht erneut einrichten möchtest.
Muss ich wirklich immer alle Files sichern?
Bei größeren Projekten mit vielen Dateien kann der Ordner »files« schnell mehrere hundert MB oder sogar GB groß werden. Hier stellt sich die Frage, ob du immer ein komplettes Backup erstellen musst.
Es macht durchaus Sinn, ein komplettes Backup zu haben, wenn du sonst keine regelmäßigen Backups erstellst. Vor größeren Änderungen und Versionswechsel macht eine komplette Sicherung ebenfalls Sinn.
Allerdings sehen wir gerade bei kleinen Bugfix-Updates, wie z. B. von Contao 4.13.24 auf 4.13.25 keinen Mehrwert für ein volles Backup. Hier ändern sich in der Regel keine Templates. Zudem sind CSS-Anpassungen in den wenigsten Fällen nötig. Deswegen sichern wir vor einem Bugfix-Release nur »composer.json«, »composer.lock« und erstellen einen aktuellen Dump der Datenbank. Anschließend installieren wir per trakked unsere Updates.
Sollte es doch zu unerwarteten Problemen kommen, können wir mithilfe der «composer.lock« und der Datenbank zügig die vorherige Version wiederherstellen.
Soweit zur Theorie. Kommen wir noch ein wenig zur Praxis.
Wie kannst du ein Backup durchführen?
Den EINEN richtigen Weg gibt es nicht. Es hängt ganz stark von deinen Fähigkeiten, dem Hosting und deinem Workflow ab. Wir möchten dir hier kurz ein paar Möglichkeiten und Ideen aufzeigen.
1) Backup per SFTP und phpMyAdmin
Das wird dir sicher bekannt vorkommen.
Dateien und Verzeichnisse
Hierfür verbindest du dich mit einem SFTP-Client (z. B. Filezilla, WinSCP) mit deinem Server und transferierst die betreffenden Dateien lokal oder kopierst diese in ein anderes Verzeichnis auf dem Server.
Alternativ kannst du auch den Web-FTP des Hosters verwenden und die entsprechenden Dateien herunterladen oder kopieren.
Datenbank sichern
Hier kannst du phpMyAdmin verwenden. Dieses Tool ist bei nahezu jedem Hoster verfügbar. Du wählst dazu deine entsprechende Contao-Datenbank und führst mit phpMyAdmin einen Export durch. Seit Contao 4.13 wird zudem ein automatisches Backup bei jeder Datenbankmigration, die du über den Contao Manager ausführst, gesichert. Standardmässig werden die Backups in «var/backups» gespeichert und dort auch verwaltet.
Wenn du Contao 4.13 und trakked nutzt, dann erhältst du automatisch ein Mini-Backup für deine Installation. Denn trakked sichert bei jedem Update eine aktuelle «composer.json» und «composer.lock», die du bei Bedarf herunterladen kannst. Contao 4.13 führt zudem ein automatisches Backup bei jeder Datenbankmigration durch, die du über den Contao Manager ausführst. Somit hast du alles Wichtige, um im Notfall dein Contao-System auf einen älteren Stand zurückzusetzen.
2) Backup per Konsole
Hierfür benötigst du SSH-Zugriff auf deinen Server. Das sollte heute bei den meisten proffesionallen Hostern vorhanden sein.
Dateien und Verzeichnisse sichern
Hierfür kannst du den Befehl «cp» verwenden und die entsprechenden Dateien kopieren.
Das könnte dann vor einem Bugfix-Update so aussehen:
# Login auf Server ssh user@domain.ch
# In das Backup Verzeichnis wechseln cd public_html/backup/domain.ch
# Neues Verzeichnis erstellen mkdir 4.13.20
# In public_html Verzeichnis wechseln cd ../../public_html
# Dateien von Contao nach Backup kopieren cp domain.ch/composer.json backup/domain.ch/4.13.20 cp domain.ch/composer.lock backup/domain.ch/4.13.20/
# Dump Datenbank mysqldump -h localhost -u username -p --opt databasename | gzip -c > backup/domain.ch/4.13.20/mysqldump.sql.gz
Seit Contao 4.13 kannst du für ein Datenbankbackup auch den Befehl «contao:backup:create» verwenden. Mehr dazu findest du im Contao Handbuch.
Um diese Schritte zu optimierten, kannst du auch ein Shell-Script erstellen, welches du vorbereitest und einfach bei Bedarf oder regelmässig per CronJob ausführen kannst.
Ein fertiges Script stellt z. B. Andreas Fieger auf seinem GitHub-Account bereit.
3) Backup per Erweiterung
Zusätzlich gibt es zahlreiche Erweiterungen, die dich beim Backup unterstützen können.
Bei den meisten Erweiterung wird allerdings nur die Datenbank gesichert. Auf YouTube findest du ein Video zur Datensicherung per BackupDB.
Es gibt noch zahlreiche weitere Möglichkeiten. Dazu gehören je nach Hoster eine Backup- oder Snapshot-Funktionen sowie Deployment-Tools oder externe Backup-Lösungen.
Zusammengefasst
Bei einem einfachen Bugfix-Release reicht ein Backup der «composer.json», «composer.lock» und der Datenbank. Mit trakked und Contao 4.13 hast du dieses Mini-Backup bereits «out of the box». Ansonsten kannst du die Sicherung auf unterschiedliche Arten durchführen. Wichtig ist nur, dass du dich darum kümmerst.
Wie sicherst du deine Contao-Installation?
Lass uns gerne dein Feedback per Slack, als Kommentar oder per E-Mail zukommen.
