Datenbank in einem Backup modifizieren, um ein doppeltes Schlüssel-Tag zu entfernen, damit es bei der Wiederherstellung nicht fehlschlägt

Installation
1

Dies ist eine sehr komprimierte Version meiner letzten 24 Stunden, obwohl es bisher noch nicht funktioniert hat, daher hoffe ich auch, dass jemand unten postet, wo es schief gelaufen ist.

Mein Discourse-Update ist aufgrund eines doppelten Schlüssels fehlgeschlagen, eines meiner Tags ist doppelt vorhanden. Um das Update-Problem zu beheben, musste ich eine neue Discourse-Installation durchführen und dann mein letztes Backup laden, aber das Laden schlägt fehl, da es wegen des doppelten Schlüssels meckert. Also musste ich in das Backup gehen, um das fehlerhafte Tag in etwas anderes zu ändern.

Aus irgendeinem Grund ist das neu gezippte Backup mit dem behobenen Problem des doppelten Tags deutlich kleiner als das Backup, aus dem es stammt, und schlägt fehl, wenn ich versuche, es wiederherzustellen, sodass bei der Neukomprimierung etwas schief gelaufen ist.

1) Backups finden: Um Ihre Discourse-Backups zu finden, können Sie den folgenden Befehl verwenden:

sudo find / -name "*.tar.gz"

Dadurch wird Ihr System nach allen Backup-Dateien mit der Erweiterung “.tar.gz” durchsucht. Standardmäßig sollte es sich in Ihrem Container unter folgendem Pfad befinden: shared/backups/default

2) Eine Kopie erstellen: Sobald Sie das gewünschte Backup gefunden haben, erstellen Sie eine Kopie davon, um sicherzustellen, dass Sie eine Sicherung der Originaldatei haben. Verwenden Sie den Befehl “cp”:

bash

sudo cp /pfad/zum/original_backup.tar.gz /pfad/zur/kopie_backup.tar.gz

3) Die Kopie extrahieren: Extrahieren Sie den Inhalt der kopierten Backup-Datei mit dem Befehl “tar”:

bash

tar -xzvf /pfad/zur/kopie_backup.tar.gz

Dadurch werden die Backup-Dateien in ein temporäres Verzeichnis extrahiert.

4) Tags in der Datenbank bearbeiten: Navigieren Sie zu den extrahierten Backup-Dateien und öffnen Sie die relevante Datenbankdatei mit einem Texteditor. Ich hatte ein Problem mit doppelten “socialmedia”-Tags, was eine erfolgreiche Wiederherstellung verhinderte. In einer großen Datenbank gibt es viele Instanzen von Tags, und wahrscheinlich auch für das spezifische Tag, nach dem Sie suchen. Daher habe ich mit Strg+W in Nano nach ‘immutable socialmedia’ gesucht, was mich direkt dorthin gebracht hat.

sudo nano /pfad/zur/extrahierten_datenbank.sql

Ich habe eine Instanz des “socialmedia”-Tags in “socialmedia2” geändert und dann schnell gesucht, um zu überprüfen, ob es jetzt nur noch einmal vorkommt. Ich kann diese Tags im Admin-Bereich beheben, sobald die Wiederherstellung erfolgreich ist.

5) Neu komprimieren: Nachdem Sie die Backup-Dateien bearbeitet haben, erstellen Sie eine neue Backup-Datei mit dem korrigierten Inhalt. Verwenden Sie den folgenden Befehl, um die geänderten Dateien zu komprimieren:

tar -czvf /pfad/zur/neuen_geänderten_backup.tar.gz /pfad/zum/verzeichnis_mit_geänderten_dateien

6) In die richtige Datei verschieben: Verschieben Sie die neue geänderte Backup-Datei in das entsprechende Verzeichnis, in dem Backups gespeichert werden. Der Standardspeicherort ist normalerweise “/shared/backups/default”:

sudo mv /pfad/zur/neuen_geänderten_backup.tar.gz /shared/backups/default/

7) Dienste stoppen und starten: Bevor Sie das geänderte Backup wiederherstellen, stellen Sie sicher, dass Sie die relevanten Dienste stoppen, um potenzielle Konflikte während des Wiederherstellungsprozesses zu vermeiden. Verwenden Sie den Befehl “./launcher stop app”, um die Discourse-Anwendung zu stoppen:

./launcher stop app

8) Backup wiederherstellen: Um aus dem geänderten Backup wiederherzustellen, verwenden Sie den Befehl “discourse restore” mit dem Pfad zur neuen Backup-Datei:

