'Wiederherstellen' schlägt fehl: Diskrepanzen können ignoriert werden

Dieses Thema entwickelte sich später ab dem 4. Beitrag zu „Restore Failing“, was jetzt das Hauptproblem ist. Sie können die ersten 4 Beiträge ignorieren.

Ich habe meine Uploads vor Jahren/von Anfang an auf Aws S3 eingestellt.
Auch wenn ich (soweit ich sagen kann) nie die Option aktiviert habe, die S3-Uploads in meine Backups einzubeziehen, habe ich gestern, als ich die Option „Uploads“ in meine Backups einbezog, Folgendes in meinen Protokollen erhalten:

Dies wirft einige seltsame Ungereimtheiten auf, die mich verwirren:

  1. Gestern Abend habe ich in meinen Admin-Einstellungen die Option aktiviert, „Uploads“ in meine Backups einzubeziehen. Als ich dann meinen lokalen Ordner „Shared Uploads“ über WinScp ansah, enthielt er knapp 100 Dateien in nur 1x Ordner (keine anderen 2x, 3x Ordner existieren dort, SS kann bei Bedarf geteilt werden). Warum zeigen die Backup-Protokolle also den Download von etwa 3.000 Dateien an? („Fehler beim Download“ ist ein weiteres Problem in diesen Protokollen, aber das ist ein anderes Thema). Wenn es diese Dateien aus dem lokalen Speicher herunterlädt, woher kommen dann so viele Dateien? Und wenn es von S3 herunterlädt, warum lädt es von dort herunter, weil ich diese Option in der Rails-Konsole nicht geändert habe, um S3-Daten in Backups einzubeziehen, noch habe ich eine ähnliche Option im Env-Abschnitt meiner yml-Datei erstellt.
  2. Dann habe ich heute diese Option in der Rails-Konsole auf „True“ geändert. Und jetzt, als ich den Backup-Job ausführte, zeigte er die gleichen etwa 3,2.000 heruntergeladenen Dateien an, etwa 100 „Fehler beim Download“. Aber als ich in meinem Aws S3-Bucket nachsah, hatte es fast 10 Mal so viele, 32.000 Dateien von etwa 3 GB. Warum lädt es also nicht all diese Dateien herunter?
  3. Gibt es keine Möglichkeit, all diese Daten abzugleichen/zu synchronisieren und möglicherweise festzustellen, welche Diskrepanzen auftreten und wo?
  4. Jetzt bin ich sehr verwirrt, was soll ich tun. Mein ultimatives Ziel ist es, meinen (zu teuren) AWS-Speicher auf eine günstigere Version zu verlagern (Hetzner selbst, wo mein VPS läuft, ist sehr, sehr günstig, sodass ich auch den Speicher meines primären Servers erhöhen kann).

Danke. Bitte leiten Sie mich in eine Richtung.

Selbst wenn mein Ordner „Uploads“ (im Aws S3 Bucket) mehr als 3 GB (3,2.000 Dateien) groß ist, warum sind die Backups dann nur knapp unter 1 GB (mit nur 2,9.000 heruntergeladenen Dateien in das Backup), selbst nachdem die Option „include_s3_uploads_in_backup“ über die Rails-Konsole aktiviert wurde?

Diese Einstellung lädt die Dateien in ein temporäres Verzeichnis herunter und schließt sie in das Backup ein. Sie werden nicht in das Uploads-Verzeichnis gestellt. Um sie in das Uploads-Verzeichnis zu bekommen, müssen Sie das Backup wiederherstellen. Ich würde es auf einem neuen Server tun, damit Ihr ursprünglicher Server intakt bleibt, falls etwas schief geht.

Es scheint, dass einige Dateien fehlen könnten. Haben Sie Beiträge mit fehlenden Bildern? Eine andere Möglichkeit ist, dass die Uploads-Tabelle Uploads enthält, die nicht mehr in Beiträgen referenziert werden, sodass diese fehlenden Bilder keine Rolle spielen.

Wenn es nur etwa 100 sind, ist es wahrscheinlich keine große Sache.

Oder es könnte sein, dass ein Fehler zu einem bestimmten Zeitpunkt Dateien bereinigt (gelöscht) hat, die hätten aufbewahrt werden sollen.

Um die Dateien zu sehen, die es heruntergeladen hat, müssen Sie die Backup-Datei herunterladen und sehen, was sie enthält. Stellen Sie Ihr Backup auf einem neuen Server wieder her, um zu sehen, wie es funktioniert.

1 „Gefällt mir“

Aber der Hauptpunkt ist, warum das Backup nur knapp 1 GB (mit nur 3100 Dateien) beträgt, obwohl der S3-‘Uploads’-Ordner allein 3,2 GB und 32.000 Dateien umfasst. (Backup-Protokolle zeigen deutlich, dass es nur etwa 10 % bzw. 3.000 Dateien heruntergeladen hat).

