[gelöst]Core Update bei produktiver Webseite

1.) https://www.drupal.org/project/backup_migrate installieren - Zeitplan auf 1Std oder 3 Std stellen. - Achte auf das Modul "Cron"
2.) Dann ganzes Verzeichnis/Webseite mit Core kopieren/duplizieren. (Datei Backup)
3.) Jetzt aktualisieren/Update Module
3.1) das Core/Update/Upgrade kann nach meiner Erfahrung, direkt überschrieben werden.
Beispiel : Du hast installiert Drupal 7.1 ; und kannst direkt Drupal 7.3 überschreiben. die Versionen dazwischen können übersprungen werden.

LGP.
Hoffe ich hab Dir etwas geholfen.

LG Peter
PS: mache die Entwicklung direkt auf dem Server -> all-inkl.com

Danke schon mal, Peter!

Ganz verstanden habe ich die Vorgehensweise aber nicht:

1) mit dem Modul backup and migrate erstellt du dir ein Backup deiner Datenbank. Richtig? Mit Zeitplan meinst du, dass du jede Stunde bzw. dritte Stunde ein Backup machst, oder?
2) Machst du das Backup der Webseite lokal auf deinem PC oder auf dem Server?
3) Wo findet die Aktualisierung statt? Lokal am PC oder auf dem Server?

Grüße
ThuleNB

PC oder Webseitenserver ist egal hauptsache Du kannst es wieder einspielen falls die Webseite crasht.

Hallöchen,

ergänzend zu den vorhergehenden Beiträgen beschreibe ich mal wie ich es mache bzw. aus grossen Projekten kenne.
Dabei benutze ich insgesammt 4 Stufen, wobei sich je nach Komplexität des Projekts noch weitere Stufen einschieben lassen (z.B. für das Testteam):

1. Entwicklungsumgebung (Debian in VM), das Projekt liegt komplett im Repository (svn, git, ...).
2. Assembly-Test (eine eigenständige Debian VM oder zumindest ein klar abgegrenzter bereich in dem normal nicht entwickelt wird!)
3. Produktiv-Test-Umgebung (Das ist eine Subdomain auf dem Produktiv-Server! z.B. test.domain.de)
4. Produktiv-System (z.B. domain.de)

Weitergereicht werden die Sourcen/Resourcen jeweils via SVN.
Nur wenn alle Fuktionalitäten auf dem jeweiligen System getestet und als fehlerfrei eingestuft wurden, wird das Projekt auf die jeweils nächste Stufe weitergereicht.
Diese Vorgehensweise hat sich in der Vergangenheit immer wieder als 'Lebensretter' bewährt, da schon kleine Unterschiede in den Umgebungen ein system komplett zum Stillstand bringen können (z.B. PHP 5.2.3 zu 5.2.4).

