All Inkl und fiedsch/contao-4-backup-script

Ich habe bei All-Inkl. ein Problem mit dem Backup-Script (fiedsch/contao-4-backup-script) als Cronjob.

Wenn ich es richtig verstanden habe, kann ich bei All-Inkl. ein Shell-Script nicht direkt aufrufen https://all-inkl.com/wichtig/anleitu...ehren_304.html

Also rufe ich das Script in eine PHP-Datei auf.

PHP-Code:

---

<?php exec("/bin/bash /www/htdocs/xxx/meinpfad/main.sh");?>

---

Das funktioniert auch soweit. Leider wird dabei aber nur die DB gesichert.
Rufe ich das Skript direkt über die Shell auf, werden auch die Standarddateien und -ordner (composer.json,... app/,...) und der Ordner files/ gesichert.

Habe ich noch etwas vergessen?
Werden die Befehle eventuell bei All-Inkl. geblockt?
Hat jemand Erfahrung mit dem Script bei All-Inkl. Paket Premium?

Mir fehlt bei All-Inkl. etwas die Erfahrung. Habe da kaum Kunden.


Edit: Korrektur Tipfehler

All Inkl bietet selbst recht einfache Lösungen um den ganzen Webspace und/oder Datenbanken per Cron zu sichern. Da würde ich gar nicht lang mit Contao Modulen etc rumtun.

Filesystem: https://all-inkl.com/wichtig/anleitu...ichten_97.html
Datenbank: https://all-inkl.com/wichtig/anleitu...tellen_83.html


Die Dateinamen der Backups kann man mit etwas PHP noch etwas optimieren

PHP-Code:

---

$mysqlBackupDate = date("YmdHis");
$mysqlExportPath ='db123456789_'.$mysqlBackupDate.'.sql.gz'; 


---

Wird dann schön geordnet db123456789_20180818000036.sql.gz




All Inkl hat im Backend (KAS -> Tools) auch noch eine automatische Verzeichnisbereinigungsfunktion. Hier kann man automatisch den Ordner der Backups entsprechend bereinigen. Z.B. Alle Dateien älter als 30 Tage entfernen. Somit hat man ohne viel Aufwand Backups vom Filesystem und/oder DB der letzten 30 Tage.


Sorry, falls das ein wenig Offtopic war.

Ich hatte das Script genutzt, weil ich es gerade bei anderen Hostern getestet hatte und ich die Möglichkeiten von All-Inkl. gar nicht auf dem Schirm hatte.

Danke, also für die Links.

Trotzdem interessiert mich die Ursache des Problems auch noch.

Zitat:

---

Zitat von mlweb

Also rufe ich das Script in eine PHP-Datei auf.

PHP-Code:

---

<?phpexec("/bin/bash /www/htdocs/xxx/meinpfad/main.sh");?>"

---

---

Sind das nur Tippfehler hier im Forum, dass Du beispielsweise zwischen <?php und exec kein Leerzeichen/Return hast und am Ende nach ?> noch ein Anführungszeichen steht?

Hallo Maren,

ich muss das bei Gelegenheit mal testen, denn aktuell helfe ich einem Freund bei einer neuen Site und das ist auch bei all-incl. Wir hatten da gestern einige Probleme mit der Datenbank. Wenn ich diesbezüglich noch etwas herausfinde, füge ich es hier hinzu.

Wieso versuchst Du, das Bash-Skript in ein PHP-Skript zu packen?

Was passiert, wenn Du das Skript direkt auf der Konsole aufrufst?

Wie heißt es hier so (wenig) schön: Das Skript muss per HTTP ausführbar sein.

Zitat:

---

Zitat von tab

Wie heißt es hier so (wenig) schön: Das Skript muss per HTTP ausführbar sein.

---

Liefert aktuell sogar ein 404…

Hier die Links dazu (den einen hatte @mlweb oben schon gepostet):

https://all-inkl.com/wichtig/anleitu...htung_479.html
https://all-inkl.com/wichtig/anleitu...ehren_304.html

