Backup einer 4.4 - so oder wie?

[folkfreund]

Ich denke, Du lädst es nur einmal runter, beim zweiten Kunden sollte es aus dem Cache kommen. Das macht es zumindest etwas besser.

Wenn denn in allen Fällen dieselbe PHP Version genutzt wird. Oder spielt das hier keine Rolle?

[Spooky]

Das spielt keine Rolle.

[mlweb]

Ich habe bisher auch noch kein PHP Script gefunden, was mir dies erledigt. Als .zip packen habe ich diverse Scripte gefunden, aber die helfen mir ja nicht weiter.

Ich stehe einfach auf dem Schlauch, vielleicht blockiere ich innerlich auch, weil mich das echt ärgert .....

Schau Dir mal die Erweiterung [BackupDB] an. Die bringt ein Script mit, mit dem Symlinks wieder hergestellt werden können. Ich habe das zwar selbst noch nicht getestet, aber es soll funktionieren.

https://github.com/do-while/contao-B...ontao-4.4-(DE)

[verkruemelt]

Da ein Backup ohne erfolgreiche Wiederherstellung wertlos ist (Schrödingers Backup), möchte ich kurz meine Erfahrung teilen.

Ausgangslage: Ich habe Contao 4.4.x auf einem ubuntu Server 17.10 installiert. Auf diesem wird täglich per cron die Datenbank und die Dateien

• web/.htaccess
• templates/
• system/config/
• files/
• app/config
• composer.*

als .tar.gz gesichert. Das neue System ist ein ubuntu Server 18.04 (beta). Beide Maschinen sind virtuell und ich habe SSH-Zugriff.

Auf diesem System habe ich die notwendigen Pakete (PHP, MariaDB, Composer etc.) installiert.
Anschließend habe ich die Konfiguration das Apache vom alten, auf das neue System kopiert.
Dann in MariaDB den gleichen Benutzer angelegt, entsprechende Rechte vergeben und die DB aus dem SQL-Dump im neuen System eingespielt.
Darauf habe ich via composer die Version 4.4 von Contao installiert und die Dateien aus der Sicherung per

rsync -a backup/ /var/www/<contao>

die oben angegebenen Dateien wiederhergestellt.
Sowohl mv, als auch cp verweigern das Überschreiben der vorhandenen Dateien.

Anschließend mit composer die Installation aktualisieren lassen:

composer update --no-plugins --no-scripts --optimize-autoloader

Dann auf der Installations-Webseite prüfen, ob auch alle Sym-Links korrekt erstellt wurden.
Nun die Startseite aufrufen und Contao läuft auf dem neuen System.

Die Vorgehensweise setzt SSH-Zugriff voraus und etwas Erfahrung in der Shell, von daher sicher nicht unbedingt für jeden geeignet, aber vielleicht als Anhaltspunkt zum Ablauf brauchbar.

[grashalm]

liebe community,

ich nutze contao 4.6.7 auf einem windows-system. der hoster (all-inkl.com) hostet meine seite vermutlich auf linux-servern. in meinem zugang habe ich keinen ssh-zugriff (gibt es erst bei doppelt so teuren paketen).
jetzt habe ich das bundle backupdb per contao-manager installiert (was problemlos geklappt hat) und als ich die datenbank sichern wollte, kam ein internal server error mit folgender meldung: "Error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 19338240 bytes)." was tun?, sprach zeus...
ich habe natürlich die option zur späteren reparatur der symlinks angehakt (weil das bei meinen bisherigen versuchen, sicherungen mittels ftp einzuspielen, genau der fehler war), aber er macht eben erst gar kein datenbank-backup.
ist das ein fehler, der aus irgendwelchen gründen nur bei mir auftaucht? oder ist der bekannt? gibt es abseits der sicherungsvariante mit backupdb mittlerweile noch einfachere methoden, backups nicht nur von der datenbank, sondern auch von den installationsdateien zu erstellen und wieder einzuspielen (ohne ssh-zugang)? wenn das backupdb-script funktionieren würde, könnte ich dann tatsächlich die installation mittels ftp sichern, wieder einspielen und die datenbank ebenfalls neu einspielen? würde das dann funktionieren / ausreichen?

vielen dank vorab für eure meinung...

grashalm

[Spooky]

In der Version 4.6.7 gibt es einen Fehler bzgl. der Symlink Generierung. Du musst auf Contao 4.6.8 aktualisieren.

Das hat aber nichts mit dem Out of memory error zu tun. Poste die geamte Fehlermeldung.

[grashalm]

hallo spooky,