Für jede Migration gilt natürlich:
1. Maintenance ON
2. DB Sichern (mysqldump + zip ist dein Freund :), den Dump am besten in einem tmp-Verzeichniss innerhalb des Themes ablegen.
3. Die gesamte Umgebung Zipen und irgendwo sicher aufbewahren.
4. Alte Pakete durch aktuelle ersetzen (dito Core)
5. update.php ausführen! (ansonsten kann's sein das die DB nicht mehr rund läuft).
6. Testen.
7. Maintenance OFF
8. Testen.
9. Entspannen || Panic ^^

Viele Spass dabei
Peter

Vor allem musst Du daran denken, bei einer Live-Seite den Wartungsmodus zu aktivieren.

Ich mache auch immer zuerst den Core-Update und falls es noch Modul-Updates gibt, diese erst danach. Wenn Du die Core- und Modul-Dateien löschst und nachher beim Upload Core- und Modul-Dateien per FTP auf ein Mal hochlädst, kann es eine ganze Weile dauern, bis die Core-Dateien alle hochgeladen sind und die Wartungsmeldungs-Seite wieder richtig dargestellt wird.

Weitere Probleme habe ich aber bei den letzten Updates nicht mehr gehabt. Gut, wenn Du weißt, dass das Installationsprofil deaktiviert wird, kannst Du da je gezielt gegensteuern (ich habe ehrlich gesagt noch nie Installationsprofile genutzt, aber sollten die nicht auch Updates anbieten, wenn der Kern ein Update hat???). Daher mache ich die Updates auch direkt auf der Live-Seite und mache - wichtig!!! - vorher stets ein Backup der Dateien und der Datenbank.

Nur bei sehr komplexen Projekten würde ich das vorher auf einer Entwicklungsversion testen (insbesondere wenn viele Updates, also Kern und Module, anstehen). Dabei können aber auch nur die ganz groben Schnitzer auffallen - meist laufen bei mir (wenn überhaupt) - nur in den Drupal-Logs oder den Server-Logs irgendwelche Meldungen auf oder an irgendwelchen exotischen Stellen klappt irgendwas plötzlich nicht mehr. Restrisiko, würde ich sagen.

Also, kurzum: Seite in Wartungsmodus, Backups ziehen, Core-Dateien löschen, neue hochladen und update.php aufrufen, Wartungsmodus deaktivieren und fertig. Sollte reichen. Bei Dir vielleicht noch Installationsprofil aktivieren (wie auch immer das geht, wie gesagt, kenne das nicht).

Hey Tobi,

wenn Du erst alles was aktualisiert werden muss (Core+Module+Resourcen) lokal zusammenstellst, dann Zips, das Zip via FTP/SFtp an die passende Stell überträgst (maintenance on) dann Auspacks (direkt in die Verzeichnisse), kannst Du die Zeit in der die Webseite im Wartungs-Modus hängt erheblich reduzieren. Außerdem ist es an der Stelle sicherer falls dir mitten in der Übertragung doch mal die Verbindung wegbricht.

Wie viel Vorsicht jeder bei der Migration von einer auf die nächste Umgebung an den Tag legt, bleibt letztlich jedem selber überlassen :*)
Der bösartigste Fallstrick lauert halt nach meiner Erfahrung bei der Migration von der Entwicklungs-Umgebung (egal wie viele Stufen) in die Prod-Umgebung. Häufig ist die Prod sehr viel aufwendiger gestaltet (Cluster, Reverse-Proxy, Fw, ...). Und je nachdem was Du so anstellst kann es dann schon mal zum Rohrkrepierer kommen wenn plötzlich die Session anders geparkt werden als Du es erwartet hast (:

Für den Hausgebrauch reicht es aber sicherlich, ein ordentliches Backup zu fahren und bei der Migration sorgfältig vorzugehen.
Auf der anderen Seite kostet das Einspielen des Systems auf eine Test-Domain wenig Zeit und kann eine Menge nerven sparen. Oder ist Deine Entwicklungsumgebung eine exakte Kopie der Prod? (Hier mal noch ein nettes Bespiel dazu: https://bugs.php.net/bug.php?id=53971)

Grüße
Peter

Hallo Peter,

Du meinst dann sicher über die Shell das Entzippen machen, oder? Da muss ich gestehen, schrecke ich immer noch etwas vor zurück, aber da ich jetzt auch mit GIT langsam warm werde, werde ich es vielleicht besser mal so probieren, danke für den Tipp.

Für Module nutze ich eh mittlerweile gerne das Update-Modul, das ist ja seit Drupal 7 ähnlich komfortabel, wie man es bei Wordpress schon gewohnt ist.

Viele Grüße,
Tobias

Hallo Tobi, probieren geht über studieren,

1.) mach Dir einfach eine Sicherung auf Deiner FESTPLATTE (SQL oder Mysql etc und das Drupal Verzeichnis) und probiere alles aus.
2.) Lade dann das ganze einfach hoch - WEBSERVER
3.) Du brauchst einen Datenbank Zugang um die SQL etc. hochzuladen. ANBIETER des WEBSERVERS
4.)Überprüfe ob die Passworter und Benutzerdaten von der DATENBANK eingetragen sind in der "settings.php" - wahrscheinlich NICHT.
5.) Lege auf dem Server die Verzeichnisse an "temp" und "cache" - siehe Bild Anhang. - CMD 777
6.) überprüfe das Dateisystem - siehe Bild Anhang. Verzeichnisse müßen vorhanden sein - CMD 777