discourse restore /shared/backups/default/neue_geänderte_backup.tar.gz

Oder Sie können es über /admin auf Ihrer Website tun, da es jetzt im Backup-Bereich erscheinen sollte.

9) Wiederherstellung überprüfen: Nachdem der Wiederherstellungsprozess abgeschlossen war, habe ich überprüft, ob die Änderungen erfolgreich waren, indem ich die Discourse-Anwendung und die Datenbank überprüft habe, um sicherzustellen, dass die doppelten “socialmedia”-Tags entfernt wurden.

10) Dienste starten: Ich habe die zuvor gestoppten Dienste neu gestartet, um die Discourse-Anwendung wieder online zu bringen. Ich habe den Befehl “./launcher start app” verwendet, um die Discourse-Anwendung zu starten:

./launcher start app

11) Temporäre Dateien und zusätzliche Backups löschen: Nachdem das Backup erfolgreich wiederhergestellt wurde, habe ich alle temporären Dateien und zusätzlichen Backups gelöscht, die während des Prozesses erstellt wurden, um Speicherplatz freizugeben. Verwenden Sie den Befehl “rm”, um die Dateien zu entfernen:

sudo rm -r /pfad/zum/temporären_verzeichnis
sudo rm /pfad/zur/kopie_backup.tar.gz
3 „Gefällt mir“
2

Warum?

Warum konnten Sie dies nicht „online“ beheben, indem Sie die App neu gestartet, den Container betreten, Postgres betreten und sich dann sofort um die Dateneingabe gekümmert haben?

1 „Gefällt mir“
3

Ich hatte den Fehler nicht erwartet und hatte bereits die neue Version von Discourse auf meinen Server geladen. Der Fehler mit dem doppelten Schlüssel befand sich im Backup und nicht in der neu installierten Anwendung, aber ich konnte das Backup nicht wiederherstellen, da der Fehler zuerst behoben werden musste.

Also musste ich versuchen, das Tag im Backup zu bearbeiten.

4

Aber hast du den Fehler beim Update gesehen?

Mach dir das nächste Mal das Leben leichter und behebe es direkt.

5

Die App lief nicht und ich konnte sie nicht neu laden, also habe ich auf eine neue Discourse-Version aktualisiert, um das zu beheben. Das bedeutete, dass ich keinen Zugriff auf die Datenbank hatte, außer auf das Backup.

Sicherlich ist dies ein Nischenfall, den ich hier gepostet habe. Die bessere Option wäre gewesen, das Problem zu bemerken und zu beheben, solange ich noch direkten Zugriff auf die App-Datenbank hatte, aber ich habe es verpasst und keine andere Option gefunden.

1 „Gefällt mir“
6

Kein Problem. Zumindest hast du gezeigt, dass es möglich ist, etwas Neues gelernt und anderen eine zusätzliche Option gegeben.

Gute Arbeit! :clap:

3 „Gefällt mir“
7

Danke, obwohl die Originaldatei 128 MB groß war und die neue 29 MB, daher glaube ich, dass das erneute Zippen auf dem Server die Datei aufgrund ihrer Länge abgeschnitten haben könnte.

Dieser Prozess scheint funktionieren zu müssen, aber die Datei, die ich am Ende erhalten habe, konnte nicht verwendet werden, um mein Discourse wiederherzustellen.

1 „Gefällt mir“
8

Der von Ihnen eingeschlagene Weg war riskanter, aber sicherlich machbar? Vielleicht kann jemand mit Ratschlägen zu diesem Problem helfen.

Sie können dies wahrscheinlich wieder vom Backup wiederholen, also …

1 „Gefällt mir“
9

Ist dieses Problem gelöst? Es liest sich wie eine Anleitung, aber es scheint, als ob Ihre Website immer noch kaputt ist.

Vielleicht machen Sie etwas, das ich nicht verstehe, aber normalerweise können Sie einfach ./launcher start app ausführen, um den alten Container zu starten. Gab es einen Grund, warum Sie das nicht tun konnten?

Dann können Sie Rails oder SQL-Tools verwenden, um Ihre Datenbank im alten Container zu reparieren und dann erneut zu versuchen, den Bootstrap/Neubau auszuführen.

Oder vielleicht haben Sie die Datenbank über das hinaus migriert, was Ihr alter Container verarbeiten konnte.

