Backup einer 4.4 - so oder wie?

Durch die Symlinks und die große Anzahl Dateien macht ein Backup über (S)FTP / ZIP (windows) nicht wirklich Sinn.
Die Symlinks bleiben nicht erhalten bzw. werden in "echte" Dateien umgewandelt.

Spielt man so ein Backup wieder ein, meckert Symfony, dass die Symlinks nicht mehr angelegt werden können.

Ich will hier mal Eure Ideen hören und sammeln, vorab mal zwei von mir, auf Linux bezogen. (noch nicht getestet)

1. Komplett mit tar
   
   1. Ich lösche var/cache/prod und var/log/* , eventuell auch contao-manager/logs/*
   2. alternativ mittels "--exclude .." jeweils ausschließen bei nachfolgender Aktion
   3. das gesamte Installationsverzeichnis wird mit tar gepackt, dabei bleiben die Symlinks erhalten.
   4. Nachteil: das wird relativ groß
2. Teilweise mit tar
   
   1. es wird nur files/, templates/, app/config/ web/.htaccess sowie composer.json und composer.lock mit tar gepackt
   2. Vorteil: Archiv nicht ganz so groß, je nach Umfang in files/
   3. Nachteil: Restore bedarf nach dem Auspacken ein "composer install --no-dev --optimize-autoloader" Aufruf, und natürlich composer selbst, auf dem Server über Kommandozeile

Ach ja, für ein vollständiges Backup natürlich Backup der Datenbank nicht vergessen.


Nachtrag: Richtiger Hinweis von Spooky: bei Methode 2 eventuell noch system/modules/ beachten, siehe #5

Nachtrag: Korrekturen und Ergänzungen eingebaut. Hatte ich Teilweise auch im Kopf (--no-dev) aber hier nicht erwähnt.

Nachtrag: Generell mit Deployment Tools arbeiten, siehe auch hier, habe ich mal hier weggelassen. Mit Magallanes (magephp) habe ich bei 4.0/1 auch schon mal experiementiert nachdem das mal in einem Contao Camp glaub ich erwähnt wurde.

Wer "tar" nicht kennt: http://wiki.cbeier.net/linux/tar.gz_packen

Weitere Idee / Konzepte? Dann her damit, ich würde die hier oben dann drankleben als Sammlung.

Sprechen wir über ein Backup welches ohne große "Arbeit" eingespielt werden kann, oder von einem Backup woraus man seine Installation mit ein paar Zeilen wiederherstellen kann?

Finde Variante 2 definitiv am einfachsten als "Poweruser".
Denke aber das diese Variante nicht allen zusagt :P

Ich gehe mal von einem produktiven System aus - somit würde ich wie auch hier beschrieben
http://symfony.com/doc/current/deployment.html
beim Wiederherstellen:

Code:

---

composer install --no-dev --optimize-autoloader

---

Zitat:

---

The --optimize-autoloader flag improves Composer's autoloader performance significantly by building a "class map". The --no-dev flag ensures that development packages are not installed in the production environment.

---

Kann ich vollständig bestätigen.

@Methode 2 - warum löscht Du etwas, was Du eh nicht packst und mitnimmst? Vielleicht habe ich dort auch etwas falsch verstanden...

Ich packe mir alles wichtige inklusive db ein: d.h. alles ausser var, cache und vendor

Hmm, ja, muss man alles erst mal testen. Mit tar mache ich das bisher bei meinen 3.5 Installationen (Variante 1, natürlich gzip komprimiert). Wenn das weiterhin inklusive Symlinks so funktioniert, werde ich das wohl auch weiterhin so machen. Ist einfach am bequemsten für mich. Wobei ich das Backup dann online auf einen anderen Webspace verschiebe mit allen Vor- und Nachteilen. Nur das Backup vom Auslieferungszustand sichere ich dann nochmal zusätzlich lokal.
Vorteile: Geht sehr schnell, weil die Verbindung zwischen den Webservern wesentlich schneller ist als meine lokale Verbindung zu den Webservern. Auch das Restore geht sehr schnell.
Nachteil: Frisst Webspace.

Zwischen zwei Servern kann man eventuell alternativ rsync einsetzen, wenn man mehrere Entwicklungsstände sichern will. Also Installation auf den Zielserver syncen, dort Backup mit tar. Zeitlich dürfte das sogar eher langsamer sein, aber Traffic auf den Servern einsparen, falls man da Limits hat (oder trotz "unlimited traffic" irgendwann Ärger bekommt :D )

Ich würde nur das "teilweise" Backup machen, alles andere hat meiner Meinung nach keinen Sinn. Brauchen tut man (bei der Managed Edition) im Endeffekt eigentlich nur

• app/
• files/
• templates/
• system/modules/ [1]
• web/.htaccess
• composer.json
• composer.lock
• .env

[1] Schwierig wird es beim system/modules/ Ordner. Dort kann sich ein Mix aus Symlinks und regulären Ordnern befinden, wenn man manuell installierte Extensions verwendet. Daher müsste man also den system/modules/ Ordner so sichern, dass eben alle Symlinks ignoriert werden. (Related: https://github.com/contao-community-...ugin/issues/69)

Im web/ Ordner könnten sich auch zusätzliche Dateien befinden - aber nur wenn man selbst dort welche angelegt hat. Die muss man natürlich dann beachten.

Die .htaccess Datei aus dem web/ Verzeichnis sollte ebenfalls mit gesichert werden falls dort Anpassungen gemacht werden.

Guten Morgen zusammen,

irgendwie lese ich aus dem Thread hier, dass es scheinbar noch gar keinen ordentlichen "Backupplan" für Contao 4.4 gibt. Ich hoffe und denke dass ich mich da täusche, da ich derzeit sowieso Gefahr laufe, den Überblick über Contao 4.4 zu verlieren.

Wird denn eine Backupmöglichkeit offiziell empfohlen oder wird so etwas im Contao manager implementiert damit auch "nicht Poweruser" ein "sicheres" Backup machen können?

Gruß
tschero

Rate mal warum ich nach den ganzen Fragen im Forum hier mal einen Sammelthread erstelle :-)

Je nach System (Windows, Linux, MacOS, ...) müssen auch erstmal Erfahrungen gesammelt werden.
Andererseits wird ja empfohlen auf der Kommandozeile nicht unbegabt zu sein. Und wer da was drauf hat, der weiß auch wie man ein Backup macht unter Beachtung der neuen Randbedingungen.
DIE muss man natürlich kennen. (Symlinks, Composer, ...)

Es wird demnächst für DB Backup wieder eine Erweiterung geben (BackupDB) wie zu Contao 3 Zeiten.
Aber wie der Name sagt, macht die nur ein DB Backup, als kleines Bonbon wird auf Wunsch auch die composer.json und .lock mit in das ZIP gepackt.

Der Contao Manager soll auch mal eine Möglicheit bekommen für ein Backup, da weiß ich aber grad nicht ob nur für die DB oder komplett.

Ich hänge mich da mal dran. Jetzt, wo ich dachte nach zwei Jahren wird alles gut mit Contao 4 und ich kann mich endlich mal ernsthaft damit beschäftigen, lese ich so etwas.

Ich verstehe das richtig, wenn ich ganz „normal“ (wie bei jedem anderen CMS) einfach die DB sichere und die Installation (also die Dateien) per (s)FTP sichern möchte geht das schief? :eek:

Etwas weniger Kommandozeile fände ich auch zugänglicher für den technisch nicht ganz unversierten Designer (= mich). Zu WordPress gibt es Duplicator, für Joomla Akeeba – so wünschte ich mir das auch für Contao. Zum Glück lässt sich auf absehbare Zeit auch noch mit 3.5 arbeiten.

So long
Michael

Zitat:

---

....möchte geht das schief?

---

Kurz: Ja.
Grund: Weil dabei die Symlinks zu echten Dateien gewandelt werden. Bei einem Restore meckert Symfony dann, weil es die Symlinks nicht mehr anlegen kann.
Es gäbe da noch eine Möglichkeit:
- Die Symlinks auslassen beim kopieren/transferieren und mittels contao-console beim Restore wieder anlegen lassen.
- oder nach dem Restore die "falschen" Dateien löschen (dazu muss man aber wissen welche) und dann mittels contao-console wieder die Symlinks anlegen lassen.

Macht die Sache nicht einfacher, soll nur zeigen das es möglich ist, ein solches "falsches" Backup zu reparieren.

Zitat:

---

Zitat von amateur

Etwas weniger Kommandozeile fände ich auch zugänglicher für den technisch nicht ganz unversierten Designer (= mich). Zu WordPress gibt es Duplicator, für Joomla Akeeba – so wünschte ich mir das auch für Contao. Zum Glück lässt sich auf absehbare Zeit auch noch mit 3.5 arbeiten.

---

Wordpress und Jommla arbeiten aber nicht mit Symlinks, oder?

Und zu Contao 3.5: Auch da ist es in Verbindung mit Composer möglich bereits mit Symlinks zu arbeiten, je nach Einstellung in der Paketverwaltung.
Also Vorsicht! (in Normalfall sollten da keine sein, einfach mal schauen ob es in system/modules/ Symlinks gibt)

Achja, wozu gibt es die Admins? Die freuen sich wenn sie helfen können :-)

Danke für die Erklärungen und dein Engagement, BugBuster!

Danke, aber nein danke. Ich würde mich jetzt nicht als den totalen Terminal-Versager bezeichnen, aber dieses ganze Geraffel für ein simples Backup ist mir einfach too much.

Ist jetzt total OT, aber für wen genau soll Contao zukünftig sein? Muss man vorher einen Kommandozeilen-Kurs irgendwo belegt haben um profane alltägliche Dinge wie ein Backup ausführen zu können? Eine Vergrößerung der Nutzerbasis dürfte mit dieser Form der Bedienung eines CMS nicht zu erreichen sein. Schade. Sehr schade.

Der Composer ist nicht dafür da die Leute abzuschreckenn - ganz im Gegenteil dieses Ding ist sehr toll:

1. Die Pakete aktuell zu halten - nicht nur bzgl. der Features sondern vorallem der Sicherheit zu liebe
2. Konflikte/Abhängigkeiten mit anderen Erweiterungen aufzulösen und gar nicht erst entstehen zu lassen
3. 3th-Party Libs nicht im Core zu halten - Größe des Projektes wird um einiges vermindert
4. Die App an das System optimal anzupassen
5. etc.

Etwas zum Thema Symlinks: Die Dinger sind auch ganz toll - einfach ausgedrückt, ermöglichen sie die Integration einzelner Libs/Pakete/Bundels

Zitat:

---

Zitat von electricarts

Ist jetzt total OT, aber für wen genau soll Contao zukünftig sein? Muss man vorher einen Kommandozeilen-Kurs irgendwo belegt haben um profane alltägliche Dinge wie ein Backup ausführen zu können? Eine Vergrößerung der Nutzerbasis dürfte mit dieser Form der Bedienung eines CMS nicht zu erreichen sein. Schade. Sehr schade.

---

Contao ist halt kein Jimdo- oder Wix-Baukasten. Ebenso auch kein WP, was so aufgeblasen ist, das es für jeden möglichen Klick ein js existiertiert. Contao ist in meinen Augen sehr mächtig - was die Performance, Flexibilität und Usability angeht.

Wau, wau.
Ich bin zu Contao gekommen, weil ich den Zugang mit einem praxisggerechten Framework und CSS für mich überzeugend war, einfach 'Wow' – und ist, denn darin hat sich auch bei Version 4 ja nichts geändert. WP ist für mich schön, wenn man mit fertigen Templates arbeiten kann/muss. Mit Joomla muss ich mich leider auch auseiandersetzen, weil Kunde es verlangt. Ich habe mich zwangsläufig damit arrangiert – und finde die Back-uplösung sehr angenehm.

Tatsächlich bin ich in vielerlei Hinsicht völlig ahnungslos, kenne mich mit Symfony nicht aus und weiß noch nicht mal genau, was Symlinks sind. Trotzdem biete ich Kunden Websites an und muss sie gelegentlich von einem Server auf den anderen transferieren. Bisher ging das eigentlich ganz gut, und ich nehme an, dahin werden wir auch mit Contao (wieder) kommen. Außerdem geibt es ja noch diese engagierte und hilgsbereite Community. Verstehe nicht, warum man sich deshalb ans Bein gepisst fühlen muss!? Das ist nicht meine Absicht.

So long
Michael

P.S.: Was ist ein 'mentales Modell'?

Oder wie letztes Jahr mal festgestellt wurde.
Einsatz von Contao: https://leofeyer.de/files/slides/2016/konferenz/#18
Zielgruppe von Contao: https://leofeyer.de/files/slides/2016/konferenz/#19

Wie man sieht: Zielgruppe !== Nutzerbasis

Die Hoffnung ist, das die Homepage Baukasten Nutzer im Lauf der Zeit lernen und zum CMS Nutzer werden. ;)

Das habe ich schon verstanden. Hier ging es auch nicht um Webbaukästen. Contao ist auch kein ProcessWire, WordPress, Joomla, Drupal, Typo3, Craft ... whatever. Und weil es so „anders“ war habe ich gerne bis Version 3.5 damit gearbeitet.

Ich verstehe nur seit geraumer Zeit nicht mehr, für wen Contao sein soll. Welche Zielgruppe will man bedienen? Wenn man nur noch PHP/Terminal Cracks im Sinn hat ist das ja auch in Ordnung. Aber dann soll man das auch sagen. Dann können sich alle anderen mit ihrem popeligen Shared Hosting und alle, die nicht in der Commandozeile zuhause sind, was anderes suchen.

Wenn es um die Installation und Nutzung geht, dann brauchst du durch den Contao Manager keine Kommandozeile.
Aber es vereinfacht Dir die Arbeit, wenn es mal Probleme geben sollte. Der Composer kann mehr als der Contao Manager zur Zeit anbietet.

Administrative Dinge hat Dir Contao 3 auch nicht abgenommen, da musstes du auch mit (S)FTP oder ZIP, TAR, ... Bescheid wissen, je nachdem was der Zweck war.
Das ist also nun nicht anders. Nur haben sich eben die Randbedingungen geändert.

Warte mal ab, ich glaube das irgendwann von irgendwem ein Shellscript auftauchen wird, das brauchste dann nur aufrufen und der Rest erfolgt von selbst.
Oder eine gute ausformulierte Anleitung.

Zitat:

---

Zitat von electricarts

Ich verstehe nur seit geraumer Zeit nicht mehr, für wen Contao sein soll. Welche Zielgruppe will man bedienen? Wenn man nur noch PHP/Terminal Cracks im Sinn hat ist das ja auch in Ordnung. Aber dann soll man das auch sagen. Dann können sich alle anderen mit ihrem popeligen Shared Hosting und alle, die nicht in der Commandozeile zuhause sind, was anderes suchen.

---

... kann mich der Aussage nur voll und ganz anschließen.
Ich weiß die Entwicklungsarbeit die in Contao 4 gesteckt wird zu schätzen –
habe jedoch den Eindruck das der durchschnittliche End-Anwender aus den Augen verloren wird.

Aus meiner Sicht kann das Backup für Contao 4.4.x nur dann funktionieren, wenn auf dem Zielsystem die Datenbank und die dazugehörigen Konfigrationsdateien wiederhergestellt werden. Das Problem mit den Symlinks ist bei Hostern auf denen der Endanwender keinen Shell Zugriff hat dann das Ende des Backups. Damit ist für Contao 4.4.x ein SSH Zugriff erforderlich ob mit oder ohne contao-manager.

Ich selbst hatte auf den contao-manager gewartet, weil ich trotz "Konsolenfähigkeiten" und entsprechenden Servern, wissen wollte ob man das Ding (contao) tatsächlich noch ohne Konsole installiert bekommt.
Ich war erstaunt wie gut das schon mit dem contao-manager beta1 möglich und Problemlos war... Allerdings beim ersten kopieren der Daten via FTP kam dann der AHA Effekt :eek: Das kann ja gar nicht funktionieren. Adios günstige Webspaces für 5 EUR/Monat :(

Wenn ich heute einen Backup machen müsste, würde ich so vorgehen:

- Datenbanksichern,
- die Module welche ich per contao-manager installiert habe aufschreiben
- die Module die ich von Hand installiert habe aufschreiben -> ja die gibt es nach wie vor z.B. bei gekauften Themes die nie auf github erscheinen werden.

Auf dem Zielserver die Installation mit allen Modulen durchführen und die Datenbank wiederherstellen. Ob das so funktionieren könnte muss ich noch testen - aber aus meiner Sicht aktuell die einzige Möglichkeit.

Noch zum Thema aktualisierung via contao-manager -> das hat in den letzten Tagen immer wunderbar funktioniert.
Für die core Module und auch die selbst über den contao-manager installierten Module kann man da auch bestimmte Versionen vorgeben. Nicht aber für Grundlagen wie Symfony. Das hat gestern einen Update von 3.3.2 auf 3.3.3 erfahren... 3x dürft ihr raten was passiert -> so schlimm ist es nicht https://github.com/contao/core-bundle/issues/921 , verdeutlicht aber die Komplexität. Mit nur einem Klick kann man die Installation ins Nirvana befördern, wenn da schon am Symfony 3.3.2 zu 3.3.3 hunderte von PHP Warnings gibt.

Deshalb ist BACKUP immer die Grundlage jedes Updates - und dass man hierfür erwartet, dass es jeder via Konsole kann (sonst hätte man sich Gedanken beim Einsatz von Symlinks gemacht) finde ich schon bisschen traurig. Contao 4.4.x entwickelt sich aus meiner Sicht zum Werkzeug für spezielle Sachen.

EDIT-> ich wollte zum Backupvorschlag noch was schreiben:
via contao-manager die Einstellungen/Dateistruktur (DocRoot) prüfen oder falls nicht möglich den User eingeben lassen.
Dann per tar das System sichern - und die Datei als Download unter /files anbieten
Auf dem Zielsystem den contao-manager für die Rücksicherung bemühen (user muss die Tar Datei in ein Verzeichnis laden) und Dateien die auf Dateistrukturen basieren entsprechend neu generieren (Symlinks o.ä).

Ich denke schon, dass man den Contao-Manager dahin bringen kann, auch so ein "defektes" Backup mit Dateien statt Symlinks automatisch zu reparieren. Vereinfacht gesagt könnte man ihn ja so programmieren, dass er beim Anlegen der SymLinks eine eventuell gefundene Datei halt einfach löscht (oder eine Kopie davon irgendwo ablegt für alle Fälle) und dann den SymLink anlegt. Ich habe schon noch Hoffnung, dass man da ohne Kommandozeile auskommen kann.

Wobei ich die Aufregung um die Kommandozeile nicht so ganz verstehen kann. Es gibt durchaus günstige Webspaces um die 5 Euro oder sogar noch günstiger, die einen solchen SSH-Zugang anbieten. Freilich nicht bei jedem Anbieter, aber wer sparen will oder muss, der muss seinen Webspace halt da kaufen wo dies der Fall ist.

Zitat:

---

Zitat von tab

Wobei ich die Aufregung um die Kommandozeile nicht so ganz verstehen kann. Es gibt durchaus günstige Webspaces um die 5 Euro oder sogar noch günstiger, die einen solchen SSH-Zugang anbieten. Freilich nicht bei jedem Anbieter, aber wer sparen will oder muss, der muss seinen Webspace halt da kaufen wo dies der Fall ist.

---

Würde daher bedeuten (für nicht wenige) => Umstieg auf contao 4.4 = neuer Webspace!

Um jetzt einen direkten Vergleich mit contao 3.5 anzubieten: es wird nicht mehr das CMS sein, das überall läuft. Datenbank anlegen, Dateien per FTP hochzuladen und den Installer starten war mal. Und sollte der contao-manager alles das schön abdecken ist prima. Aber noch ist es nicht so weit, da wir uns momentan um die wichtigste Sache eines Projektes kümmern müssen: funktionierendes BACKUP! Ohne Backup kein Produktiveinsatz (meine Meinung)

Meine Server haben keine GUI, außer ich installiere mir dazu ISPConfig. Daher ist das nicht meine Sorge - aber ich denke hier an die User die "schnell mal ein CMS installierten". Die füllen dann demnächst das Forum: "wie ziehe ich eine Installation um" oder "habe Server neuinstalliert meine Contao Installation geht nicht mehr weil Symfony Pfade nicht findet"

Also der Contao Manager kann theoretisch die Symlinks neu anlegen, das macht er ja bei jeder Installation oder Update einer Erweiterung am Ende.
Wobei das die Post-Install Scripte von Contao sind, aber das spielt ja erstmal keine Rolle.

Nur gibt es dazu noch keinen eigenen Menüpunkt, so wie es jetzt ja bereits gibt "Cache neu erstellen".

Der Manager soll ja defekte Installationen auch reparieren können, das muss er aber noch lernen. Wobei ich das noch nicht probiert habe, vielleit kann er es ja in dem Fall schon.

Ich hatte gehofft das sich hier mal die großen Agenturen melden und sagen wie die es tun. Denn Contao ist schon seit vielen Monaten auf Live Seiten im Einsatz.

Backup != Deployment
Ich kann mir nicht die auf USB gesicherten MP3´s auf einem CD-Spieler anhören.

Zitat:

---

Zitat von ihkwdiopk

Backup != Deployment
Ich kann mir nicht die auf USB gesicherten MP3´s auf einem CD-Spieler anhören.

---

Wo bleibt die Innovation? :D

Zitat:

---

Zitat von planepix

Wo bleibt die Innovation? :D

---

Wollte zuerst schon Kassettenrecorder schreiben :rolleyes:

Zitat:

---

Zitat von ihkwdiopk

Backup != Deployment
Ich kann mir nicht die auf USB gesicherten MP3´s auf einem CD-Spieler anhören.

---

aber sehr wohl auf einem anderen Medium das USB Anschluss hat.

Hallo zusammen,

was spricht dagegen, folgendes zu tun:

• Sicherung der Datenbank
• Sicherung d. Composer-Daten
• Dateien und Module in jeweils eigene tars sichern
• Eine Art Build-Script, welches dann wieder "zurück" rollt nach einer Contao Installation

Also im Grunde den Weg geht: Installiere Contao -> Richte Website ein -> Erstelle backup. Das Backup wiederum geht den schritt dann Rückwärts, indem Contao installiert wird und die Sicherung eingespielt wird. Hiermit kann man also getrost, getrennt von Symlink oder Ordner, die Inhalte des jeweiligen Inhalts wieder herstellen.

Es müsste, so mein Gedanke, eine Möglichkeit einer "Automatisierten" Contao Installation geben mit der Rücksicherung.

Oder ist das vollkommen gaga? :o

Zitat:

---

Zitat von kretschi

Würde daher bedeuten (für nicht wenige) => Umstieg auf contao 4.4 = neuer Webspace!

Um jetzt einen direkten Vergleich mit contao 3.5 anzubieten: es wird nicht mehr das CMS sein, das überall läuft. Datenbank anlegen, Dateien per FTP hochzuladen und den Installer starten war mal. Und sollte der contao-manager alles das schön abdecken ist prima. Aber noch ist es nicht so weit, da wir uns momentan um die wichtigste Sache eines Projektes kümmern müssen: funktionierendes BACKUP! Ohne Backup kein Produktiveinsatz (meine Meinung)

Meine Server haben keine GUI, außer ich installiere mir dazu ISPConfig. Daher ist das nicht meine Sorge - aber ich denke hier an die User die "schnell mal ein CMS installierten". Die füllen dann demnächst das Forum: "wie ziehe ich eine Installation um" oder "habe Server neuinstalliert meine Contao Installation geht nicht mehr weil Symfony Pfade nicht findet"

---

Nur weil der Contao-Manager noch nicht so weit ist (Beta ...) heißt das ja nicht, dass man momentan kein funktionierendes Backup machen kann. Kann mir ja keiner weismachen, dass Leo nicht weiß, wie man ein funktionierendes Backup erstellt bzw wieder einspielt. Es ist halt nur noch nicht wieder so einfach wie früher, eventuell geht es auch nur etwas anders als früher und ist dann womöglich noch einfacher. Da muss man halt umlernen. Irgendwann mal haben wir den Umgang mit FTP-Tools und phpMyAdmin gelernt, jetzt müssen wir halt den Umgang mit neuen Tools lernen. Egal ob sie jetzt Contao-Manager oder Composer heißen. Alles entwickelt sich weiter, Dinge ändern sich. Nur wenig im Leben ist noch so, wie es vor 20 Jahren mal war. Im Softwarebereich geht es halt immer noch ein wenig schneller. Also ist lernen angesagt, wie überall im Leben heutzutage. Die User, die nach einer neuen Version das Forum mit Fragen füllen gab es auch schon beim Umstieg auf Contao 3. Wird es immer geben, wenn sich irgendwas ändert bzw nicht mehr so funktioniert wie früher.

Zitat:

---

Zitat von tab

Nur weil der Contao-Manager noch nicht so weit ist (Beta ...) heißt das ja nicht, dass man momentan kein funktionierendes Backup machen kann. Kann mir ja keiner weismachen, dass Leo nicht weiß, wie man ein funktionierendes Backup erstellt bzw wieder einspielt. Es ist halt nur noch nicht wieder so einfach wie früher, eventuell geht es auch nur etwas anders als früher und ist dann womöglich noch einfacher. Da muss man halt umlernen. Irgendwann mal haben wir den Umgang mit FTP-Tools und phpMyAdmin gelernt, jetzt müssen wir halt den Umgang mit neuen Tools lernen. Egal ob sie jetzt Contao-Manager oder Composer heißen. Alles entwickelt sich weiter, Dinge ändern sich. Nur wenig im Leben ist noch so, wie es vor 20 Jahren mal war. Im Softwarebereich geht es halt immer noch ein wenig schneller. Also ist lernen angesagt, wie überall im Leben heutzutage. Die User, die nach einer neuen Version das Forum mit Fragen füllen gab es auch schon beim Umstieg auf Contao 3. Wird es immer geben, wenn sich irgendwas ändert bzw nicht mehr so funktioniert wie früher.

---

Stimme ich soweit zu. Alles wird weiterentwickelt - ohne Weiterentwicklung könnten wir weiterhing mit der Version 2.x arbeiten.
Aaaaber: wir sprechen hier nicht von 4.x beta Test sondern von einer 4.4. LTS die eigentlich in Produktionsumbgebungen arbeiten könnte! Die Aussage ist doch klar: Contao 4.4 benutzen weil es besser ist! Hat man ja gesehen, warum so viele gewartet haben bis der contao-manager draußen war. Davor waren die wenigsten mit der Version 4.x beschäftigt...

Gerade mit meiner Erfahrung gestern und einem "Fehler" im Symfony ist der Einsatz von Contao 4.4 ohne vernünftiges Backupkonzept ein riskantes Spielchen. (

Der Fehler ist aber gerade über Kommandozeile und Composer reparierbar ohne ein Backup wieder einspielen zu müssen.
Dem hier folgen: https://community.contao.org/de/show...-unter-Windows
dann ein "composer update --no-dev --optimize-autoloader" und dann sollte das repariert sein.

Zitat:

---

Zitat von BugBuster

Der Fehler ist aber gerade über Kommandozeile und Composer reparierbar ohne ein Backup wieder einspielen zu müssen.
Dem hier folgen: https://community.contao.org/de/show...-unter-Windows
dann ein "composer update --no-dev --optimize-autoloader" und dann sollte das repariert sein.

---

Nö, das war nicht die Windows Meldung. Ich hatte mein Ticket von gestern gemeint: https://github.com/contao/core-bundle/issues/921
Mit dem Update auf Symfony 3.3.4 von eben ist wieder alles tutti.

Ich wollte damit nicht sagen, dass man ohne Backup das o.g. Problem nicht lösen kann - sondern, wenn es mal ein Paket gibt das gravierende Änderungen durchführt (DB und Files) dann könnte es ohne Backup schlecht aussehen.

Doch natürlich kannst du das lösen, die kannst jedes Update rückgängig machen. Und offenbar hat ja Symfony 3.3.4 den Fehler behoben, dann hätte man auch auf 3.3.2 zurückgehen können. (durch den conflict Eintrag automatisch, solange es keine 3.3.4 oder höher gibt)

Zitat:

---

Zitat von BugBuster

Doch natürlich kannst du das lösen, die kannst jedes Update rückgängig machen. Und offenbar hat ja Symfony 3.3.4 den Fehler behoben, dann hätte man auch auf 3.3.2 zurückgehen können. (durch den conflict Eintrag automatisch, solange es keine 3.3.4 oder höher gibt)

---

Und somit sind wir wieder beim Thema Composer - Tolles Teil!

Nicht nur Composer ist ein tolles Teil, sondern auch die Konsole rockt.

Ich synchronisiere schon seit Jahren alle meine Webprojekte mit meiner lokalen Testumgebung direkt auf der Konsole. Vom Server nach Lokal und umgekehrt. Das Linux Kommando dazu ist rsync:

Code:

---

rsync -avze ssh quelle/ ziel/

---

Dabei werden alle Dateien/Ordner aus der Quelle nach Ziel kopiert. Auch versteckte Dateien (die mit dem Punkt davor) z.B. .htaccess. Und das Wichtigste - zumindest unter Linux: Symlinks bleiben Symlinks. Beim ersten Einsatz wird alles kopiert, danach nur noch veränderte Dateien. Somit ist die Synchronisation recht schnell.

Der Aufruf aus meiner lokalen Linux-Umgebung lautet:

Code:

---

rsync -avze ssh --delete --exclude=<auszuschließende Datei(en) oder Ordner> Serveruser@server.tld:/pfad/zum/projektordner/ /pfad/zum/lokalen/backup/

---

Das ist ein komplettes Backup der Daten, die somit ohne Probleme wiederhergestellt werden können.

Mehr infos zu rsync und den verschiedenen Optionen(-avze --delete --exclude...): https://wiki.ubuntuusers.de/rsync/

EDIT: Typo

Voraussetzung:
Nur Contao4 – Bundles, Managed Edition, keine Contao3 Module

Umbenennen des Ordners

Zitat:

---

xampp

---

auf

Zitat:

---

xampp-old

---

Herunterladen der Installations- Datei xampp

https://www.apachefriends.org/xampp-...-installer.exe

Installation von xampp (bei mir auf D: )

Kopieren aller nicht vorhandener Dateien von

Zitat:

---

D:\xampp-old\htdocs\

---

nach

Zitat:

---

D:\xampp\htdocs\

---

!Aber keine Contao 4 Versionen!!!!

Kopieren aller nicht vorhandener Dateien von

Zitat:

---

D:\xampp-old\mysql\data

---

nach

Zitat:

---

D:\xampp\mysql\data

---

Folgende Dateien/Ordner aus

Zitat:

---

D:\xampp-old\htdocs\ …

---

der entsprechenden Contao4 Installationen nach

Zitat:

---

D:\xampp\htdocs\ …

---

der entsprechenden Contao4 kopieren:

.settings / Ordner Eclipse
Files / Ordner Contao
Files / Ordner Contao
.gitignore
.project / Datei Eclipse
Composer.json
Composer.lock
README.md

Ich spreche jetzt von WINDOWS!!!

Xampp- Kontrollpanel als Administrator starten, Apache und MySQL starten

Entweder Eclipse oder CMD als Administrator starten

Ins Verzeichnis der Contao4- Installation wechseln

Eingabe:

PHP-Code:

---

Composer update 


---

Vollständige Installation, inklusiv der Erweiterungen der Contoa4- Bundles

Explorer als Administrator öffnen (sicher ist sicher)

Aufruf des Install- Tools mit

PHP-Code:

---

 …/Contao/Install 


---

Eingabe des neuen Passwortes

Datenbank angeben

( jetzt bei mir Fehler bei DB- Update mit tl_image_size, Abhilfe mit löschen der Tabelle tl_image in PHPMyAdmin, irgendwie wurde das _size beim anlegen wohl abgeschnitten)

Danach Login im Backend

Systemwartung -> Daten bereinigung alles auswählen

Manchmal danach noch css- Probleme im Frontend

Im Backend unter Themes-> Seitenlayout Layout wählen, dort auf speichern gehen

Alles gut

Zitat:

---

Zitat von ihkwdiopk

Und somit sind wir wieder beim Thema Composer - Tolles Teil!

---

ohne ssh Zugang? Zeig mal wie geht das?

Zitat:

---

Zitat von BugBuster

Doch natürlich kannst du das lösen, die kannst jedes Update rückgängig machen. Und offenbar hat ja Symfony 3.3.4 den Fehler behoben, dann hätte man auch auf 3.3.2 zurückgehen können. (durch den conflict Eintrag automatisch, solange es keine 3.3.4 oder höher gibt)

---

Das ist doch das was ich beim contao manager vermisse -> hier schon für alle module die automatisch aktulisiert werden, entsprechende "bremsen" einzubauen. Ohne Konsole geht aber gar nicht.

Wenn ich zuerst per FTP Dateien editieren muss um anschließend per contao-manager zu aktualisieren, muss ich ja schon vorher wissen, dass das Update nicht durchgeführt werden darf.

Ich glaube aber, dass wir hier den Thread lieber wieder mit Backupideen füllen sollten und nicht über composer und Konsole.

Ich gebs zu, ich habe auch gewartet. Hauptsächlich auf die LTS, aber natürlich nehme ich den Contao-Manager gerne mit. Ich hatte auch nie eine Kundeninstallation mit Contao 3.3 oder 3.4 am laufen. Grundsätzlich nur LTS. Ok, hätte ich eines der neuen Features von 3.3 oder 3.4 ganz ganz dringend gebraucht ... aber war nicht. Habe alles von 3.2 auf 3.5 upgedatet, völlig problemlos, weil ich auch mit Erweiterungen sparsam umgehe. Und ich gehe davon aus, bis zum Ende der 3.5 LTS wird es mir auch genauso problemlos gelingen, alles nach und nach auf 4.4 zu bringen.

Grundsätzlich war es mir schon immer lieber, beim Kundenwebspace einen SSH-Zugang zu haben. Das vereinfacht vieles, auch ohne Composer. Es geht alles einfach unendlich viel schneller als per FTP, weil ich da meist von Server zu Server kopiere und wenn ich was lokal sichere, dann wird es zuerst mit tar gepackt und dann als eine Datei übertragen. Ist ja nicht so, dass ich der große Unix-Wizard wäre. Aber die paar Befehle, die ich regelmäßig brauche, die kann ich mir gerade noch merken. Was ich seltener brauche, hole ich mir im Zweifelsfall per Google oder aus diversen Wikis, unter anderem auch vom Asteroidenhoster, der vermutlich für Kommandozeilenhasser die Höchststrafe darstellen dürfte.