BackupDB für Contao 4.4

Endlich ist die Contao-Erweiterung BackupDB für Contao 4.4 soweit fertig. Es war kein ganz einfacher Weg.
Durch die Hilfe von BugBuster und unserem Workshop vom Contao Stammtisch Berlin ist es nun gelungen.

Ich hoffe, alles läuft soweit korrekt und Ihr könnt Eure Datenbank-Backups wieder über das Backend machen.
Im Contao Manager installiert Ihr die Erweiterung als do-while/contao-backupdb-bundle.
https://packagist.org/packages/do-wh...ackupdb-bundle

Das Handbuch in Deutsch und Englisch findet Ihr im Wiki bei GitHub
https://github.com/do-while/contao-BackupDB

Problem melden könnt Ihr hier:
https://github.com/do-while/contao-BackupDB/issues

Hallo Hagen

Zuerst herzlichen Dank für dein Engagement. Wobei ich wahrscheinlich vielen anderen auch mal danken sollte. Ihr ermöglicht mir mit eurer Arbeit zwar nicht meinen Lebensunterhalt, aber ein mich faszinierendes Hobby. Und eine berufliche Horizonterweiterung.

Ich habe die Erweiterung mit dem Manager installiert - soweit alles ok. In der Contaoversion 3 habe folgenden serverseitigen Cronjob engerichtet:

Code:

---

cd /home/xxxxx/www/xxxxxxxxxxx.ch/system/modules/BackupDB/ ; /usr/local/bin/php -f /home/xxxxx/www/xxxxxxxxxx.ch/system/modules/BackupDB/AutoBackupDB.php

---

Welche Datei muss ich in der Version 4.4 ansprechen? Geht das überhaupt in der Version 4?

Der Pfad ist ein wenig anders, weil es jetzt über eine Symfony-Route läuft.
Wie es geht, steht in der Doku:
https://github.com/do-while/contao-B...tisches-backup

Hallo und vielen Dank, vor allem für die restoreSymlinks.php – Das ist eine große Hilfe, wenn man eine lokale Installation auf einen Server umziehen möchte, bei dem weder der Contao Manager noch der Composer an sich unterstützt wird!

Aber eine kleine Bitte: Wäre es möglich, das Script dahingehend zu ändern, dass man die Pfade des Stammverzeichnisses für eben einen solchen Umzug anpassen kann, bevor das Script ausgeführt wird?

Momentan ist der Array ja in der Art aufgebaut, wenn man z.B. seine lokale XAMPP-Installation sichert (Beispiel-Auszug, Pfad anonymisiert):

$arrSymlinks = unserialize( ... {s:4:"link";s:25:"system\modules/beispielmodul";s:6:"target";s:56:"C:\xampp\htdocs\ contao\vendor\beispielmodul";}... }

Problem 1: Wenn ich von Lokal auf den Server umziehe, ändert sich der Pfad ja von C:\xampp... in /var/www/... - das sollte anpassbar/änderbar sein

Daraus ergibt sich dann

Problem 2: Die Zahlen geben ja die Länge der folgenden Textstrings an. In meinem Beispiel stimmt das schon nicht mehr, weil ich den Pfad für das Beispiel im öffentlichen Forum abgeändert habe. Die Länge sollte automatisch aus dem neuen Pfad berechnet werden.

Und Problem 3, falls nicht schon aufgefallen: Slashes und Backslashes sollten korrigiert werden, also alle \ in / umwandeln...

Danach kann man bei einem Umzug einfach die vorhandenen Daten per FTP übertragen, den Cache löschen und das Script für die Symlinks ausführen, danach sollte man auch das Install-Tool und das Backend problemlos ausführen können.

Bei einem Test mit manueller Anpassung der ganzen Pfade (und händischer Korrektur der ganzen Zahlen/Stringlängen) in der restoreSymlinks.php hat es bei mir funktioniert! Würde mir daher nur noch wünschen, dass man diese Anpassung nicht manuell machen muss :-)

Nochmal vielen Dank!

Hallo contaotester,

die Zahlen darin sind die Längen, die sich die PHP-Funktion seralize dort merkt. Wäre die Länge automatisch ermittelbar, dann würde die Funktion sicherlich anders speichern.

