Workflow Website-Kopie erstellen mit aktuellen Daten (z.B. Formulardaten)

[pipkin]

Hallo zusammen,

ich möchte eine 3.5.17 zur 3.5.30 updaten. Die Website sammelt laufend Daten, nämlich über unterschiedliche Formulare, die in der Datenbank gespeichert werden ("Anfragen", Contao Leads).

Ich würde jetzt zunächst einen Datenbank-Dump ziehen und alle FTP-Daten herunterladen und daraus auf dem Server eine Kopie erstellen, anschließend Contao updaten, und - wenn dann alles läuft - die Domain auf das Verzeichnis der Kopie umswitchen.

Wie gehe ich aber mit Formularen um, die in der Zwischenzeit auflaufen?

Soll ich, wenn alles fertig ist, einfach nochmals die Datenbank kopieren und ersetzen?
Ich kann mir vorstellen, dass dies nicht der grundsätzlich beste Weg ist, da sich Datenbankstrukturen ja auch unterscheiden können und die Kopie nicht mehr passt.

Wie sieht für sowas grundsätzlich der beste Workflow aus?
Also wenn es nicht nur um Formulardaten geht sondern auch um allerhand andere Daten, die in der Zwischenzeit auflaufen.
Führt dann kein Weg daran vorbei, die Website für die Dauer des Updates in den Wartungsmodus zu schalten?

Wie macht Ihr das?

Bin gespannt ...

[jscholtysik]

Warum kein Backup von DB und FTP-Daten machen und die Seite direkt updaten? Das Update dauert bei so einem kleinen Versionssprung über EasyUpdate3 wahrscheinlich keine 5 Minuten...

[pipkin]

In diesem konkreten Fall wäre diese "OP am offenen Herzen" wohl auch ok, ist mir als grundsätzlicher Workflow aber zu unsicher. Schließlich kann immer etwas passieren - irgendeine Erweiterung nicht mitspielen, dann hat man einen Bug und dann den Stress.

Ich dachte, es gibt vielleicht einen bombensicheren Weg, der eben dann beschritten wird, wenn es eben mehr ist als nur "vermutlich problemlose Miniänderungen".

Nachtrag: Angenommen, alles sieht super aus nach dem Update, muss ich die Website ja dennoch 1x durchchecken, Formulare abschicken, testweise auf mich umleiten, usw. Bis ich einen Bug entdecke, vergehen also einige Minuten. Auch wenn der "Refall" aufs Backup dann innerhalb von 30 bis 60 Minuten geschehen könnte, wäre diese Zeitspanne im Ernstfall etwas zu lang. Wenn dann in der Zwischenzeit ein echter User das Formular abschicken wollte oder sich die Daten geändert haben und mein Backup nicht mehr aktuell ist, wäre das genau der Fall, den ich nicht haben möchte.

[jscholtysik]

Ich hatte in letzter Zeit ein paar Seiten, die ich teilweise sogar von Version 3.2 auf die aktuelle 3.5.30 mit EasyUpdate3 upgedated habe, da hatte ich nie Probleme mit irgendwelchen Erweiterungen. Und das bei Dir ist ja sogar nur ein Versionsupdate innerhalb der 3.5er Version. Zur Not hast Du ja dann immer noch Dein Backup.

[pipkin]

Das mag im Einzelfall ja auch angemessen sein. Wie würdest Du aber vorgehen, wenn Du erstmal etwas in sicherer Umgebung (d.h. parallal) testen musst, bevor Du es live stellst, und dann die Daten, die in der Zwischenzeit aufgelaufen sind, wieder ergänzen musst?

[jscholtysik]

Wie viele Daten laufen denn in Deiner Installation in 5 Minuten auf? Verstehe ich jetzt nicht. Dann schalte doch einfach den Wartungsmodus an, dann laufen in der Zeit auch keine Daten auf...

[tab]

