Backup-Lösung (Dateien und DB) für Contao-Installationen auf Shared Hosting

[Balduin]

Ich habe ein kleines Backup-Script veröffentlicht, das Contao-Dateien und Datenbank sichert. Es ist auch ohne SSH-Zugang nutzbar und lässt sich per PHP-Trigger mit URL-Cronjob automatisieren:

https://github.com/elektrischerwalfi...p-shell-script

Das Script läuft serverseitig, unabhängig von Contao-Extensions und Backend.

Kurzüberblick:

• Contao 4.x und 5.x (Credentials aus parameters.yml bzw. .env.local)
• Datei-Backup per tar mit konfigurierbaren Excludes
• DB-Backup per mysqldump
• automatische Aufbewahrung älterer Backups (MAX_BACKUPS)
• Logging und optionale E-Mail bei Fehlern
• für Hoster ohne SSH: Ausführung per PHP-Trigger und URL-Cronjob möglich

Getestet auf all-inkl und IONOS.

Feedback und Issues sind willkommen — besonders von anderen Shared-Hosting-Setups.

[CeeKay]

Nur als Ergänzung, es gibt auch noch: https://github.com/fiedsch/contao-4-backup-script

[Balduin]

Nur als Ergänzung, es gibt auch noch: https://github.com/fiedsch/contao-4-backup-script

Danke für den Hinweis — das kannte ich bei der Entwicklung meines Scripts tatsächlich noch nicht, habe ich mir nun aber mal angeschaut.

Auf den ersten Blick ist der Ansatz ähnlich (Shell, mysqldump, tar). Mein Script lagert die Konfiguration in eine .env-Datei aus (statt Variablen direkt im Shell-Script) und zielt zusätzlich auf Shared Hosting ohne SSH (PHP-Trigger), automatische Credential-Erkennung für Contao 4/5 sowie Retention, Logging und Fehler-Mail. Freue mich über Feedback, ob das für eure Setups relevant ist.

[zoglo]

Danke für den Hinweis — das kannte ich bei der Entwicklung meines Scripts tatsächlich noch nicht, habe ich mir nun aber mal angeschaut.

Auf den ersten Blick ist der Ansatz ähnlich (Shell, mysqldump, tar). Mein Script lagert die Konfiguration in eine .env-Datei aus (statt Variablen direkt im Shell-Script) und zielt zusätzlich auf Shared Hosting ohne SSH (PHP-Trigger), automatische Credential-Erkennung für Contao 4/5 sowie Retention, Logging und Fehler-Mail. Freue mich über Feedback, ob das für eure Setups relevant ist.

Nur als kurze Frage hierzu (habe hier starke Sicherheitsbedenken, scheint auch LLM generiert der Comment, falls nicht, bitte ignorieren)
https://github.com/elektrischerwalfi...p.php#L82-#L97

Das heißt, wenn es zu einem Fehler kommt, so gibst du alles im Error aus und leakst so den kompletten Fehler? Inklusive Pfad und weiterem mit Trace
Ich würde das hier nochmal überdenken und bzgl. Security überprüfen, denn viele Leute werden sich die contao-backup.php schön in Public oder web reinwerfen.

[Balduin]

Nur als kurze Frage hierzu (habe hier starke Sicherheitsbedenken, scheint auch LLM generiert der Comment, falls nicht, bitte ignorieren)
https://github.com/elektrischerwalfi...p.php#L82-#L97

Das heißt, wenn es zu einem Fehler kommt, so gibst du alles im Error aus und leakst so den kompletten Fehler? Inklusive Pfad und weiterem mit Trace
Ich würde das hier nochmal überdenken und bzgl. Security überprüfen, denn viele Leute werden sich die contao-backup.php schön in Public oder web reinwerfen.

Hey zoglo, vielen Dank für den Hinweis — berechtigter Punkt!

Die ausführliche HTTP-Ausgabe war ursprünglich nur für Tests ohne SSH gedacht und ist im Laufe der Entwicklung wieder reingerutscht. Als Schutz hatte ich kurz IP-Filter per .htaccess geplant; das erwies sich auf Shared Hosting (z. B. IONOS) aber als unzuverlässig, weil Cron-IPs wechseln können — daher verworfen (siehe README, Abschnitt Trigger Security).

An die Fehlerausgabe im PHP-Trigger habe ich dabei nicht mehr gedacht. Ein vollständiger Stack-Trace wurde nicht ausgegeben, aber Pfade und Setup-Hinweise konnten sichtbar werden — das war zu viel für einen öffentlich erreichbaren Trigger.

In v1.1.0 ist das jetzt per `$debugMode` gelöst (Standard: `false`, nur minimale Meldungen wie „Process started/finished/Error“). Details stehen weiter in `backup.log`. Zusätzlich ist in der README dokumentiert, dass das Tool nicht ins Contao-`web/`/`public/` gehört, sondern separat liegt muß — mit eigener Cron-URL/Subdomain.

Token-Auth für den Trigger wäre der nächste sinnvolle Schritt; dazu gibt es bereits einen Issue im Repo, falls jemand mithelfen möchte.