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.

Zitat:

Zitat von mlweb

Ja wäre nett.

Ich habe versucht die bis jetzt bekannten Probleme zu beseitigen und einen neuen Branch erstellt:

https://github.com/fiedsch/contao-4-...t/tree/allinkl

@mlweb, @planepix: Wenn ihr es testen wollt, dann müsst ihr in eurer main.sh noch die Variable TAR=ptar setzen. Ansonsten hat sich dort nichts geändert.

Beim Aufruf des Scriptes über den Browser und über den Cronjob werden jetzt wie es sich gehört alle drei Dateien geschrieben.
Danke @fiedsch.
Wie erwartet bekomme ich aber beim Aufruf über den Browser noch einen Fehler wegen des ebenfalls nicht innerhalb von exec ausführbaren /bin/uname

Code:

Returncode: 1 Ausgabe des Scripts: Array ( [0] => mysqldump: [Warning] Using a password on the command line interface can be insecure. [1] => mysqldump: [Warning] Using a password on the command line interface can be insecure. [2] => /www/htdocs/xxx/meinPfad/c4-backup.sh: line 191: /bin/uname: Permission denied [3] => unknown operating system )

Wenn ich die if-Funktion mit uname dort auskommentiere und von Linux als Operating-System ausgehe, laufe ich dann bei rm und ls in einen Fehler, weil die auch nicht erlaubt sind.
Außerdem wird anders als über die Konsole die Löschung der files und Standard-Dateien vom gleichen Tag nicht angeboten.

Code:

Returncode: 126 Ausgabe des Scripts: Array ( [0] => gzip: /www/htdocs/xxx/meinPfad/meinname_files_2018-12-12.tar.gz already exists; not overwritten [1] => gzip: /www/htdocs/xxx/meinPfad/meinname_2018-12-12.tar.gz already exists; not overwritten [2] => mysqldump: [Warning] Using a password on the command line interface can be insecure. [3] => mysqldump: [Warning] Using a password on the command line interface can be insecure. [4] => loesche altes Backup vom '2018-11-12' [5] => /www/htdocs/xxx/meinPfad/c4-backup.sh: line 205: /bin/rm: Permission denied [6] => /www/htdocsxxx/meinPfad/c4-backup.sh: line 206: /bin/ls: Permission denied )

Ich denke aber auf das automatische Löschen könnte man vielleicht verzichten. Ich habe da auch etwas von einer automatischen Löschfunktion bei All-inkl. gesehen. Das werde ich mir aber erst demnächst genauer anschauen können.
Noch etwas ist mir aufgefallen. Das "alte" Script konnte ich auch als PHP-Script in der Konsole aufrufen. Diese Version bleibt in der Konsole hängen, wenn ich den Aufruf des PHP-Scriptes starte. Direkter Aufruf von main.sh funktioniert natürlich.

Nachtrag: Gerade gefunden wie man bei All-Inkl. die älteren Datei löschen könnte (unter Tools->Webspacebereinugung). Werde ich dann gleich mal einrichten.

Hallo Maren,

Danke für's Feedback.

Zitat:

Zitat von mlweb

Wie erwartet bekomme ich aber beim Aufruf über den Browser noch einen Fehler wegen des ebenfalls nicht innerhalb von exec ausführbaren /bin/uname

Hier könnte man den versuch der automatischen Erkennung noch so abändern, daß das Betriebssytem in der Konfiguration angegeben werden müsste.
Dann wäre der uname-Aufruf schon mal weg. Das bringt im All-Incl Fall aber wahrscheinlich nicht so viel, da dann die nächsten Probleme auftreten (rm und ls).
ls dient eigentlich nur dazu, daß eine Auflistung der vorhandenne Dateien erzeugt wird, was ich hilfreich finde, wenn man sich den Output des Cronjobs per E-Mail zuschicken lässt. Ansonsten kann das natürlich ersatzlos gestrichen werden. Bliebe rm: Wenn ich nicht falsch liege, sollt das durch setzen von PURGE_AFTER_DAYS=0 gelöst werden können. Dann sollte der Block nicht ausgeführt werden und Du kümmerst Dich selbst (auf anderem Weg um das Löschen der alten Backups).

Zitat:

Außerdem wird anders als über die Konsole die Löschung der files und Standard-Dateien vom gleichen Tag nicht angeboten.

Die Dateien vom selben Tag -- die eben erst angelegt wurden -- sollten doch nie gelöscht werden. Wo stehe ich hier auf dem Schlauch?

Zitat:

Code:

[0] => gzip: /www/htdocs/xxx/meinPfad/meinname_files_2018-12-12.tar.gz already exists; not overwritten