Das heißt dann praktisch, All-Inkl bietet keine vollwertigen Cronjobs an, sondern nur das, was bei Webgo z.B. Cronjob Light heißt.:(

Hallo Maren,

für dein ursprüngliches Problem könnte verantwortlich sein, dass das Script nicht in deinem Contaoordner ausgeführt wird.
Mit

Code:

---

<?phpexec("/bin/bash /www/htdocs/xxx/meinpfad/main.sh");?>"

---

stehst du ja irgendwo und rufst die main.sh absolut auf.
Vielleicht musst du zuerst per cd in /www/htdocs/xxx/meinpfad/ wechseln und dann dort ./main.sh aufrufen?

Edit:
Nee, wahrscheinlich nicht, da das Script ja mit den konfigurierten Pfaden arbeitet...

Zitat:

---

Zitat von xchs

Sind das nur Tippfehler hier im Forum, dass Du beispielsweise zwischen <?php und exec kein Leerzeichen/Return hast und am Ende nach ?> noch ein Anführungszeichen steht?

---

Ja, ist nur ein Tippfehler im Forum. habe ich oben korrigiert.

Zitat:

---

Zitat von folkfreund

stehst du ja irgendwo und rufst die main.sh absolut auf.
Vielleicht musst du zuerst per cd in /www/htdocs/xxx/meinpfad/ wechseln und dann dort ./main.sh aufrufen?

---

Konnte ich mir schwer vorstellen, denn auf der Konsole klappt es auch, unabhängig davon in welchem Pfad ich bin. Nutze ich das Script z.B. bei Webgo läuft das problemlos, aber dort habe ich eben auch einen richtigen Cronjob (also direkter Aufruf der main.sh).
Getestet habe ich es trotzdem. Leider mit dem gleichen Ergebnis.

Zitat:

---

Zitat von fiedsch

Wieso versuchst Du, das Bash-Skript in ein PHP-Skript zu packen?

---

Weil das bei All-Inkl. scheinbar nicht anders geht. Es sei denn ich habe das völlig falsch verstanden.

Zitat:

---

Zitat von fiedsch

Was passiert, wenn Du das Skript direkt auf der Konsole aufrufst?

---

Siehe oben. In der Konsole gestartet arbeitet das Script fehlerfrei.

Es macht wahrscheinlich auch keinen Unterschied, wenn Du Deine PHP-Datei anstelle mit Endung *.php mal mit *.phpx aufrufst. Zumindest in älteren Anleitungen ist nämlich davon die Rede, dass das für das Ausführen von exec() mal notwendig gewesen wäre.

Sie wird ja aufgerufen und ausgeführt, denn der Teil für die Datenbanksicherung des Scriptes wird ja ausgeführt.

Lässt Du das komplette files-Verzeichnis mitsichern? Falls ja, hast Du mal probiert, in main.sh

Code:

---

BACKUP_CONTAO_FILES=0

---

zu setzen? Vielleicht dauert das Erstellen des Archivs einfach zu lange und wird beim Erreichen des Limits einfach abgebrochen.

Sind sonst noch große Verzeichnisse dabei, die mitgesichert werden?

Habe das Files-Verzeichnis mal rausgenommen. Dann bekomme ich ganz korrekt einen Textfile mit der Meldung: "Dateisicherung übersprungen, da BACKUP_CONTAO_FILES=0 in /www/htdocs/xxx/meinpfad/main.sh".
Bei den Standardverzeichnissen ist nichts großes dabei und individuelle Verzeichnisse bzw. Dateien habe ich nicht eingetragen. Habe aber testweise das c4-backup.sh mal so angepasst, dass ausschließlich die composer.json und die composer.lock gesichert werden.

Zitat:

---

Zitat von mlweb

Habe aber testweise das c4-backup.sh mal so angepasst, dass ausschließlich die composer.json und die composer.lock gesichert werden.

---

Wurde dieses Archiv ohne Deine Änderungen an der c4-backup.sh sonst auch nicht erstellt? Eigentlich dürfte dieses Archiv nur ganz klein sein (< 100 kB oder so), da im Prinzip nur Konfigurationsdateien gesichert werden (sofern keine großen Verzeichnisse zusätzlich mitgesichert werden). Es wäre eben interessant gewesen zu wissen, ob es tatsächlich beim Erstellen des Archivs des files-Verzeichnisses scheitert oder ob es auch sonst irgendein Problem gibt.

Bei Aufruf des Cronjobs wird ausschließlich die Datei

meinname_2018-12-09.sql.gz (344kb) als Backup der DB erstellt.

Bei Aufruf über die Konsole werden so wie es sich gehört alle drei Dateien erstellt
meinname_2018-12-09.sql.gz (344kb)
meinname_2018-12-09.tar.gz (163kb)
meinname_files_2018-12-09.sql.gz (5.532kb)

Wenn ich BACKUP_CONTAO_FILES=0 einstelle bekomme ich beim Cronjob zusätzlich die Datei meinname_files_2018-12-09.txt. Die Datei meinname_2018-12-09.tar.gz wird auch dann nicht erstellt.

Zitat:

---

Zitat von mlweb

Die Datei meinname_2018-12-09.tar.gz wird auch dann nicht erstellt.

---

Ah, okay. Dann ist schon mal klar, dass die Laufzeit für die Backupoperation nicht ursächlich dafür ist.

Vielleicht sind bei All-Inkl bestimmte Shellbefehle nicht via exec() zugelassen.

Zitat:

---

Zitat von mlweb

Wenn ich BACKUP_CONTAO_FILES=0 einstelle bekomme ich beim Cronjob zusätzlich die Datei meinname_files_2018-12-09.txt. Die Datei meinname_2018-12-09.tar.gz wird auch dann nicht erstellt.

---

Das ist korrekt und auch so beabsichtigt. Die *.txt hatte ich als Marker gedacht, damit man ein ausgeschaltetes file/-Backup nicht so leicht übersieht.

Zitat:

---

Zitat von mlweb

Nutze ich das Script z.B. bei Webgo läuft das problemlos

---

Wollte es mal eben bei Webgo ausprobieren. Schon der Aufruf aus der Konsole scheitert:

• Dateien von github in einen eigenen Ordner /home/www/meinpfad/contao-4-backup in der Contaoinstallation kopiert (parallel zu /home/www/meinpfad/web)
• main.sh angepasst
• in der Konsole aufgerufen: /home/www/meinpfad/contao-4-backup/main.sh

Fehlermeldung:

Code:

---

PHP Fatal error:  Uncaught TypeError: Return value of Contao\ManagerPlugin\Bundle\Parser\DelegatingParser::addParser() must be an instance of Contao\ManagerPlugin\Bundle\Parser\void, none returned in /home/www/meinpfad/vendor/contao/manager-plugin/src/Bundle/Parser/DelegatingParser.php:25

---

Habt ihr 'ne Idee, was ich übersehen haben könnte?

Zitat:

---

Zitat von folkfreund

Habt ihr 'ne Idee, was ich übersehen haben könnte?

---

Richtige PHP-Version?

In https://github.com/fiedsch/contao-4-...er/main.sh#L15 wird einfach php verwendet. Das passt, wenn auf PHP dem Server passend konfiguriert ist. Vielleicht brauchst Du hier (wie z.B. im Contao-Manager) die direkte Angabe inkl. Pfad.

Laut https://github.com/contao/contao-manager/wiki/webgo wäre das dann /usr/bin/php{major}.{minor}

Zitat:

---

Zitat von fiedsch

Laut https://github.com/contao/contao-manager/wiki/webgo wäre das dann /usr/bin/php{major}.{minor}

---

Ja genau bei Webgo habe ich genau wie auch bei All-Incl. den PHP-Pfad entsprechend angepasst.

Zitat:

---

Zitat von fiedsch

Das ist korrekt und auch so beabsichtigt. Die *.txt hatte ich als Marker gedacht, damit man ein ausgeschaltetes file/-Backup nicht so leicht übersieht.

---

Das hatte ich im Script auch so interpretiert, aber trotzdem fehlt mir ja beim Aufruf über die Konsole die Sicherung der meinname_2018-12-09.tar.gz.

Zitat:

---

Zitat von xchs

Vielleicht sind bei All-Inkl bestimmte Shellbefehle nicht via exec() zugelassen.

---

Kann ich das irgendwie elegant testen? Sonst frag ich morgen mal den Support danach.

Bei mir funktioniert es jetzt. Und mit BACKUP_CONTAO_FILES=0 werden außer der genannten .txt-Datei eine .tar.gz und eine .sql.gz erzeugt, so wie erwartet.
Danke! :)