Also wenn du es am Original machst und notfalls das Backup wieder einspielst, dann solltest du zuvor in jedem Fall zumindest den Wartungsmodus aktivieren. Dazu ist der da und er verhindert, dass dir jemand beim Update dazwischenpfuscht, indem er irgendwelche Formulare abschickt oder sonst etwas macht, was die Datenbankinhalte ändert.

Eine relativ sichere Strategie zum Update in so einem Fall könnte sein, erst einmal einen Testlauf des Updates an einer Kopie zu machen. Wenn dann nach Tests klar ist, mit welchen Schritten das Update erfolgreich durchgeführt werden kann, die produktive Site in den Wartungsmodus versetzen. Neue Kopie davon erstellen, komplett oder zumindest Datenbank und alle Verzeichnisse, wo Besucher, Mitglieder oder irgendwelche anderen Backend-Benutzer irgendwas ändern können (Datei-Upload, ...). Die erprobten Schritte zum Update durchführen. Nochmal kurz testen, man weiss ja nie. Wenn es gut aussieht Wartungsmodus deaktivieren, ansonsten Backup wieder einspielen und zurück zum Zeichenbrett . So lässt sich die Downtime etwas verringern im Falle von beim Update auftretenden Problemen und es sollte nichts verloren gehen, was nicht auch im Normalbetrieb verloren gegangen wäre (Rechenzentrum abgebrannt ... ).

Insofern würde ich meinen, es führt mit normalen Bordmitteln kein sicherer Weg völlig am Wartungsmodus (oder anderen Maßnahmen, die Änderungen von aussen sicher verhindern) vorbei.

[do_while]

1) Ich würde eine laufende Kopie erstellen (als Sicherheit, Backup)
2) Dann würde ich den Wartungsmodus aktivieren, damit die Website während des Updates nicht benutzt werden kann
3) Dann das Original updaten
4) Wenn alles läuft, den Wartungsschutz entfernen
5) anderenfalls die Domain auf die laufende Kopie setzen (Notlösung, nächster Versuch später)

Mit einer Live-Update-Id oder mit EasyUpdate3 sollte das Update in wenigen Miunten erledigt sein.
Man sollte das Ganze natürlich in Zeiten vornehmen, wo relativ wenige Nutzer sind (Statistiken auswerten).

Vorbereitend sollte man sich natürlich die Änderungen in den Zwischenversionen genau ansehen und ggf. Erfahrungen aus Fragen im Forum auswerten.

Edit: tab war schneller

[Andreas]

Vergiss auch nicht zusätzlich zum Wartungsmodus im BE die Benutzer zu deaktivieren.

[pipkin]

Wie viele Daten laufen denn in Deiner Installation in 5 Minuten auf? Verstehe ich jetzt nicht. Dann schalte doch einfach den Wartungsmodus an, dann laufen in der Zeit auch keine Daten auf...

Es ging mir generell um einen vernünftigen, maximal sicheren und grundsätzlichen Workflow für Updates, unabhängig von meinem o.g. Einzelfall. Teil der Frage war, ob man um den Wartungsmodus drum herum kommt, da Kunden internationaler Websites, die keine "Nachtruhe" kennen, dies natürlich extrem ungern sehen.

@ tab und do_while: klingt beides gut. Ein Kopie so vorbereiten (also nicht nur Backup im Sinne eines Downloads, sondern gleich online eine einsatzfähige Kopie) klingt sehr sinnvoll, das ist dann notfalls auch innerhaln von einer Minute am Start. Um den Wartungsmodus kommt man anscheinend dann nicht herum, damit kann das Backup dann auch nicht veralten.

Vergiss auch nicht zusätzlich zum Wartungsmodus im BE die Benutzer zu deaktivieren.

Guter Punkt!


Hm .. im schlimmsten Fall würde dann jemand vom Wartungsmodus erwischt werden, der gerade dabei ist, zu interagieren (Formular abschicken/ Kommentar schreiben/ sich registrieren ..). Aber auch das wäre nur halbschlimm, da beispielsweise ein Formular noch verarbeitet werden würde... Richtig?