Ich habe ähnliche Eingriffe an einem Backup vorgenommen, als die wiederherzustellende Website ein Jahr oder älter war. Ich glaube, der DB-Dump war klein genug, dass ich ihn in vim bearbeiten konnte.

1 „Gefällt mir“
10

Danke für die Antwort.

Er weigerte sich zu starten, da wir ein paar Upgrades hinterherhinkten. Deshalb habe ich auf die neueste Discourse-Version aktualisiert, indem ich eine neue erstellt und unser altes Backup hochgeladen habe, aber dieses Backup wurde wegen doppelter Schlüssel abgelehnt.

Oder vielleicht haben Sie die Datenbank über das hinaus migriert, was Ihr alter Container verarbeiten konnte.

Ja, wahrscheinlich das. Es ist jetzt ein bisschen verschwommen, was genau ich getan habe, aber ich habe ein paar Dinge unabhängig voneinander aktualisiert, basierend auf den Fehlerbehebungshinweisen hier. Eines davon war, die aktuellste PostgreSQL-Version zu erhalten.

Ich konnte es in vim bearbeiten.

Ich konnte es in Nano bearbeiten, und alles sah gut aus, aber die neu komprimierte Datei war viel zu klein, also ist irgendwo etwas schief gelaufen… vielleicht konnte ich sie nicht in Nano bearbeiten. Es sah zu der Zeit so aus, als hätte es funktioniert.

11

Ich hoffte, jemand würde einen Fehler darin sehen und mich korrigieren, damit es zu einer „Anleitung“ wird.

12

Was ich als Nächstes prüfen würde:

  • Den gesamten Entpackvorgang wiederholen. Packen Sie ihn unverändert. Überprüfen Sie, ob die Zip-Größe dieselbe ist wie zuvor. Wenn nicht, packen Sie vielleicht nicht mit denselben Optionen?

  • Erneut entpacken, Dateigröße der zu bearbeitenden Datei prüfen. Bearbeiten Sie sie, speichern Sie sie, bestätigen Sie, dass die Größe nicht wesentlich verändert wurde.

1 „Gefällt mir“
13

Ein kleines Update. Jemand anderes in meinem Team hat letzte Woche daran gearbeitet, aber keine Lösung gefunden, also habe ich es noch einmal versucht, diesmal durch Bearbeiten der Datenbank auf meinem lokalen System.

Was ich getan habe:

  1. Alten Backup heruntergeladen, das ich wiederherstellen möchte
  2. Dateien mit 7zip entpackt
  3. dump.sql mit Visual Studio Code geöffnet
  4. Duplizierte Tags direkt in der Datenbank gefunden.
  5. Den Tag-Eintrag gefunden, indem ich nach ’ ’ um den Tag gesucht habe. In meinem Fall ‘socialmedia’. Die Tags scheinen die 2. und 3. von unten der gefundenen Instanzen zu sein.

image
image881×406 25.6 KB

  1. Einen bearbeitet, um zu lesen

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. Die dump.sql-Datei in 7zip neu komprimiert
  • Archiv hinzufügen
  • Archivformat .gzip
  1. Die Hauptbackup-Datei neu komprimiert
  • Archiv hinzufügen
  • Archivformat .tar (gzip ist noch nicht verfügbar)

  1. Sie sollten nun eine komprimierte .tar-Backup-Datei sehen

  2. Die .tar-Datei in 7zip komprimieren, um eine .tar.gz-Datei zu erstellen, die dem von Discourse verwendeten Format entspricht

  • Archiv hinzufügen
  • Archivformat .gzip
  1. In Backups hochladen und über den Admin-Bereich wiederherstellen

An diesem Punkt erhalte ich eine Fehlermeldung:

dump-Datei wird extrahiert…
[2023-08-08 15:09:15] EXCEPTION: Datei oder Verzeichnis nicht gefunden @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

Hat jemand eine Idee, was ich im obigen Prozess übersehen habe?
Das Einzige, woran ich denken kann, ist, dass der Pfad, nach dem gesucht wird, das heutige Datum verwendet und nicht das Datum des Backups (ich schreibe dies am 08.08.2023).

14

Dies ist eine Folge meiner früheren Veröffentlichung hier. Ich poste erneut, damit es für andere, die dies in Zukunft tun, leichter zu finden ist, wenn es funktioniert.