das ist die komplette errormeldung, die im frontend unter der fetten überschrift "Internal Server Error" angezeigt wird:

Was ist das Problem?

Error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 19338240 bytes)

[Spooky]

Bei welcher Operation genau?

// du hast nur 64 MiB RAM zur Verfügung. Das ist generell sehr wenig. Erhöhre den verfügbaren Arbeitsspeicher auf 128 MiB zB.

[grashalm]

beim versuch, das mysql-backup von der funktion backupdb downzuloaden...

wo kann ich den arbeitsspeicher erhöhen? im backend unter einstellungen?

[Spooky]

Nein, das ist eine Einstellung der Server Umgebung (also beim Hoster). Je nach Hosting geht das über verschiedene Art und Weisen (php.ini, .htaccess, Administrationssystem, etc.).

[xchs]

Siehe auch die Anmerkungen im Contao Manager Wiki: https://github.com/contao/contao-manager/wiki/All-Inkl

[grashalm]

danke für den hinweis! habe gerade bei meinem hoster angerufen und der hat das limit in der .htaccess-datei hochgesetzt auf 128 MB.
dann funktionierte es aber immer noch nicht. dann habe ich das limit nochmal verdoppelt auf 256 MB, und jetzt geht es. danke spooky!

wenn ich jetzt meinen webspace löschen würde, und würde die installation mittels ftp wieder hochladen und anschließend die datenbank
mit der integrierten restore-funktion bezüglich der symlinks wieder einspielen und anschließend aktualisieren: würde das ausreichen, um
backend und frontend wieder ganz normal erreichen zu können, oder müsste ich dann noch zusätzliche schritte unternehmen, und wenn
ja, welche? muss auch der symfony-cache nochmal neu aufgebaut werden?

[grashalm]

danke für deinen hinweis, xchs.

das kann ich jetzt aufgrund des telefonates mit meinem hoster bestätigen: bei 256M scheint es zu funktionieren...

meine frage an euch im post 212 bleibt aber noch aktuell...

[mlweb]

Ich würde grundsätzlich nicht die ganze Installation per ftp kopieren, sondern im Prinzip so vorgehen wie hier beschrieben https://erdmann-freunde.de/logbuch/contao-4-4-umziehen/.
Um das Ganze zu automatisieren (Backup Dateien und DB) gibt es ein Script von @fiedsch https://github.com/fiedsch/contao-4-backup-script

[grashalm]

danke für deine ideen, mlweb. allerdings erscheint mir der bei erdmann-freunde beschriebene weg erheblich aufwändiger, als wenn ich einfach nur die dateien per ftp hochkopieren und die datenbank wieder einspielen müsste. wäre das denn theoretisch auch machbar, so wie von mir in post 212 nachgefragt, oder müsste ich dann zusätzlich noch etwas machen?

mir ist nicht so wichtig, dass es möglichst schnell geht, sondern dass ich möglichst wenig schritte unternehmen muss (zeit habe ich genug)...

ein automatisiertes script kann ich leider nicht nutzen, da ich weder eine konsole noch einen cron-job zur verfügung habe...

[mlweb]

Ich finde das prinzipiell nicht aufwendiger und es ist soweit ich weiß auch der empfohlene Weg (wegen der Symlinks).

Grundsätzlich sollte Dir das Script von [BackupDB] die Symlinks nach einem FTP-Upload reparieren. Getestet habe ich das allerdings noch nicht weil ich wie gesagt anders vorgehe.

[do_while]

beim versuch, das mysql-backup von der funktion backupdb downzuloaden...

wo kann ich den arbeitsspeicher erhöhen? im backend unter einstellungen?

Hast Du so schon den Speicher erhöht?
https://github.com/contao/contao-manager/wiki/All-Inkl

Eigentlich sollte das schon ausreichend sein.
Hast Du bei BackupDB in die Blacklist die nicht unbedingt notwendigen Tabellen eingetragen?
https://github.com/do-while/contao-B...C3%BCr-backups

[mlweb]

Speicher erhöht hat er schon. Das Backup hat jetzt auch funktioniert.

[grashalm]

Ja, Speicher ist erhöht. Der Download der Datenbank hat auch funktioniert, allerdings habe ich das Backup noch nicht wieder eingespielt. Werde ich morgen mal in Ruhe testen.
Und dann will ich morgen auch mal versuchen, die Vorgehensweise von Erdmann-Freunde umzusetzen. Vielleicht ist es ja wirklich einfacher, als es mir anfangs erschien.