Das "not overwritten" ist das Ergebnis des jetzt separaten Aufrufs von gzip <datei> nachdem die <datei> von ptar erstellt wurde. Wenn Du das Skript mehrmals nacheinander am gleichen Tag aufrufst, passiert das. Im wirklichen Betrieb sollte das aber kein Thema sein. Oder wir hängen noch ein --force an den gzip-Aufruf an.

Zitat:

Noch etwas ist mir aufgefallen. Das "alte" Script konnte ich auch als PHP-Script in der Konsole aufrufen. Diese Version bleibt in der Konsole hängen, wenn ich den Aufruf des PHP-Scriptes starte. Direkter Aufruf von main.sh funktioniert natürlich.

Muss ich mal versuchen (unter MacOS) nachzustellen. Wäre zwar egal, denn "wenn Du schon auf der Konsole bist, dann rufe halt gleich das Skript auf", finde ich aber unschön und außerdem riecht es für mich nach "da könnte noch ein bisher nicht beachtetes Problem dahinter stecken".

Zitat:

Zitat von fiedsch

... finde ich aber unschön und außerdem riecht es für mich nach "da könnte noch ein bisher nicht beachtetes Problem dahinter stecken".

Deshalb habe ich es Dir mitgeteilt.
Auf die Idee das PHP-Script über die Konsole aufzurufen bin ich auch nur deshalb gekommen, weil ich irgendwann von All-Inkl dazu aufgefordert wurde und vermelden konnte, dass das PHP-Script gestartet auf Konsolenebene keine Probleme macht.

Das Löschen bei All-Inkl habe ich gestern schon ausgetestet. Kann man also gut über die Oberfläche von All-Inkl. realisieren.

Zitat:

Zitat von fiedsch

Die Dateien vom selben Tag -- die eben erst angelegt wurden -- sollten doch nie gelöscht werden. Wo stehe ich hier auf dem Schlauch?

Beim Aufruf über die Konsole kam ein Abfrage:

Code:

gzip: /www/htdocs/xxx/meinPfad/meineDatei_files_2018-12-13.tar.gz already exists; do you wish to overwrite (y or n)?

Geht also nicht ums Löschen sondern ums Überschreiben. Da habe ich nicht richtig hingeschaut.
Könnte die Abfrage das Hängenbleiben des PHP-Scriptes auf Konsolenebene verursachen?

PURGE_AFTER_DAYS=0 habe ich eingesetzt. Dann läuft das Script über den Browser durch so wie es jetzt ist.

Code:

Returncode: 0 Ausgabe des Scripts: Array ( [0] => gzip: /www/htdocs/xxx/meinPfad/meineDatei_files_2018-12-13.tar.gz already exists; not overwritten [1] => gzip: /www/htdocs/xxx/meinPfad/meineDatei_2018-12-13.tar.gz already exists; not overwritten [2] => mysqldump: [Warning] Using a password on the command line interface can be insecure. [3] => mysqldump: [Warning] Using a password on the command line interface can be insecure. )

Führe ich das Skript mehrfach am gleichen Tag aus, wird zusätzlich zu den Dateien meineDatei_Datum.tar.gz und meineDatei_files_Datum.tar.gz jeweils eine Datei meineDatei_Datum.tar bzw. meineDatei_files_Datum.tar erstellt und bei weiteren Wiederholungen überschrieben, während bei meineDatei_Datum.tar.gz und meineDatei_files_Datum.tar.gz die erste erstellte Datei erhalten bleibt. meineDatei_Datum.sql.gz wird bei jedem Durchlauf überschrieben.

Aber im Normalfall würde ich den Cronjob nur einmal am Tag laufen lassen. Sehe ich also auch nicht als Problem.

Mal so eine Idee. Wäre es nicht möglich, wenn kein Betriebssystem erkannt wird, das PURGE_AFTER_DAYS automatisch in Deinem Script auf 0 zu setzen.

Zitat:

Zitat von mlweb

Beim Aufruf über die Konsole kam ein Abfrage:

Code:

gzip: /www/htdocs/xxx/meinPfad/meineDatei_files_2018-12-13.tar.gz already exists; do you wish to overwrite (y or n)?

Geht also nicht ums Löschen sondern ums Überschreiben. Da habe ich nicht richtig hingeschaut.
Könnte die Abfrage das Hängenbleiben des PHP-Scriptes auf Konsolenebene verursachen?

Ich denke, ja: die Nachfrage ist kommt von gzip und beim Aufruf über das PHP-Skript antwortet ja keiner.

Zitat:

Führe ich das Skript mehrfach am gleichen Tag aus, [...]

dann würde ich den angehängten "Zeitstempel" so definieren, daß er auch eine Angabe zur Uhrzeit enthält, womit der Dateiname dann jedes Mal ein anderer wäre und nichts überschrieben würde.

Bsp.:

Code:

# Aktuell in c4-backup.sh eingestellt NOW=$(date +"%Y-%m-%d") # Beispiel mit Uhrzeit NOW=$("%Y-%m-%d_%H_%M_%S")

Wie detailliert Du bei der Uhrzeit (Stunde %H, Minute %M, Sekunde %S) sein willst musst Du selbst entscheiden.

Zitat:

Zitat von mlweb

Mal so eine Idee. Wäre es nicht möglich, wenn kein Betriebssystem erkannt wird, das PURGE_AFTER_DAYS automatisch in Deinem Script auf 0 zu setzen.

Bei der aktuellen Implementierung würden wir uns damit aber im Kreis drehen:

Wenn PURGE_AFTER_DAYS ungleich 0 ist, wird das Datum von vor PURGE_AFTER_DAYS Tagen zu ermitteln. Dabei muss je nach Betriebssystem unterschieden werden, da die date Aufrufe von Linux und BSD-Unixen wie MacOS andere Parameter haben (andere Betriebssysteme habe ich nicht im Einsatz und damit keine Ahnung, was es sonst noch geben könnte).

Und genau hier kommt der uname Befehl in's Spiel, der bei All-Incl gesperrt ist.

Code:

if PURGE_AFTER_DAYS ungleich 0 mittels uname Betriebssystem und damit date Aufrufsyntax bestimmen (=Problem bei All-Incl) endif

Dein Vorschlag wäre ja: Betriebssystem bestimmen (=Crash) um dann PURGE_AFTER_DAYS auf 0 zu setzen um bei der dortigen Betriebssystembestimmung nicht zu crashen.

Ausweg wäre, Das Betriebssystem oder gleich die Parameter für den date Aufruf als Konfigurationsoption anzugeben. Das könnte dann auch gleich Dein "mehrere Backups am Tag-Problem lösen". Bedeutet aber weitere Konfigurationsoptionen. Und hier wollte ich so wenige wie möglich verwenden. Meine Idee: was nicht angegeben werden muss kann auch nicht falsch angegeben werden.

Ich probiere dazu noch ein paar Möglichkeiten aus und melde mich wieder.

Bis dahin erst Mal Danke für's Feedback!

Ich habe eben im Branch 'allinkl'

https://github.com/fiedsch/contao-4-...t/tree/allinkl

die folgenden optional zu setzenden Variablen definiert:

Code:

# @mlweb: damit könntest Du Deine mehrmals täglichen Backups so konfigurieren, daß sie unterschiedliche Namen bekommen BACKUP_TIMESTAMP_FORMAT='%Y-%m-%d_%H_%M_%S' # Beim alte Backups löschen dann aber "alle des jeweiligen Tags" (muss logischerweise zu BACKUP_TIMESTAMP_FORMAT passen) PURGE_TIMESTAMP_FORMAT='%Y-%m-%d' # Wenn gesetzt, wird nicht versucht, dies mit Hilfe des bei All-Incl gesperrten uname zu ermitteln OSNAME='Linux'

Danke. Werde ich heute Abend mal austesten. Vorher komme ich wahrscheinlich nicht dazu.

Zitat:

Zitat von fiedsch

Das könnte dann auch gleich Dein "mehrere Backups am Tag-Problem lösen".

Das Problem ist wirklich nur beim Testen aufgetreten. Denn für die Tests wollte ich ja nicht jedesmal einen Tag warten.

Hallo miteinander,

ich grätsche hier mal rein, da ich ebenfalls bei all-inkl bin und eine Frage zu deren Backupscripten hätte :)
Ich nutze die Scripte leicht abgewandelt, und hab mir dazu noch im Backend 2 Links eingefügt, siehe hier.
Bis jetzt hab ich immer manuell per Klick meine Backups erstellt...
Angenommen, ich nutze dies jetzt als Cronjob (= Tarif Private plus), das tut.
Lasse ich jedoch automagisch alle Dateien älter als x löschen, werden doch meine beiden PHP Dateien im selbigen Verzeichnis mitgelöscht, oder irre ich mich da?
Verzeichnis ist (in der Contao Installation): /web/_backup/
Meine Hauptfrage wäre nun: wie biege ich den Ausgabepfad in den Scripten um, das die Ausgabe eine Ebene tiefer stattfindet?

Hier die beiden Scripte, da copy bei mir nicht funktionieren wird. ;)

DB Backup:

PHP-Code:

<?php // PHP-Konfiguration optimieren @error_reporting(E_ALL ^ E_WARNING); @ini_set("max_execution_time", 300); @ini_set("memory_limit", "512M"); ######## einstellungen ############################################# $db_name = "0815xyz"; $db_passwd = "subber-geheimes-pw"; $sql_file = "sql_dump_" . $db_name . "_" . date('Y-m-d_H-i-s') . ".sql"; #################################################################### exec("mysqldump -u $db_name -p'$db_passwd' --allow-keywords --add-drop-table --complete-insert --quote-names $db_name > $sql_file"); exec("gzip $sql_file"); $datei = $sql_file . ".gz"; $link = 'http://'.$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF']; $link = str_replace(basename(__FILE__),$datei,$link); echo "Backup fertig <a href='" . $link . "'>" . $datei . "</a"; ?>