Was ich getan habe, um die DB auf meinem Laptop zu bearbeiten:

  1. Alten Backup, das ich wiederherstellen möchte, aus dem Admin-Bereich heruntergeladen
  2. Dateien mit 7zip entpackt
  3. dump.sql mit Visual Studio Code geöffnet
  4. Die duplizierten Tags direkt in der DB gefunden.
  5. Die Tag-Liste gefunden, indem ich mit Anführungszeichen um den Tag gesucht habe. In meinem Fall ‘socialmedia’. Die Tags scheinen die 2. und 3. von unten der gefundenen Instanzen zu sein.

image
image881×406 25.6 KB

  1. Einen bearbeitet, um zu lesen

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. Die dump.sql-Datei in 7zip neu komprimiert
  • Archiv hinzufügen
  • Archivformat .gzip
  1. Die Haupt-Backup-Datei neu komprimiert
  • Archiv hinzufügen
  • Archivformat .tar (gzip ist noch nicht verfügbar)

  1. Sie sollten nun eine gezippte .tar-Datei mit repariertem Backup sehen

  2. Die .tar-Datei in 7zip zippen, um eine .tar.gz-Datei zu erstellen, die dem von Discourse verwendeten Format entspricht

  • Archiv hinzufügen
  • Archivformat .gzip
  1. In Backups hochladen und über den Admin-Bereich wiederherstellen

An diesem Punkt erhalte ich eine Fehlermeldung:

Dump-Datei wird extrahiert…
[2023-08-08 15:09:15] EXCEPTION: No such file or directory @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

Hat jemand eine Idee, was ich in dem obigen Prozess übersehen habe?
Das Einzige, woran ich denken kann, ist, dass der Pfad, nach dem gesucht wird, das heutige Datum verwendet und nicht das Datum des Backups (ich schreibe dies am 08.08.2023).

1 „Gefällt mir“
15

Ich denke, vielleicht ist der genaue Name einer Sicherungsdatei wichtig: Forenname, Datum und Zeitstempel, Versionskennung. Wenn Sie also entpacken, ändern und neu verpacken, würde ich vorschlagen, unter demselben Namen wie das Original neu zu erstellen. Aber behalten Sie natürlich das Original sicher.

1 „Gefällt mir“
16

Ich habe die Beiträge aus dem neuen Thema in dieses hier zusammengeführt, da es einfacher sein wird, dieses Problem für zukünftige Reisende an einem Ort zu verfolgen. :+1:

1 „Gefällt mir“
17

Danke @Ed_S, ich habe den Originalnamen beibehalten, da ich anderswo gelesen habe, dass er wichtig ist. Meine Frage oben bezieht sich darauf, warum das Backup-Restore-Tool gesucht hat und nicht gefunden hat: /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

was das Datum ist, an dem ich die Wiederherstellung durchgeführt habe.

1 „Gefällt mir“
18

Ah, Entschuldigung. Das scheint tatsächlich seltsam zu sein. Es mag sein, dass das temporäre Verzeichnis erwartungsgemäß nach dem heutigen Datum benannt ist, aber es sieht nicht gut aus, dass die SQL-Dump-Datei nicht gefunden wird.

Wenn Sie den Inhalt der Tar-Datei auflisten, sehen Sie diesen Dateinamen dort? In meinem Fall

root@ubuntu-2gb-nbg1-1:/var/discourse/shared/standalone/backups/default# tar vtfz forumname-2023-08-03-HHMMSS-v2023mmddhhmmss.tar.gz dump.sql.gz | head
-rw-r--r-- discourse/www-data 16336925 2023-08-03 05:31 dump.sql.gz
1 „Gefällt mir“
19

Danke Ed, diese Datei existierte nicht. Entschuldige die Verzögerung, ich war eine Weile nicht erreichbar.

Es gibt keine Datei mit dem richtigen Namen dort, also habe ich gerade versucht, manuell eine leere Datei dort zu erstellen:

sudo mkdir -p /var/www/discourse/tmp/restores/default/2023-08-22-121010/

Aber jedes Mal, wenn ich auf Wiederherstellen klicke, sucht es nach einer leicht anderen Datei (die letzten 6 Ziffern). Ich gehe davon aus, dass es nach einem Ordner sucht, der durch einen Zeitstempel generiert wurde, sodass sich jedes Mal, wenn ich auf die Wiederherstellungsschaltfläche klicke, der Ordner, nach dem es sucht, geändert hat.

20

Ich vermute, dass in Schritt 10, wo Sie die Tar-Datei erstellen, etwas schiefgeht. Können Sie das sehen? Können Sie file verwenden, um sie zu beschreiben? Können Sie den Inhalt mit tar tvfz auflisten?

1 „Gefällt mir“