Datentransfer zwischen zwei Servern nach Drupal-Update auf 8.9.1 [gelöst]

Ich mache das so:

• Public- und private-Filesverzeichnise synchronisieren
• Datenbank exportieren (entweder mit Backup&Migrate oder, wenn das nicht geht, mit mysqldump auf der Kommandozeile.
• Entsprechend beim Import der Datenbank
• falls möglich Backup&Migrate
• oder Datenbank leeren und Import mit drush auf der Kommandozeile (cat /pfad/zum/dbdump.sql | drush sqlc)
• oder Datenbank leeren und Import mit mysql auf der Kommandozeile (mysql --character-sets-dir=utf8 --default-character-set=utf8 -h[hostname] -P[portnumber] -u[user] -p[passwd] [dbname]  < /pfad/zum/dbdump.sql)

Anschließend update.php laufen lassen.

Danke, für die schnellen und genauen Tipps!

Welche Datenbanktabellen schließt du aus, wenn du nur die Daten auf eine neuere Drupalversion übertragen möchtest?

Ich habe festgestellt, dass Drupal 8.9.1 eine neue Datenbanktabelle erzeugt hat: config_import

Ich schließe nur, wie auch Backup&Migrate, die Daten der Cache-Tabellen aus. Die Struktur aller Tabellen muß mitkommen. Wenn 8.9.1 eine neue Tabelle erzeugt hat, sollte die durch den Lauf von update.php wieder erzeugt werden. Das ist der Sinn der Update Funktionen in den Modulen (sowohl core als auch contrib). Im Übrigen meint mein "Datenbank leeren" in der Anleitung das Löschen aller vorhandenen Tabellen.

Zunächst mal möchte ich noch mal betonen, daß man nicht selbst raten sollte, welche Tabellen Sinn machen "transportiert" zu werden. Im Zweifel alles nehmen.

Denn die Datenbank-Struktur unterscheidet sich nicht nur in der Anzahl von Tabellen. Es können via Update-Routinen der Module (core und contrib) auch Tabellen-Spalten erzeugt werden usw. Die Datenbank muss immer zum Code passen.

Downgrades sind bei Drupal auch nicht vorgesehen. Das heißt es geht immer nur vorwärts, ansonsten wird es kompliziert. Aus dem Grund testet man eben auch Code-Updates, so daß das beschriebene Vorgehen mit einem zweiten Server zu arbeiten generell empfehlenswert ist.

Und auf dem Ziel-System sollte man nach erfolgreichen Tests immer noch mal den Wartungsmodus einschalten, um weitere Änderungen zu verhindern, dann ein volles Backup inkl. Datenbank-Strukur durchführen und dann die Datenbank mit dem Update script (empfehlenswert ist drush updb). Und wenn dann trotz Tests noch was schief läuft und man das Backup wieder einspielen möchte, sollte man wie Werner schreibt die Datenbank leeren (oder weil schneller: löschen und neu anlegen) und dann Datenbank-Strukur und -Daten wieder importieren.
Ein einfaches Überschreiben lässt nämlich neue Tabellen unberührt und wenn dann das Update-Script versucht, diese neu anzulegen, wird es übel. Und falls dann das Backup nur Daten enthält, würde es kompliziert werden.

In unseren Systemen testen wir übrigens nächtlich automatisch ein Vollbackup in Kombination mit dem aktuellen Code für die Produktiv-Systeme (via Gitlab CI System) für alle betreuten Produktiv-Systeme.
Denn generell sollten Backups nicht nur gemacht, sondern auch überprüft werden, ob sie vollständig und nutzbar sind. Sonst sind es nämlich keine Backups im eigentlichen Wortsinn, sondern nur irgendwelche Kopien von Daten, die evtl. nicht vollständig sind und nur eine trügerische Sicherheit.

Edit: Tippfehler behoben

Vielen Dank für eure Hilfe!

Ich habe nun folgendes gemacht:

• Modul Backup&Migrate zum Export der SQL Datenbank verwendet
• Import via MYsql-Datenbank
• Files aufgrund der großen Datenmenge manuell überspielt
• PHP und CSS manuell übertragen
• danach update.php ausgeführt
• Hat geklappt :-)