Mit \ und / hast Du sicherlich recht, das könnte zu Problemen führen. Linux ist da oft sehr tolerant, aber man muss auch an den Rückweg (Linux nach Windows) denken. Ich werde dazu ein paar Tests machen und das Script dahingehend anpassen. Ich erstelle dazu ein Ticket.

Mit den Pfaden ist das so eine Sache. Offenbar sind in Deiner Installation, die Du gesichert hast, die Symlinks falsch gesetzt. Ich habe bisher in Contao nur relative Symlinks gefunden, damit man nämlich portieren kann. Kann es sein, dass Du die absoluten Symlinks mal manuell gesetzt hast?

In meinem erstellten Script sieht es so aus:

Code:

---

$arrSymlinks = unserialize('a:37:{i:0;a:2:{s:4:"link";s:11:"system/logs";s:6:"target";s:11:"../var/logs";}i:1;...

---

und das wäre dann so portierbar, wie Du es geschrieben hast.

Unter Windows werden wegen eines Bugs in PHP nur absolute Symlinks generiert.

Generell ist es aber eigentlich nicht notwendig die Symlinks gesondert zu sichern.

Das macht es aber einfacher, wenn Contao nicht mehr will und der Manager auch nicht aufgerufen werden kann.
Jetzt wäre die Kommandozeile gefragt - oder alternativ die gesicherten Symlinks :)

Ein Ticket ist erstellt:
https://github.com/do-while/contao-BackupDB/issues/7

Auf Kommandozeile wäre das alles kein Problem, da habe ich einfach mal alles unterhalb web/ gelöscht und contao install aufgerufen, danach war alles wieder ok.

Dasselbe könnte ja auch BackupDB machen. Was genau passiert bei einem Restore eigentlich momentan?

Zitat:

---

Zitat von Spooky

Dasselbe könnte ja auch BackupDB machen. Was genau passiert bei einem Restore eigentlich momentan?

---

Eigentlich ist es ein Backup-Programm, deshalb kein Datenbank-Restore. Aber es sind ein paar hilfreiche Dateien dabei, unter anderem auch ein Script zur Wiederherstellung der Symlinks, denn im ZIP sind keine Symlinks drin, oder es werden Verzeichnisse daraus gemacht.

Beim Backup werden einfach alle Symlinks herausgesucht und im Script gespeichert. Bei der Wiederherstellung einer Installation kann man mit dem Script die Symlinks korrigieren, dabei werden die PHP-Befehle zum Anlegen genutzt. Wenn Symlinks vorhanden sind, passiert nichts.
Aus dem Script ein Kommandozeilenkommando aufrufen ist sicherlich nicht bei allen Providern möglich. Das möchte ich mir ersparen.

Nein ich meinte dein Script könnte ja genau so gut die entsprechenden Funktionen von Contao bzw. Symfony aufrufen (allerdings fehlt da noch eine Möglichkeit vom composer-plugin).

Falls es hier Verwirrungen gab: Ich habe Contao 4.4 auf einem Windows10 Rechner mit XAMPP lokal installiert und soweit fertig eingerichtet. Dort kann ich auch mit dem Composer Erweiterungen laden usw. Wie bereits korrekt angemerkt, werden die Symlinks unter Windows absolut angelegt.

Bei dem Webspace (Shared Hosting) funktioniert der ContaoManager (beta8) noch nicht und der Komandozeilen-Zugriff mit Putty und SSH ist nicht mein Ding, auch wenn ich es eventuell hinbekommen würde.

Lösung:
- Die Datenbank auf dem Zielsystem einrichten (SQL aus dem Backup bei PHPmyAdmin importieren)
- Die Dateien und Ordner (der Sicherung oder lokalen Installation) per FTP übertragen.
- Ggf. absolut erstellte Symlinks per FTP auf dem Server löschen (bei meinem Upload von Windows mit FileZilla auf den Server wurden die absoluten Symlinks nicht übertragen, dieser Schritt war also nicht einmal nötig).
- Das TEMP-Verzeichnis auf dem Server leeren (temporäre Dateien der Ursprungs-Installation löschen)
- Mit dem restoreSymlinks.php aus BackupDB die Symlinks auf dem Webspace neu erzeugen lassen
- Das Install-Tool aufrufen, um ggf. die Datenbanken-Verbindungsdaten zu aktualisieren
- Im Backend einloggen und loslegen/weiterarbeiten