Mich würde natürlich auch interessieren, ob das bei Websites mit Buchungs- oder Shop-Funktionen auch so gehandhabt wird, denn dort könnten User noch sensibler unterbrochen werden, z.B. mitten im Bezahlvorgang. Ägerlich auch, wenn der Warenkorb gelöscht wird. Größere Shops haben vermutlich parallel irgendwie synchronisierte Systeme, falls mal eines ausfällt. Aber die nicht ganz so großen .. wie machen die das?

[Samson1964]

Hm .. im schlimmsten Fall würde dann jemand vom Wartungsmodus erwischt werden, der gerade dabei ist, zu interagieren (Formular abschicken/ Kommentar schreiben/ sich registrieren ..). Aber auch das wäre nur halbschlimm, da beispielsweise ein Formular noch verarbeitet werden würde... Richtig?

Mich würde natürlich auch interessieren, ob das bei Websites mit Buchungs- oder Shop-Funktionen auch so gehandhabt wird, denn dort könnten User noch sensibler unterbrochen werden, z.B. mitten im Bezahlvorgang. Ägerlich auch, wenn der Warenkorb gelöscht wird. Größere Shops haben vermutlich parallel irgendwie synchronisierte Systeme, falls mal eines ausfällt. Aber die nicht ganz so großen .. wie machen die das?

Dir ist das bestimmt auch schon mal passiert, das Du gerade auf einer Website bist, dort Formulare ausfüllst oder anderweitig interagierst - und plötzlich ist der Server nicht erreichbar oder Du siehst eine Wartungsseite. Das finde ich völlig normal. Bei meinem Hoster komme ich täglich von 3 bis etwa 6 Uhr nicht in das Kundenmenü. Auch die Postbank geht nachts oft offline.

[pipkin]

Ja, das kenne ich schon - wobei ich nicht sicher bin, wann so eine Wartungsseite spontaner Ausdruck eines Unfalls ist oder ob diese zu einer "professionellen Wartungs-Routine" dazu gehört. Dank Eurer Einschätzung reift bei mir diese Erkenntnis aber gerade ;-)

(Bisher ging ich davon aus, dass die Wartungs-Seite nur in absoluten Notfällen zum Einsatz kommen sollte. Liegt wohl auch an den bisherigen eher verständnislosen Reaktionen der Websitebetreiber auf jegliche Unterbrechungen des Livebetriebs, beispielsweise bei einem Server-Umzug - oder wenn der Hoster ankündigt, dass ggf. die Website wegen eines Umbaus nicht zu erreichen ist. Das gibt dann immer gleich Puls und hektische Flecken.)

[tab]

Also wenn die es so wichtig haben, dann können die ja ein entsprechendes Entwicklungsprojekt finanzieren. Manuell kann man sicher auch was machen, wenn die (Formular-?)Daten, die da eingegeben werden, in separaten Tabellen gespeichert werden, die sich bei einem Update nicht ändern und sich problemlos abgleichen lassen.

[pipkin]

;-)
Wichtigtuerei und "finanzieren wollen" stehen sich ja fast immer diametral gegenüber ;-)

Wenn Wartungsseite Usus ist, dann sollten sie damit auch leben können.

[tab]

Fängt ja schon beim Hosting an, für höhere Verfügbarkeit als 99,99% wird man schon ein wenig mehr hinlegen müssen als für ein Shared-Hosting Paket des nächstbesten Feld- Wald- und Wiesenhosters, meist sind ja sogar nur 99,9% versprochen (man wird sich ja mal versprechen dürfen, es kommt auch immer darauf an, was man unter Verfügbarkeit versteht), was immerhin 8 Stunden Downtime zulässt pro Jahr.

[pipkin]