[Ich finde es sehr umständlich, ein neues Discourse-Setup mit einer anderen Domain zu erstellen, um dies zu testen, obwohl ich es super einfach finde, einen Snapshot zu erstellen und dann, falls nötig, meine, sehr wenig besuchte, Seite innerhalb von 5 Minuten ohne Aufhebens wiederherzustellen.]

Nun, ich dachte, selbst nachdem ich die Option in Rails C geändert hatte, warum nicht auch diese Zeile in yml hinzufügen DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true, in der Annahme, dass dies alle meine Uploads von Aws S3 aufrufen würde.

Aber nachdem ich diese Option in yml geändert, den Container neu erstellt und das Backup ausgeführt hatte, fand ich dieselben Zeilen in den Backup-Protokollen (3000 Medien-Downloads mit rund 100 Fehlern).

Und als ich versuchte, die Wiederherstellung durchzuführen (ich habe noch keine Upload-/S3-Einstellungen in meinen Admin-Einstellungen geändert), gab es einen Fehler.

Full Log:
![image|690x389](upload://fN6fSsRv2l37aN7O2Mxie7kwx8V.png)

Dann wird versucht, die Bilder in Ihren S3-Bucket hochzuladen.

Wenn Sie die Tar-Datei öffnen, sehen Sie, dass sie alle Ihre Bilder enthält, abzüglich der hundert, für die Sie die Fehlermeldung erhalten.

1 „Gefällt mir“

image
Ich habe also S3-Uploads deaktiviert und dann versucht, mein 1 GB großes Backup (Backup ist immer noch auf Aws S3) wiederherzustellen, und es ist wieder fehlgeschlagen. Was kann hier schiefgehen?

Außerdem wurde ich nach fehlgeschlagener Wiederherstellung abgemeldet, und als ich mich wieder angemeldet habe, wurde mir ein Banner angezeigt, dass alle E-Mails von Nicht-Mitarbeitern deaktiviert sind. Und als ich versuchte, über den Link, den ich per E-Mail erhalten habe, auf das Protokoll zuzugreifen, wurde diese Datei nicht gefunden/ist unzugänglich (meine festgelegte Fehlerseite wird angezeigt).

Als ich versuchte, die Wiederherstellung durchzuführen, kurz bevor ich abgemeldet wurde, sah ich diese Protokollmeldungen:

[2024-08-19 04:12:58] 'Bathinda_Helper' hat die Wiederherstellung gestartet!
[2024-08-19 04:12:58] Markiere Wiederherstellung als laufend...
[2024-08-19 04:12:58] Stelle sicher, dass /var/www/discourse/tmp/restores/default/2024-08-19-041258 existiert...
[2024-08-19 04:12:59] Lade Archiv in das tmp-Verzeichnis herunter...

Im nachfolgenden ‘FAILED-restore’-Versuch konnte ich kurz bevor ich abgemeldet wurde, auf den Protokoll-Link klicken. Hier ist er:
log- failed restore.txt (98.9 KB)

Ich habe einige Experimente durchgeführt, die zeigen, dass neue Uploads tatsächlich auf meinem lokalen Ubuntu-Server erstellt werden. Die Wiederherstellung von S3 auf lokal schlägt jedoch fehl. Aber die Sache ist, dass einige Beiträge, die ich überprüft habe, immer noch Bilder von S3 anzeigen (diese fehlen nicht).

Bitte leiten Sie mich an.

Bitte helfen Sie. Die Wiederherstellung schlägt wiederholt fehl.

Außerdem kann ich nach einem fehlgeschlagenen Wiederherstellungsversuch, selbst wenn ich mich mit demselben Administrator anmelde, nicht auf den Anhang ‘Log.txt’ zugreifen. Stattdessen wird die Seite nicht verfügbar / meine Setup-Fehlerseite angezeigt.

Sie könnten versuchen, die Befehlszeile wiederherzustellen und tmux oder screen zu verwenden, damit Sie im Protokoll zurückscrollen können.

1 „Gefällt mir“

Von Ihrem diesem Beitrag habe ich Folgendes versucht, über Tmux, wie Sie es angewiesen haben, aber es schlägt auf diese Weise fehl:

Außerdem, da ich ‘data’- und ‘Web_only’-Container habe, auf welchen soll ich wiederherstellen?

Sie stellen aus dem web_only-Container wieder her, wie Sie es tun.

Sie haben die Wiederherstellung im ersten Befehl erfolgreich aktiviert (ich weiß nicht, warum Sie es auf andere Weise erneut versuchen würden). Führen Sie nun Folgendes aus:

discourse restore

1 „Gefällt mir“

Ich habe tatsächlich versucht, genau dasselbe zu tun wie auf Ihren Screenshots im obigen Beitrag. Wie auch immer, ich werde jetzt nur noch ‘Discourse restore’ machen.

Wie ich es verstanden habe/ich hoffe, ich muss keinen Pfad zur Sicherungsdatei (.tz) angeben, die irgendwo liegt, sie wird sie automatisch aus meinem lokalen Server-Backup-Ordner abrufen.

1 „Gefällt mir“