Dank des restoreSymlinks.php ist bei dieser Variante für die Einrichtung auf dem finalen Webspace weder Composer noch der Manager noch die Komandozeile nötig. Damit kann man Contao 4.4 auch bei günstigen SharedHosting-Paketen zum Laufen bekommen. Updates oder die Installation neuer Erweiterungen funktioniert damit natürlich nicht, das müsste auf dem Entwicklungssystem gemacht werden und dann wieder per FTP hochgeladen werden...

Nachteil/Voraussetzung ist natürlich, dass man Contao vor der Übertragung auf den Webspace auf einem anderen System vorbereiten/einrichten muss, wo dann der Composer funktionieren sollte. Das Grundproblem, dass die Systemvoraussetzungen mit Composer/dem Manager extrem gestiegen sind, wird damit natürlich nicht behoben. Bei günstigen Shared Hosting Webpaketen sind 1,5 GB Ram und lange Scriptlaufzeiten für den Composer kaum zu finden und das wird sich wahrscheinlich auch nicht schnell ändern...

Der Nachteil von restoreSymlinks.php ist momentan bei dieser Nutzung nur die erforderliche händische Anpassung der Pfade, manuelles Zählen der Stringlängen und Anpassung der Zahlenwerte, sowie Korrektur der Slashes/Backslashes... Abgesehen davon ist das ein sehr tolles Hilfsmittel und sollte eigentlich fester Bestandteil von Contao sein, um das System umzuziehen! :-) Contao sollte wieder einfacher zu Installieren/Einrichten/Übertragen/Sichern werden und dieses kleine Script ist aus meiner Sicht ein sehr guter Schritt in die richtige Richtung...

Ich habe mir ein Ticket erstellt, um auch bei absoluten Links ohne Änderungen einen Umzug zu ermöglichen.
https://github.com/do-while/contao-BackupDB/issues/7

Ich komme aber nicht sofort dazu, das umzusetzen, ich muss nach einigen Tagen für BackupDB jetzt erstmal wieder an den Kundenaufträgen weiterarbeiten.

Die ersten 100 Installationen vom BackupDB-Bundle sind ausgeliefert!
https://packagist.org/packages/do-wh...ackupdb-bundle

101. Rockt. Danke, Hagen.

Zitat:

---

Zitat von contaotester

Problem 1: Wenn ich von Lokal auf den Server umziehe, ändert sich der Pfad ja von C:\xampp... in /var/www/... - das sollte anpassbar/änderbar sein
Problem 2: Die Zahlen geben ja die Länge der folgenden Textstrings an. In meinem Beispiel stimmt das schon nicht mehr, weil ich den Pfad für das Beispiel im öffentlichen Forum abgeändert habe. Die Länge sollte automatisch aus dem neuen Pfad berechnet werden.

Und Problem 3, falls nicht schon aufgefallen: Slashes und Backslashes sollten korrigiert werden, also alle \ in / umwandeln...

---

Neue Version 1.1.0 löst das Problem!

Die Symlinks werden jetzt so übertragen, dass unter Windows wieder absolute Links gesetzt werden, unter Liniux werden es relative Links.
Mit dem Script kann man jetzt auch zwischen Linux und Windows hin und her übertragen (wird konvertiert).

Das klingt doch schon mal sehr gut :).

Heute ist die 500er-Installgrenze gefallen, Contao 4.4 ist im Kommen! (zusammen mit BackupDB)
https://community.contao.org/de/atta...1&d=1504958195

Hallo, zunächst noch vielen Dank für die Änderung der restoreSymlinks.php, das klappt jetzt wunderbar!

Dann andere Frage bzw. ein Vorschlag: Wäre es nicht sinnvoll, auch die "allgemeinen Einstellungen" in die Sicherung mit aufzunehmen?

Es ist mir beim Kopieren von Daten in eine neue Installation aufgefallen, dass diese Angaben nicht in der Datenbank-Sicherung enthalten sind...

Wie kann ich autobackup direkt per php-cli aufrufen ohne das ich über die URL muss?

Finde die Crons über wget oder curl nicht so schön

z. B. mit

Code:

---

mysqldump -u Datenbankname . ' -pMeinPasswort --allow-keywords --add-drop-table --complete-insert --quote-names Datenbankname > sicherung.sql