Wollte mich nochmals bei allen für die Anregungen bedanken. Ich habe das Verfahren heute dann auch gleich ausgetestet. Dabei hat sich herausgestellt, dass es - für mich - sinnvoll ist, den Wartungsmodus im Original zu setzen, bevor der Datenbank-Dump gezogen wird, da in der kleinen Lücke zwischen beenden des Backups und Start der Wartungsarbeiten (Aktivierung des Wartungsmodus) schon wieder frische Daten reingerasselt sind, weswegen ich wieder neue Datenbank-Dumps ziehen und hochdudeln musste. Bis ich alles synchron hatte, dauerte es also doch länger. Wenn ich vorher den Wartungsmodus einschalte, entfällt auch das lästige checken, ob auch noch alles gleich ist...

Außerdem habe ich festgestellt, wie extrem sinnvoll es ist, das Backup erstmal als lauffähige Kopie zu installieren und zu testen (!), bevor ich mich darauf verlasse, dass ich ein funktionierendes Backup habe. Denn tatsächlich schlug der Import via phpMyAdmin von verschiedenen sql.gz-Dateien fehl, andere klappten. Vielleicht lag es am mysql-Dumper. Ich werde Backups - insb. in solchen Situationen - fortan testen.

Die eigentlichen Contao-Updates habe ich dann mit easyupdate3 gemacht, was wirklich Spaß gemacht hat und super bequem war. Toll auch zu wissen, dass parallel Backups angelegt werden und super, dass man sieht, was genau passiert, was beruhigend ist, auch wenn ich nicht alles verstehe, was da steht. Super Arbeit.

Ein Problemchen und "weiße Seite" hatte ich beim Updaten einiger Erweiterungen. Umso beruhigter ließ sich arbeiten, da ich die intakte Fallback-Kopie parat hatte und zudem den Wartungsmodus - mit eigenem Template (yeah!) - aktiv.

Mein Workflow sieht jetzt so aus:

1. Aktivieren des Wartungsmodus im Original (sofern relevant Deaktivieren von Benutzern)
2. Erstellen des Backups und Inbetriebnahme (inkl. Testen) der Fallback-Kopie unter einer Subdomain zwecks schneller Reaktion für den Notfall (umswitchen der Domain)*
3. Updaten der Erweiterungen und von Contao
4. Testen der Website
5. Beenden des Wartungsmodus

*Wenn nur Daten in der Datenbank gesammelt werden und keine Dateien auf dem Server, beispielsweise Datei-Uploads in Formularen, kann der FTP-Download und Upload vorbereitend erledigt werden.

Für die meisten hier ist das alles vermutlich Banane, aber unsereins steht oft davor und bibbert, ob man auch alles richtig macht. Krimi pur ;-)

[Andreas]

Noch eine Idee/Gedanke dazu. Habe ich zwar noch nie gemacht, aber rein theoretisch müsste man den Spiegel, da wo upgedatet wird, mit der original DB laufen lassen können. In der DB kann eigentlich nichts passieren.

• Entweder kommen dort neue Tabellen und Felder hinzu - die stören nicht.
• Nicht mehr benötigte Tabellen und Felder werden nicht zum Löschen angehakt - sollte man auch erstmal nicht löschen.
• Felder werden in ihrer Einstellung optimiert. Das geht eher Richtung char(16) auf char(256) und nicht andersherum, dürfte also kein Problem sein.
• Indizes werden zum Löschen oder Hinzufügen angeboten. Dies ist auch eher eine Optimierung und kann noch nachträglich im Original gemacht werden.

Höchstens eine runonce.php könnte ich mir vorstellen, die da was verbocken könnte, wenn sie Daten aus bestimmten Feldern in andere Felder überträgt, oder sogar merged oder irgendwie die Struktur ändert. Und dies auch nur, wenn diese die ursprünglichen Felder entfernt, deren Inhalte verändert, oder den Namen ändert.

Aber ich weiß nicht, ob es überhaupt Erweiterungen gibt, die soetwas machen.

Was sagen die Gelehrten dazu?

[do_while]

Naja - mit einer Datenbank-Kopie bin ich aber auf der sicheren Seite, egal was das Update damit macht.
Zumindest ein Backup auf Datei sollte man dann da haben.