@ do_while: Nein, die besagten Tabellen habe ich noch nicht in die Blacklist eingetragen. Kann ich aber morgen noch nachholen.

Ich werde berichten, ob und wie ich es hinbekommen habe.

[grashalm]

so, nach ein paar tagen auszeit habe ich mich wieder drangesetzt.

habe, wie in github beschrieben, die sicherung ohne die nicht unbedingt notwendigen dateien durchgeführt
und anschließend etliche verzeichnisse meiner installation vom webspace gelöscht, um sie anschließend per
ftp wieder hochzuladen. danach war mein frontend erwartungsgemäß noch nicht zu sehen...
dann habe ich die mit backup-db erstellte zip-datei entpackt und die restoreSymlinks.php-datei in das web-
verzeichnis meiner installation kopiert und aufgrufen.

danach erschien folgende fehlermeldung:



Warning: symlink(): No such file or directory in /www/htdocs/w007154e/contao-0/web/restoreSymlinks.php on line 51
Symlink failed: /www/htdocs/w007154e/contao-0/web/system/modules/mobile_menu/assets

Warning: symlink(): No such file or directory in /www/htdocs/w007154e/contao-0/web/restoreSymlinks.php on line 51
Symlink failed: /www/htdocs/w007154e/contao-0/web/system/themes
Program terminated with 23 errors, 23 new symlinks

PLEASE DELETE THE SCRIPT FROM THE DIRECTORY NOW!
CLEAR THE SYMFONY-CACHE, e.g. with Contao Manager


wobei es bei mir nicht 2 warnungen waren, sondern rund 25. der contao-manager ließ sich ab da leider nicht mehr
aufrufen. hätte ich die in der zip-datei enthaltenen dateien composer.json und composer.lock vorher noch in das root-
verzeichnis meiner installation kopieren müssen, oder konnte ich auch problemlos diese beiden dateien aus meiner ftp-
sicherung verwenden? hätte ich vorher schon oder noch den symfony-cache löschen müssen?

irgendwann ließ sich die seite wieder aufrufen (ich kann aber nicht mehr rekonstruieren, was ich dazu getan habe),
aber ohne die anzeige sämtlicher bild- und video-dateien meines files-ordners. möglicherweise waren auch alle weiteren
dateien im files-ordner davon betroffen (habe ich nicht geprüft).

das einspielen der sicherung hat also nicht ganz geklappt. leider weiß ich aber nicht, an welcher stelle was genau schief
gegangen ist, und wie ich das das nächste mal verhindern kann...

vielleicht könnt ihr mir hier nochmal helfen.


vielen dank im voraus,

grashalm

[folkfreund]

Hast du es denn inzwischen auch mal nach der Anleitung von Erdmann-Freunde versucht?
Ich finde dieses Vorgehen wirklich viel einfacher ...

[grashalm]

nein, noch nicht. will ich mir aber morgen oder übermorgen abend nochmal anschauen.
danach melde ich mich nochmal...

[grashalm]

habe noch eine nachfrage, bevor ich die tage mal versuche, den weg von erdmann-freunde für eine sicherung zu nutzen:

verstehe ich das richtig, dass man im grunde gar kein richtiges (vollständiges) backup anlegt, da man nur ein paar wenige
dateien und ordner braucht und dann contao im grunde immer komplett neu mithilfe des contao-managers installiert???
muss ich dann nicht auch jedesmal die ganzen erweiterungen wieder zusammensuchen und neu mitinstallieren (mal von den
manuell installierten erweiterungen abgesehen), oder werden die noch von meiner alten installation im neuen contao-manager
angezeigt und automatisch wieder mitinstalliert, bzw. aktualisiert? das ist mir noch nicht ganz klar...

vielleicht kann hier noch mal jemand meinen geist erhellen...

vielen dank für eure mühe,

grashalm

[fiedsch]

verstehe ich das richtig, dass man im grunde gar kein richtiges (vollständiges) backup anlegt, da man nur ein paar wenige
dateien und ordner braucht und dann contao im grunde immer komplett neu mithilfe des contao-managers installiert???

Im Prinzip ja. Du musst nur sichern, was nicht einfach wieder nachinstalliert werden kann.

Das wäre zu allererst natürlich mal die Datenbank.

muss ich dann nicht auch jedesmal die ganzen erweiterungen wieder zusammensuchen

Nein, den Du sicherst die composer.json und die composer.lock und da steht drin, welche Erweiterungen -- in welchen Versionen -- installiert waren. Mit dieser Information kann alles neu heruntergeladen und installiert werden.

[folkfreund]