---

Wenn Du sowieso auf Kommandoebene bist, wozu dann BackupDB?

Welchen relativen Pfad muss ich angeben, um BackupDB mit contao-cron-bundle unter Contao 4.4 zu verwenden?

Unter Contao 3 war es ja relativ einfach mit

Code:

---

system/modules/BackupDB/AutoBackupDB.php

---

VG,
Gregor

ungetestet:

Code:

---

BackupDB/autobackup

---

das ist eine Route die den Controller für das Backup aufruft, aber contao-BackupDB ist wohl noch nicht ganz angepasst wenn ich das richtig sehe:
do-while/contao-BackupDB/issues/12

Nachtrag: Kann so nicht gehen. Muss ich mit Hagen mal besprechen.

Ich hatte nicht mitbekommen, dass Glen seine Cron-Erweiterung für Contao 4 jetzt veröffentlicht hat.
Ich muss mir das mal installieren und austesten, wie ich die Verbindung machen kann.

Wollte ich dir auf dem Stammtisch verkünden, aber der ist ja erst nächste Woche.

Das mit BackupDB/autobackup hatte ich bereits probiert.
Hier kommt dann immer:

Code:

---

Warning: include(/www/htdocs/xxx/BackupDB/autobackup): failed to open stream: No such file or directory in /www/htdocs/xxx/vendor/bugbuster/contao-cron-bundle/src/Resources/contao/controllers/ContaoBackendController.php on line 124

Warning: include(/www/htdocs/xxx/BackupDB/autobackup): failed to open stream: No such file or directory in /www/htdocs/xxx/vendor/bugbuster/contao-cron-bundle/src/Resources/contao/controllers/ContaoBackendController.php on line 124

Warning: include(): Failed opening '/www/htdocs/xxx/BackupDB/autobackup' for inclusion (include_path='.:/usr/share/php:..') in /www/htdocs/xxx/vendor/bugbuster/contao-cron-bundle/src/Resources/contao/controllers/ContaoBackendController.php on line 124
BackupDB
BackupDB/autobackup
[20-Feb-2018 08:13:57] Running scheduler job manually
::Warning: include(/www/htdocs/xxx/BackupDB/autobackup): failed to open stream: No such file or directory in /www/htdocs/xxx/vendor/bugbuster/contao-cron-bundle/src/Resources/contao/controllers/ContaoBackendController.php on line 124

Warning: include(/www/htdocs/xxx/BackupDB/autobackup): failed to open stream: No such file or directory in /www/htdocs/xxx/vendor/bugbuster/contao-cron-bundle/src/Resources/contao/controllers/ContaoBackendController.php on line 124

Warning: include(): Failed opening '/www/htdocs/xxx/BackupDB/autobackup' for inclusion (include_path='.:/usr/share/php:..') in /www/htdocs/xxx/vendor/bugbuster/contao-cron-bundle/src/Resources/contao/controllers/ContaoBackendController.php on line 124
[20-Feb-2018 08:13:57] Manually scheduler job complete

---

Ja, das kann nicht gehen. Von "außen" also zum Beispiel mit einem echtem Cron könnte man den so aufrufen.
Aber meine Cron Erweiterung kann das noch nicht. Die will derzeit eine Datei, keine Route haben.
Ich bin dabei zu überlegen ob und wie ich das möglich mache.

Nachtrag: ist mittlerweile möglich.

Hallo,
Ich habe Contao 4.4 und Autobackup installiert. Zusätzlichbdie Erweiterung cron von do_while. Einen Cronjob habe ich auch eingerichtet, hier der Pfad: vendor/do-while/contao-backupdb-bundle/src/Resources/contao/modules/ModuleBackupDB.php

Früher unter Contao 3.5 waren die gesicherten SQL-Files unter cto_layout gespeichert. Jetzt kann ich diese nicht mehr finden. Ich hoffe auf Eure Hilfe. Herzlichen Dank im Voraus.

Das geht bei Contao 4 nicht so!

Der Aufruf vom AutoBackup erfolgt über eine Route
http://www.meineDomain.tld/BackupDB/autobackup

Siehe Dokumentation:
https://github.com/do-while/contao-B...tisches-backup