Für FTP nutze ich: https://filezilla-project.org/
Eventuell muß Du die ". htacces" nachjustieren, da gibts hier jede Menge Hilfe...

Dateien DIREKT mit Filezilla

LGP

FTP, Phpmyadmin und Co sind mir alle zu fehleranfällig (FTP-Datenübertragung kann mal lückenhaft sein, PHPmyadmin kommt mit großen Dumps nicht mehr klar usw.).

Professionell kann man meiner Meinung nach ein Drupal-System nur mit SSH-Zugang und Drush pflegen. Dazu gehört auch das Erstellen von Backups, das Klonen von Drupal zwischen verschiedenen Hosts (auch lokal) und vor allem als Package-Manager für Core- und Contrib-Module für Updates des Codes.

Der Aufruf des Updates-Befehls per Browser (update.php oder auch besser per 'drush updb') führt übrigens evtl. vorhandene Update-Routinen in den Modulen aus, welche oft die Datenbank-Struktur verändern. Das ist nicht nur notwendig, weil die Datenbank dann nicht "rund läuft". Sondern es kann auch komplett Drupal blockieren, wenn Module versuchen z.B. auf Tabellen in der DB zuzugreifen, die nicht vorhanden sind usw.

In jedem Fall sollte man mal ausprobieren, ob man Backups auch wieder einspielen kann in das Live-System. Da geht nämlich bei PHPmyadmin der Spass los. Auch ein paar andere Helferlein auf PHP-Basis funktionieren nicht so gut wie der Terminal-Befehl "mysql", den man direkt nutzen kann oder indirekt über drush. Das Triggern des Drupal-Cron Befehls per Drush ist auch vorteilhaft, da er mit mehr PHP-Ressourcen betrieben werden kann als über den Browser und damit weniger dem Risiko eines Timeouts ausgesetzt ist.

Nachtrag:
Vorsicht bitte auch mit den Datei-Rechten. "777" ermöglicht jedem Benutzer auf einem Server (auch andere Webanwendungen/User) das Lesen, Schreiben und Ausführen. Die Date-Rechte auf den Server müssen zu dessen Konfiguration passen und sollten nur so viel ermöglichen wie nötig.

die neuen version von phpmyadmin kommen sehr gut mit großen dumps zurecht!
andernfalls gibts noch mysqldump
professionell hast du recht, aber für einen normalen nutzer ist ssh und drush in der regel völlig unverständlich und ssh zugang gibts auch nicht üvberall

Im Eingangspost steht die Frage nach der üblichen Vorgehensweise. Und da gibt es dann inzwischen eine übliche professionelle Vorgehensweise und eine übliche Vorgehensweise, die man vllt. als "Hobby-Administration" bezeichnen kann.

Aber ähnlich, wie bei einem großen deutschen Werkzeughersteller, die grüne ("Hobby"-)Linie – die man oft als einzige im Baumarkt findet – schneller mal kaputt geht und die blaue zwar teurer ist, aber aufgrund besserer Komponenten weniger Probleme macht, muss man dann halt mit den Folgen leben.
Gelegentlich möchten Kunden von mir einen professionellen Support auch für Ihren einfachen Webspace haben, der dann oft auch kein SSH beinhaltet. Dann rechne ich mal ganz schnell geschätzten Mehraufwand z.B. für das Warten auf FTP-Transfers usw. pro Monat in Stunden mal Stundensatz vor und dann ist die Bereitschaft für ein etwas größeres Webspace-Paket mit SSH plötzlich ganz groß.
Natürlich ist Drush eine kleine Hürde, aber die ist nicht so groß, wie anzufangen, Module zu programmieren. Aber bevor sich jemand die Zeit nimmt, sich Programmieren anzueignen ist die Investition in das Erlernen eines professionellen Administrations-Werkzeug meiner Meinung nach zunächst besser angelegt.