Ich habe den für All-Incl beschriebenen Weg zur Ausführung von Skripten in cron-jobs (https://all-inkl.com/wichtig/anleitu...c&textsuche=ja) eben lokal getestet:

• 1. Versuch: mein Shellskript manuell aufgerufen => funktioniert
• 2. Versuch: eben dieses Shellskript unter "Pfad zum Script" eingesetzt und die PHP-Datei auf der Kommandozeile aufgerufen => funktioniert
• 3. Versuch: die PHP-Datei über den Browser aufgerufen => funktioniert nicht mit folgendem Output:

Returncode: 0
Ausgabe des Scripts:
Array
(
[0] => /Users/andreas/Project/contao-4-backup-script/c4-backup.sh: line 52: /Users/andreas/.../backup_2018-12-10.txt: Permission denied
[1] => tar: Failed to open '/Users/andreas/.../backup_2018-12-10.tar.gz'
[2] => /Users/andreas/Project/contao-4-backup-script/c4-backup.sh: line 163: /Users/andreas//backup_2018-12-10.sql: Permission denied
)

Heißt: es funktioniert nicht, weil der Webserverprozess in die im Backupskript angegebenen Zielverzeichnisse für das Backup nicht schreiben darf.

Das ist natürlich das Erwartete Ergebnis! Daher

• 4. Versuch: im Shellskript unter TARGET_DIR ein Verzeichnis angegeben, in das der Webserver schreiben darf (files/ Verzeichnis der Contao-Installation) => funktioniert

Heißt für mich erst ein Mal:

• der Weg über ein zusätzliches PHP-Programm sollte grundsätzlich funktionieren
• das Problem wird wohl an gesperrten Funktionen liegen
• da ich selbst kein All-Inkl Paket habe, kann ich hier einstweilen nicht weiter testen -- sorry.

@mbweb: Das Thema schreibbares Zielverzeichnis ist aber wahrscheinlich nicht das Problem bei Dir, denn die Datei mit dem Datenbank-Dump wird ja erstellt.

Habe jetzt mal den Support von All-Inkl. ins Boot geholt. Die wollen sich das mal anschauen.

Nach etwas hin und her hier die Antwort von All-Inkl.:

"Die Befehle /bin/tar und /bin/uname sind als Sicherheitsgründen nur in der Konsole verfügbar, nicht per exec. Sie können hier "/bin/ptar" verwenden."

Als ich ein bisschen mit deinem Script gespielt habe, habe ich festgestellt, dass anscheinend /bin/rm und /bin/ls/ ebenfalls nicht erlaubt sind.

Ich habe mir auch ptar mal etwas näher angeschaut, werde aber nicht ganz schlau aus der Beschreibung. Verstehe ich es richtig, dass man damit nur einzelne Dateien archivieren kann?

Auf jeden Fall reicht mein Wissen nicht um das Script damit zum laufen zu bringen. Weiß auch nicht, ob das unter den Umständen Sinn macht.
Schade eigentlich. Ich wollte mich gerade mit All-Inkl. näher anfreunden.

Nein, ich gehe davon aus, dass ptar durchaus auch ganze Verzeichnisse oder auch mehrere Verzeichnisse und Dateien archivieren kann, also im Prinzip wie tar. Jedenfalls konnte ich gerade bei uberspace mittels ptar ein Verzeichnis archivieren. Wie sieht denn dein tar-Befehl aus und wie hast du es mit ptar probiert?

@tab

Danke für die Info.
Da es mir insgesamt ja um den Einsatz des Scriptes von @fiedsch ging, werde ich jetzt erst mal nicht weiter testen.
Bei All-Inkl. sind ja offensichtlich per excec einige Shellbefehle gesperrt, die im Script genutzt werden.

ptar muss ich mir anschauen. Wenn es die identischen Optionen und Möglichkeiten hat, wie tar, dann könnte man konfigurierbar machen, was eingesetzt werden soll.

Nach einem ersten schnellen Test würde ich sagen: ptar funktioniert als Ersatz für tar. Lediglich die Option z (Ergebnis komprimieren) muss entfallen und durch einen nachgeschalteten Aufruf von gzip ersetzt werden.

Das wäre z.B.

Code:

---

tar cfz ${TARGET_DIR}/${DUMP_NAME}_files_${NOW}.tar.gz files
# wird zu
ptar cf ${TARGET_DIR}/${DUMP_NAME}_files_${NOW}.tar files && gzip ${TARGET_DIR}/${DUMP_NAME}_files_${NOW}.tar

---

uname wirde nur verwendet, um herauszufinden, auf welchem Betriebssystem das Skript läuft und damit festzulegen, wie der Aufruf bei date aussehen muss, um das Datum vor x Tagen zu bestimmen. Das sollte aber nur ein Thema sein, wenn die Variable PURGE_AFTER_DAYS einen Wert > 0 hat.

rm und ls kommen auch nur innerhalb des Blocks vor, der mit PURGE_AFTER_DAYS=0 nicht ausgeführt wird.

Das behebt dann zwar nicht alle Probleme, aber vielleicht ist es einen Versuch wert. @mlweb soll ich Di eine angepasste Version von c4-backup.sh bauen?

Hallo Andreas,
würde ich auch gerne zwischen den Jahren testen - da mehr als 90% aller Websites bei allinkl. Danke für dein Script!

Ja wäre nett.
Ich hatte es gestern schon mal selbst probiert - tar durch ptar ersetzt (allerdings das z nicht entfernt, gibt es ja als Option auch) und die if-Abfrage in dem Teil bei uname enfernt - dann kamen aber die nächsten Fehler mit rm und ls.
Da ich mir nicht mal sicher war ob ich ptar richtig verwendet habe, hatte ich erst mal keine Lust mehr und war leicht angesäuert auf All-Inkl. und den "Sch.." mit dem Cronjob über php.

Braucht ihr das überhaupt? Um Backups sollte sich ja der Hoster kümmern. Oder sind die bei All-inkl zu schlecht?

Ich finde das Script von @fiedsch schon cool um nur die Sachen einer Contao-Installation zu sichern, die man tatsächlich benötigt.

Ansonsten habe ich zu wenig Erfahrung mit All-Inkl.

Zitat:

---

Zitat von Spooky

Braucht ihr das überhaupt? Um Backups sollte sich ja der Hoster kümmern. Oder sind die bei All-inkl zu schlecht?

---

siehe https://all-inkl.com/webhosting/datensicherung/

Wenn du mal eben schnell ein Backup brauchst und das mit einem Aufruf erledigen kannst, ist das sicher eine Hilfe und Zeitersparnis.

Zitat:

---

Zitat von Spooky

Braucht ihr das überhaupt? Um Backups sollte sich ja der Hoster kümmern. Oder sind die bei All-inkl zu schlecht?

---

Ja, sollte der Hoster machen, aber: Paranoia-Mode oder "Hosenträger und Gürtel".

Spätestens beim Umzug einer Installation ist das Backup dann wieder hifreich, da ein Umzug ja auch nichts anderes ist als eine Wiederherstellung auf einem anderen Server.

Ich habe die Sicherung auch schon immer unter meinen Fittichen haben wollen. Für die DB habe ich bisher backupDB genutzt. Die ganzen Konfigurationsdateien und die templates habe ich von meiner lokalen Entwicklung einmal liegen. Außerdem habe ich diese und die files von Zeit zu Zeit (mindestens vor jedem Update) einmal manuell gesichert. Automatisch ist aber deutlich eleganter. Außerdem vergisst man bei einem einmal korrekt eingerichteten Skript nicht irgendwann mal was.