Die gesicherten SQL-Dateien befinden sich, wie auch früher, in der Dateiverwaltung in einem unveröffentlichten Verzeichnis files/AutoBackupDB/
Nur gesicherte Website-Templates werden in templates/ gespeichert, das ist aber kein Backup der Datenbank!

Hallo, vielen herzlichen Dank und Gratulation zur gelungenen Umsetzung.

Ich habe aktuell das Problem mit dem Export bzw. Import von Fremdtabellen.
Ich nutze bei einer Webseite den Contao Catalog Manager und habe Tabellen mit dem Prefix ctlg_ angelegt.
In den Contao Einstellungen habe ich unter "Datentabellen im Website-Template" die Prefixe tl_, ctlg_ eingetragen. Das Erstellen des Website Templates funktioniert auch ohne Probleme.

Nur der Import funktioniert nicht :-(

Im Install Tool erhalte ich die Meldung "Der Import konnte nicht abgeschlossen werden! Ist die Datenbank aktuell und die Template-Datei kompatibel mit Ihrer Contao-Version?".

Wenn ich den Prefix ctlg_ in den Einstellungen entferne... also nur die tl_ Tabellen als Template exportiere, klappt der Import im Install Tool Problemlos. Es scheint also an dem fremden Prefix zu liegen.
Hat jemand eine Idee?

Hallo dirksche,

in einem Website-Template sind nur die Datensätze enthalten, aber nicht die Datenbankstruktur. Wenn nicht zuvor alle Erweiterungen wieder so installiert werden, wie vor dem Backup, wirft das natürlich Fehler, weil das Installtool die Datensätze nicht eintragen kann.

In dem Template-Verzeichnis müsste sich aber auch eine Datei vom Typ .structure befinden, hier sind nur die Tabellendefinitionen drin.
Wenn Du hieraus manuell die ctlg_ - Definition herausnimmst und in der Datenbank anlegst, sollte danach die Templateinstallation funktionieren.

Hi Hagen,

vielen Dank für die Antwort. Ja, das scheint zu funktionieren. Ich arbeite mit Git und pushe im Grunde das Template in ein Repositiory. Das manuelle Löschen ist natürlich etwas umständlich.
Gibt es vielleicht noch eine alternative ?

Grüße,
Dirk

In dem Backup von BackupDB sind alle Tabellendefinitionen und alle Datensätze drin, das ist aber wiederum nicht die Struktur, die das Installtool verarbeitet.
Eine automatisierte Lösung fällt mir da im Moment nicht ein.

Schonmal so probiert?

https://community.contao.org/de/show...l=1#post439193

Hab es installiert. Das lief soweit durch, nur wenn ich nun ein Backup manuell im Backend starten will gibt es einen 500er Error. Das Logfile sagt, es fehlt Speicher.

Zitat:

---

Error: Allowed memory size of 551550976 bytes exhausted (tried to allocate 20480 bytes) at ...

---

Heißt das meine Datenbank ist zu groß? Ich denke, noch mehr Speicher kann ich nicht zuweisen oder wie hoch kann ich das bei All-Inkl setzen?

In den Contao-Einstellungen kannst Du eine BlackList setzen, siehe Anleitung unter "Blacklist für Backups"
Damit schließt Du oft große Datenmengen vom Backup aus, die Du aber im Notfall nicht benötigst, da diese Tabellen (z.B. Suchindex) nach dem Restore leicht neu erstellt werden können.

Mit der Blacklist und den dort angegebenen Tabellen reduzierst Du Deine Daten und wahrscheinlich wird das Backup dann durchlaufen.

Das war es, danke! Noch probiere ich herum, aber wenns läuft, ist das eine tolle Erweiterung. Danke!

Hi do-while,

erst mal vielen Dank für Deine Arbeit und die super Erweiterung.

Ich beschäftige mich aktuell mit der Möglichkeit, eine C 4.4-Installation automatisch zu sichern. Bis jetzt habe ich mittels DBbachup immer manuell gesichert. Nun möchte ich aber eine komplette Installationssicherung durchführen.
Du hast geschrieben

Zitat:

---

Das Datenbank-Backup mit den Zusatzinformationen zusammen mit einem gespeicherten FTP-Backup sollten ausreichen, um eine laufende Installation neu aufzusetzen.

---

Leider bin ich noch nicht php-affin, aber wenn ich das richtig verstehe, dann kann eine C 4.4-Installation mittels eines Datenbank-Backups (manuell oder automatisch) + FTP-Backup wiederhergestellt werden. Per FTP sichere ich standardmäßig die Ordner app/; files/; templates/; system/config/; web/.htaccess und die Dateien composer.json und composer.lock. Die Datei .env ( nur bei Nutzung von app_dev.php) und system/modules (nur bei manuell installierten Erweiterungen).

Mit diesem Vorgehen habe ich dann alle relevanten Dateien und Ordner gesichert, die für einen Notfall zur Wiederherstellung der gesamten C 4.4-Installation notwendig sind oder habe ich was übersehen?

Gruß
Schneetiger

Hallo Schneetiger,

letztlich musst Du wissen, ob Du gegenüber dem Standard noch an anderen Stellen Änderungen gemacht hast.
Beispielsweise manuell eingespielte Contao3-Erweiterungen solltest Du auch sichern, da in irgendwann das ER2 abgeschaltet wird.

Ich würde mir in einer Testinstallation mal alles aus den Sicherungen zusammentragen und mal probieren, ob man damit eine laufende Kopie erstellen kann.
Dann kannst Du sicher sein.

Ich würd jetzt gerne erstmalig das Sichern per Cronjob nutzen, aber der Kunde hat nur einen einzigen und der ist schon belegt... hat Contao Cronjobs, an die ich mich irgendwie dranhängen kann?

Du könntest dieses Bundle verwenden: https://packagist.org/packages/bugbu...ao-cron-bundle

Zitat:

---

Zitat von k-webdesign

aber der Kunde hat nur einen einzigen und der ist schon belegt...

---

Könntest Du diesen einen umbauen? So in der Art:

• der eine cron-jon ruft (z.B.) cron_master.sh auf
• in cron_master.sh werden der Reihe nach die einzelnen wirklichen Jobs aufgerufen

Nachteil natürlich gegenüber mehreren individuellen cron jobs: sie werden alle zur gleichen Zeit und gleich oft aufgerufen.

Edit: fix typos

Danke, dann geht das nicht, jedenfalls nicht ohne den Webspace zuzumüllen. Der eine Import muss nämlich zwingend alle 30 oder maximal 60 Minuten stattfinden.

Das Bundle ist eine richtig coole Idee, die Seite hat allerdings zu wenig Traffic, als dass ich damit ein tägliches Auslösen um 12 und 15 Uhr garantieren kann. Danke für eure Ideen :cool: Ich werd mal schauen, dass der Hoster weitere Cronjobs bereitstellt, anders wird sich das nicht lösen lassen.

Zitat:

---

Zitat von k-webdesign

Das Bundle ist eine richtig coole Idee, die Seite hat allerdings zu wenig Traffic, als dass ich damit ein tägliches Auslösen um 12 und 15 Uhr garantieren kann.

---

Hmm, daran sollte es ja nicht scheitern. Für solche Dinge ist mein alter Uberspace praktisch, damit habe ich jahrelang zuverlässig die Cronjobs von Dutzenden Contao-Kundeninstallationen getriggert, die keinen Cronjob mehr auf ihrem Webspace zur Verfügung hatten. ;)