FTP Backup:

PHP-Code:

<?php // PHP-Konfiguration optimieren @error_reporting(E_ALL ^ E_WARNING); @ini_set("max_execution_time", 300); @ini_set("memory_limit", "512M"); // Zu sicherndes Unterverzeichnis. Bleibt leer, wenn gesamter Account gesichert werden soll. $verzeichnis = "/_hp/"; // Auszuschließende Ressourcen $ignorieren = array("*.sql.gz", "*.tar.gz", "*.tgz", "kas_backup", "usage", "logs"); // PEAR-Klasse einbinden und Archiv erstellen $pfad = preg_replace('/(\/www\/htdocs\/\w+\/).*/', '$1', realpath(__FILE__)); include "Archive/Tar.php"; $archivname = "ftp_dump_".preg_replace('/.+\/(.+)\/$/', '$1', $pfad).date('_Y-m-d_H-i-s').".tar.gz"; $archiv = new Archive_Tar($archivname, true); $archiv->setIgnoreList($ignorieren); $archiv->createModify($pfad.$verzeichnis, "", $pfad); $link = 'http://'.$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF']; $link = str_replace(basename(__FILE__),$archivname,$link); echo "Backup fertig <a href='" . $link . "'>" . $archivname . "</a>"; ?>

Danke für Ideen!

ToM

Aloha,

ich mache es so, dass ich die Backup-Datei mit

PHP-Code:

rename()

verschiebe.

Gruß
Sebastian

Danke, ich frage mich nur schon seit einer Weile, wo und wie ich das an obigen Scripten zum laufen bekomme?

ToM

So, irgendwie hab ichs hingewurschdeld, macht das, was es soll: ein $targetdir = "data/"; an der richtigen Stelle kann Wunder bewirken :D

DB

PHP-Code:

<?php // PHP-Konfiguration optimieren @error_reporting(E_ALL ^ E_WARNING); @ini_set("max_execution_time", 300); @ini_set("memory_limit", "512M"); ############################################################################################################################################# ########## EDIT HERE ONLY ########### $db_name = "0815xyz"; ######################################### $db_passwd = "subber-secret-pw"; # # // Verzeichnis, wohin gesichert werden soll. Pfad gilt ab Script. # $targetdir = "data/"; # $sql_file = $targetdir . "sql_dump_" . $db_name . "_" . date('Y-m-d_H-i-s') . ".sql"; # # ############################################################################################################################################# exec("mysqldump -u $db_name -p'$db_passwd' --allow-keywords --add-drop-table --complete-insert --quote-names $db_name > $sql_file"); exec("gzip $sql_file"); $datei = $sql_file . ".gz"; $link = 'http://'.$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF']; $link = str_replace(basename(__FILE__),$datei,$link); echo "Backup fertig <a href='" . $link . "'>" . $datei . "</a"; ?>

FTP

PHP-Code:

<?php // PHP-Konfiguration optimieren @error_reporting(E_ALL ^ E_WARNING); @ini_set("max_execution_time", 300); @ini_set("memory_limit", "512M"); ############################################################################################################################################# ########## EDIT HERE ONLY ########### // Zu sicherndes Unterverzeichnis. Bleibt leer, wenn gesamter Account gesichert werden soll. ######################################### $verzeichnis = "/_hp/"; # // Verzeichnis, wohin gesichert werden soll. Pfad gilt ab Script. # $targetdir = "data/"; # # // Auszuschließende Ressourcen # $ignorieren = array("*.sql.gz", "*.tar.gz", "*.tgz", "kas_backup", "usage", "logs", "var"); # # ############################################################################################################################################# // PEAR-Klasse einbinden und Archiv erstellen $pfad = preg_replace('/(\/www\/htdocs\/\w+\/).*/', '$1', realpath(__FILE__)); include "Archive/Tar.php"; $targetdir = "data/"; $archivname = $targetdir . "ftp_dump_".preg_replace('/.+\/(.+)\/$/', '$1', $pfad).date('_Y-m-d_H-i-s').".tar.gz"; $archiv = new Archive_Tar($archivname, true); $archiv->setIgnoreList($ignorieren); $archiv->createModify($pfad.$verzeichnis, "", $pfad); $link = 'http://'.$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF']; $link = str_replace(basename(__FILE__),$archivname,$link); echo "Backup fertig <a href='" . $link . "'>" . $archivname . "</a>"; ?>

ToM