... Mit dieser Information kann alles neu heruntergeladen und installiert werden.

Es sei denn du hast irgendwelche Sachen nicht über Composer/Contao Manager installiert, also z.B. alte 3.x Erweiterungen, die es (noch) nicht als Composer-Paket gibt.
Solche Sachen musst du genau wie angepasste Templates, den files-Ordner etc. selbst sichern.

[grashalm]

danke für deinen schnellen kommentar, fiedsch!

dann habe ich die anleitung quasi richtig interpretiert.
ja klar, ich muss die datenbank sichern und auch den files- und templates-ordner.

danke nochmal für den hinweis, dass ich auch die composer.lock- und die
composer.json-dateien sichern muss und darin die erweiterungen finde.

damit sollte ich das hinkriegen...


danke auch an dich, folkfreund!
ja, dass ich alte erweiterungen von hand sichern muss, war mir klar. das steht
ja auch in der beschreibung von erdmann-freunde...

trotzdem noch mal danke für die erwähnung!

[Webstylerin]

Ich arbeite bei Backups/Umzügen immer nach der Erdmann&Freunde-Anleitung, hat bisher alles funktioniert.

Für Backups habe ich mir eine Notiz angelegt, welche Ordner/Dateien gesichert werden müssen. Über die Liste bin ich mal irgendwo im Forum gestolpert.

app/
files/
templates/
composer.json
composer.lock
.env (vorhanden wenn Zugriff auf app_dev.php eingestellt)

system/config
web/.htaccess

system/modules (wenn Erweiterungen manuell installiert sind)

[fiedsch]

Es sei denn du hast irgendwelche Sachen nicht über Composer/Contao Manager installiert, also z.B. alte 3.x Erweiterungen, die es (noch) nicht als Composer-Paket gibt.
Solche Sachen musst du genau wie angepasste Templates, den files-Ordner etc. selbst sichern.

Darum habe ich auch geschrieben "Im Prinzip ja." (Radio Eriwan ;-)

Ich habe versucht alle Fälle abzudecken und das ganze in einem Skript zusammenzufassen: https://github.com/fiedsch/contao-4-backup-script

Die von @webstylerin in #227 genannte .env habe ich auch gleich in einem Ticket notiert. Man übersieht halt gerne Sachen, die man selbst nicht verwendet. Danke!

[Spooky]

Ich arbeite bei Backups/Umzügen immer nach der Erdmann&Freunde-Anleitung, hat bisher alles funktioniert.

Für Backups habe ich mir eine Notiz angelegt, welche Ordner/Dateien gesichert werden müssen. Über die Liste bin ich mal irgendwo im Forum gestolpert.

app/
files/
templates/
composer.json
composer.lock
.env (vorhanden wenn Zugriff auf app_dev.php eingestellt)

system/config
web/.htaccess

system/modules (wenn Erweiterungen manuell installiert sind)

I approve of this message.

Pro-tip: wenn man die localconfig Einträge statt dessen in der app/config/config.yml hinterlegt, also zB:

contao:
  localconfig:
    licenseAccepted: true
    installPassword: '$2y$10$8203498jlaf…'
    websiteTitle: 'My website'
    adminEmail: 'email@example.org'
    minifyMarkup: true
    # etc.

und auch keine manuell installierten Contao 3 Extensions verwendet, kann man sich den ganzen system/ Ordner sparen. Dann ist es nur mehr:

app/
files/
templates/
web/.htaccess
web/robots.txt
.env
composer.json
composer.lock

Hat auch den Vorteil (evt. ist es auch ein Nachteil ), dass die in der app/config/config.yml hinterlegten Einträge nicht über das Backend überschrieben werden können.

[grashalm]

ich danke euch allen für die zahlreichen hilfen!
danke auch an webstylerin für die tolle liste - die hat es mir sehr einfach gemacht!

aber von anfang an:

nachdem ich ein zweites mal versucht habe, meine installation mittels der zip-datei von backupdb wieder anzulegen, klappte es schließlich wieder fast, aber nicht ganz: zum schluss fehlte mein hintergundbild, der rahmen, und auch der conato-manager lies sich - wie schon beim ersten versuch - nach dem wiederanlegen der symlinks mittels des aufrufes von www.meine-url.tld/restoreSymlinks.php im web-verzeichnis, nicht mehr aufrufen. die vermeintliche fehlermeldung, die ich neulich gepostet habe,

Warning: symlink(): No such file or directory in /www/htdocs/w007154e/contao-0/web/restoreSymlinks.php on line 51
Symlink failed: /www/htdocs/w007154e/contao-0/web/system/modules/mobile_menu/assets