https://cron-job.org ist ebenfalls kostenlos

Ich hab leider noch nie einen Cronjob eingerichtet.

Aktuell versuche ich das bei Hetzner
Wie kann ich den Pfad http://www.meineDomain.tld/BackupDB/autobackup eintragen?

Da gibt es bei Hetzner sicherlich eine FAQ oder ein Tutorial dazu.
Hat ja erstmal so nichts mit BackupDB zu tun.

Moin.
Ich habe das Bundle do-while/contao-backupdb-bundle Version 1.4.0 in einer recht frischen Contao 4.4.42 Installation laufen, aber wenn ich auf einen der beiden Buttons zur Erstellung eines Backups oder Webtemplates klicke, dann bekomme ich eine Error 500 Fehlerseite. Im var/logs/pord-**.log steht nichts dazu. Auf die Webserver Logfiles habe ich leider keinen Zugriff. Wie kann ich feststellen, was da schief läuft? Oder hat sonst jemand dieses Problem schon mal gehabt?
Sonst läuft eigentlich alles rund.

Mir ist der Fehler nicht bekannt.
Ich habe selbst die Erweiterung bei 4.4.43 im Einsatz und bekomme dort diesen Fehler nicht.

Wenn im Log nichts steht, ist es natürlich schwierig, dazu etwas zu sagen.