Phpmyadmin und Co. sind weitere zumeist PHP-basierte Webanwendungen, die Sicherheitslücken haben können. Bei dem PHP-Myadmin, das die Provider oft mit anbieten, kümmern die sich hoffentlich um Sicherheitsupdates und bieten oft auch ergänzenden Schutzmaßnahmen an. Aber um die selbst installierten Helferlein muss man sich selbst kümmern. Im Grunde stehen hier viele Hobbyisten und angebliche Profis schnell im Handlungsschema: Weil es irgendwie funktionieren muss werden irgendwelche Anwendungen oder Module installiert, bei denen die potentiellen Probleme nicht gut abgeschätzt werden können oder vllt, auch einfach egal sind. Ganz konkret: Wenn die Datenbank-Hilfanwendung angreifbar ist, ist auch das Drupal-System nebenan angreifbar.

Ich gehe folgendermaßen vor bei allen Projekten:

1. Im Servercon meines Hosters kann per Click eine sicherung-datum.tar.gz des FTP Inhalts erstellt werden, diese schiebe ich danach in den neu angelegten FTP Ordner sicherung_site.

2. Das gleiche mit Click im Servercon für die DB, diese schiebe ich in den FTP Ordner sicherung_datenbank.

Es ist auch möglich beide Dateien (FTP und DB) mit einem Click in eine Sicherung zu packen, mir ist die Trennung von vornherein lieber.

3. Beide Ordner werden per Putty auf die Testdomain kopiert und entzippt (wobei die Original .tar.gz erhalten bleibt), die DB wird dann per Putty eingespielt.

4. Auf der Testdomain werden alle Module/Core upgedatet und getestet auf Probleme.

5. Wenn o.k., wird die neue DB per Putty auf die eigentliche Domain eingespielt und der FTP Inhalt ebenso.

Wartungsmodus ist bei kleineren Projekten gleich aktiv, wenn keine Probleme erwartet werden, bei größeren teste ich erstmal auf der Testdomain und lasse die eigentliche Site online, da diese Tests dauern können, wenn o.k. wiederhole ich den Vorgang mit dem aktuellen Stand der Site und habe dadurch nicht solange den Wartungsmodus aktiviert.
Das ist hilfreich wenn Probleme erwartet werden, eventuell erst nach Patches gesucht werden muß, diese getestet werden müssen, usw.....

Alle Projekte haben SSH Zugang, ab 9.90 pro Monat bei meinem Provider möglich, ohne SSH würde ich Drupal auch nicht installieren, da das kaum händelbar wäre vom Zeitaufwand wie Carsten ja schon beschrieben hat.

Das Einspielen auch grosser Datenbanken mit Putty geht schnell, das Entzippen der FTP Daten ebenfalls und durch diese Lösung kann ich im Servercon immer schnell auf Knopfdruck beliebig viele getrennte Backups (DB und FTP Inhalt) erstellen, was manchmal bei Zwischenschritten sehr hilfreich ist.

Dazu muß ich aber noch erwähnen das mein Managded Server ermöglicht, das ich auf verschiedenen Domains und damit FTP Zugängen per Putty hin und her kopieren kann,
wenn man also nur 1 SSH Paket hat, würde diese Arbeit wieder im Root Ordner stattfinden und damit würde man bei der nächsten Sicherung auch den Root Ordner (der die Subdomain beinhaltet) auf Knopfdruck mit sichern, beim Entpacken hat man dann also alle Dateien vorliegen und muß nur aufpassen welche als neu zurückgeschoben werden soll, sinnvolle Ordnernamen haben mir dabei sehr geholfen.

Grüße Jenna