Warning: symlink(): No such file or directory in /www/htdocs/w007154e/contao-0/web/restoreSymlinks.php on line 51
Symlink failed: /www/htdocs/w007154e/contao-0/web/system/themes
Program terminated with 23 errors, 23 new symlinks

PLEASE DELETE THE SCRIPT FROM THE DIRECTORY NOW!
CLEAR THE SYMFONY-CACHE, e.g. with Contao Manager


wobei es bei mir nicht 2 warnungen waren, sondern rund 25. der contao-manager ließ sich ab da leider nicht mehr
aufrufen.

war wahrscheinlich gar keine. die warnungen werden vermutlich immer erscheinen, wenn restoreSymlinks.php aufgerufen wird. auch diesmal habe ich das skript nach der ausführung gelöscht, den symfony-cache aber mittels ftp aus var/cache/prod/ gelöscht (wobei viele dateien, nach dem löschen sofort wieder erschienen). auch danach lies sich der contao-manager nicht mehr öffnen, sodass ich die erweiterungen nicht mehr einspielen konnte (ungeklärt bleibt für mich dabei die frage, ob ich bereits vorher die dateien composer.json und composer.lock wieder in das projektverzeichnis hätte hochladen müssen...).

nach diesem zweiten erfolglosen versuch habe ich mich dann entschieden, die variante von erdmann-freunde auszuprobieren. diese dauert bei mir zwar ca. 100 min länger, weil ich meinen files-ordner ja erst löschen muss, da das projekt-verzeichnis ja wie beschrieben komplett leer sein muss, und mein files-ordner ist rund 7 GB groß. dauert halt ne weile, wenn ich den dann später wieder hochladen muss, aber es funktioniert zumindest!!!

wichtig zu erwähnen ist vielleicht noch folgendes:

1. 1. nach dem umbenennen der contao-manager.phar-datei in contao-manager.phar.php, habe ich auch die .htaccess-datei, die im web-ordner lag, wieder mit hochgeladen, weil bei mir darin die definition für den größeren arbeitsspeicher des servers enthalten ist. ansonsten scheitert das ganze wieder an zu geringem arbeitsspeicher.

1. 2. nachdem contao installiert wurde, habe ich sowohl die composer.json-datei, als auch die composer.lock-datei in das projektverzeichnis hochgeladen und dabei die beiden schon existierenden dateien gleichen namens überschrieben (unter punkt 3 bei erdmann-freunde ist nämlich nur die composer.json-datei erwähnt. lädt man die composer-lock.-datei nicht mit hoch, führt das vermutlich dazu, dass der contao-manager die entsprechenden erweiterungen an späterer stelle nicht mehr findet und man alles von hand nachinstallieren, bzw. sich zusammensuchen muss). von daher ist es ganz wichtig, bei ermann-freunde unter punkt 3 beide gesicherten composer-dateien auch wieder hochzuladen und die durch die neuinstallation von contao bereits existierenden composer.json- und composer.lock-dateien zu überschreiben!!!

1. 3. nach der aktualisierung der datenbank reichte es bei mir nicht aus, die symlinks neu zu erstellen, sondern ich musste auch den script-cache mit den css-dateien leeren. erst danach sah mein frontend wieder aus, wie gewohnt...

nochmals allen autorInnen herzlichen dank! vielleicht hilft ja auch mein beitrag anderen weiter...

grashalm

[do_while]

Hallo grashalm,

Deine Installation läuft jetzt?

Sonst wäre es interessant mit der restoreSymlinks.php noch etwas zu versuchen. In Zeile 51 werden die Symlinks in Contao angelegt (sollen jedenfalls). Das scheint bei Dir nicht zu funktionieren, die Frage ist warum. Wenn es Dir nichts ausmacht, könntest Du mir bitte mal die Datei zumailen (bitte an die info-Adresse bei softleister.de), dann würde ich mal nachsehen, ob die Generierung der Datei oder die Ausführung den Fehler verursacht.

Da beim Backupsystem eine andere Verzeichnisstruktur unterhalb Contao vorliegt als beim Zielsystem, muss ich den absoluten Pfad splitten und später wieder neu generieren, dabei könnten bei Dir vielleicht irgendwelche Dinge gestört haben. Ich bin gespannt, was das sein kann.

[grashalm]

hallo do_while,

ja installation läuft nach der anleitung von erdmann-freunde perfekt.
habe dir aber trotzdem mal meine php-datei geschickt...
vielleicht bekommst du was raus.

grüße, grashalm