Installation hast Du über den Contao-Manager gemacht?
Ansonsten vielleicht noch einmal den Cache löschen und noch einmal probieren.

Zitat:

---

Zitat von amimoto

Auf die Webserver Logfiles habe ich leider keinen Zugriff.

---

Du könntest bei Deinem Hoster nachfragen, ob es eventuell möglich wäre, die relevanten Einträge aus dem error_log zu bekommen.

Zitat:

---

Zitat von do_while

Installation hast Du über den Contao-Manager gemacht?
Ansonsten vielleicht noch einmal den Cache löschen und noch einmal probieren.

---

Installation über Contao Manager.
Prod.-Cache erneuert, Paket aktualisiert, Paket de- und wieder neu installiert, alles probiert - Fehler bleibt.
Kann es daran liegen, daß da noch PHP 5.6 läuft?? Ansonsten läuft das CMS eigentlich problemlos.

Das ist ja komisch.
Dann brauche ich weitere Informationen zu dem 500er Fehler.

Hast Du mal beim Support gefragt, ob die Dir einen Auszug aus dem Server-Fehlerlog zur Verfügung stellen kann?
Am besten fragst Du an mit einer Uhrzeit, zu der Du das ausprobiert hast, dann muss nicht so lange gesucht werden.

Ich selbst habe kein 4.4 auf PHP 5.6 laufen, kann mir aber nicht vorstellen, dass es am PHP liegt.
Die BackupDB-Routinen stammen weitestgehend noch aus BackupDB für Contao 2 und 3.

Wie geht man genau vor, um die Umgebung mit diesem Backup inkl. der FTP-Daten Wiederherzustellen? Ist das irgendwo beschrieben? Denn der Contao Manager installiert ja immer die aktuellste Version, die man aber nicht zwingend im Einsatz hatte. Sicher muss man die composer.json kopieren, aber zu welchem Zeitpunkt macht man das?

Zitat:

---

Zitat von Shania

Sicher muss man die composer.json kopieren, aber zu welchem Zeitpunkt macht man das?

---

Damit Du genau den zuvor installierten Stand wieder herstellen kannst benötigst Du die composer.lock und machst dann

Code:

---

composer install

---

(im Manager gibt es dazu auch einen Menüpunkt, ich weiß nur nicht auswendig, wie der heißt).

Wann: Zum Zeitpunkt des Backups. Ob vor oder nach Datenbankdump ist egal, denn es sollte sich in dieser "Sekunde" nichts am System ändern, die Dateien also gleich bleiben.

Wenn Du in den Einstellungen den Haken "Backup mit Restoreinfos komprimieren" setzt, werden automatisch die wichtigen Dateien, wie composer.json und composer.lock mit ins Backup geschrieben (wird dann eine ZIP-Datei).

FTP-Daten sind nicht im Backup von BackupDB enthalten, die musst Du dann extra sichern!

@do_while: Ja, das hatte ich verstanden. Diese Files sicherere ich mit und extra nochmal files und templates. Ich frage nach dem Weg aus dem Backup wieder eine laufende Umgebung zu erstellen, die auch die gleichen Versionsstände der Software hat. Ist das noch nirgends beschrieben? Eine Schritt für Schritt Anleitung wäre für mich wohl am besten, denn um einen Menuepunkt im Manager zu wählen, muss dieser ja erst einmal laufen. Wenn eine Rücksicherung auf diese Weise nur funktioniert, indem ich den SSH Zugang nutze, dann sichere ich lieber die komplette Umgebung.

Sorry, für euch mag sonnenklar sein, wie das geht, aber ich habe bisher nur komplette Umgebungen rückgesichert. Das klappt auch prima.

Zitat:

---

Zitat von amimoto

Installation über Contao Manager.
Prod.-Cache erneuert, Paket aktualisiert, Paket de- und wieder neu installiert, alles probiert - Fehler bleibt.
Kann es daran liegen, daß da noch PHP 5.6 läuft?? Ansonsten läuft das CMS eigentlich problemlos.

---

Mein Problem hat sich nach einem PHP Update erledigt!