Probleme mit Multisite-Backups auf S3 – Backups im Stammverzeichnis gespeichert

Installation
1

Ich habe eine Multisite-Instanz auf einer AWS EC2. Ich habe Backups wie folgt konfiguriert:

DISCOURSE_S3_BACKUP_BUCKET: lc-sitename
DISCOURSE_S3_SECRET_ACCESS_KEY: secret-key
DISCOURSE_S3_ACCESS_KEY_ID: key-id
DISCOURSE_BACKUP_LOCATION: s3

Backups für die Multisite-Instanzen werden im Stammverzeichnis des Buckets gespeichert, erscheinen aber nicht in der Liste in der Benutzeroberfläche. Backups für die Hauptseite werden wie erwartet unter default gespeichert. Das bedeutet, dass Backups beim Wiederherstellen unsichtbar sind und nicht gemäß den Einstellungen bereinigt werden.

Der Multisite-Abschnitt sieht wie folgt aus:

        site:
           adapter: postgresql
           database: site
           pool: 25
           timeout: 5000
           host: data
           password: secret
           host_names:
             - community.site.org

Könnte es sein, dass Backups am falschen Ort landen, wenn DISCOURE_USE_S3 nicht gesetzt ist? (Ich habe versucht, use_s3 in discourse.conf zu setzen, aber Unicorn nicht neu gestartet, sondern stattdessen ein Kommandozeilen-Backup ausgeführt, und es wurde trotzdem im Stammverzeichnis und nicht im Namen der Unterseite gespeichert).

Es gab ein Problem mit Uploads auf S3 (möglicherweise Fehlkonfiguration des Buckets), daher ist S3 nur für Backups vorgesehen.

1 „Gefällt mir“
2

Ich habe noch eineinhalb Stunden daran gearbeitet.

Eine der Multisite-Installationen speichert ihre Uploads Backups korrekt im richtigen Verzeichnis, aber zwei tun dies nicht.

Diejenigen, die nicht an den richtigen Ort gelangen, hatten Datenbanken, die von einer Single-Site-Instanz wiederhergestellt wurden. Daher vermute ich, dass etwas in der Datenbank vorhanden ist, das das Backup dazu zwingt, im Stammverzeichnis des Backup-Ordners und nicht im Verzeichnis des Website-Namens (oder dem Standard für die Standard-Website) zu landen.

@gerhard, entschuldige die Störung, aber würdest du dir das kurz ansehen, ob mir etwas offensichtlich Dummes entgeht?

3

Ja, die Upload-Speicherung ist per Design so vorgesehen. Wenn ein Backup von einer einzelnen Instanz stammt, wird es anders wiederhergestellt.

      was_multisite = BackupMetadata.value_for("multisite") == "t"
      upload_path = "/#{Discourse.store.upload_path}/"
      uploads_folder = was_multisite ? "/" : upload_path

Aber ging es hier nicht darum, wo die Backups abgelegt wurden, und nicht darum, wo die Bilder wiederhergestellt werden?

1 „Gefällt mir“
4

Ja.

Das stimmt.

Aber hoppla:

Wie ich (korrekterweise) bereits sagte, verwendet diese Instanz (derzeit?) S3 nur für Backups und nicht für Uploads.

Es sind die Backups von 2 von 3 Sub-Sites, die im Stammverzeichnis des Backup-Buckets abgelegt werden. Die Hauptseite verschiebt sie wie erwartet nach default, und eine der Multisite-Instanzen verschiebt sie in das Verzeichnis sitename.

1 „Gefällt mir“
5

Hmm, das ist ein seltsames Verhalten. Meinst du Backups, die aus dem Browser hochgeladen werden, oder Backups, die vom System erstellt werden?

Ich sehe keinen Grund, warum vom System erstellte Backups am falschen Ort landen sollten. Der Code sieht ziemlich einfach aus.

s3_helper wird mit dem korrekten Bucket und dem Multisite-Namen konfiguriert.

6

Ich meine, dass das Erstellen eines Backups entweder über die Weboberfläche oder die Rake-Aufgabe für zwei der drei Multisite-Hosts (die beide von einem anderen Server migriert wurden) das Backup in das Stammverzeichnis des S3-Buckets hochlädt, anstatt in sitename/backupname.

Das erscheint mir auch bizarr.

Ich werde versuchen, einige puts zu diesen Funktionen hinzuzufügen, um zu sehen, ob ich es nachverfolgen kann.

Ich glaube, ich habe puts für den source_path verwendet und er hatte den korrekten vollständigen Pfad im Betriebssystem, aber wenn er auf S3 hochgeladen wird, ist der Sitename nicht mehr im Pfad enthalten.

Ich werde nächste Woche genauer hinschauen. Die Backups sind vorhanden, sie sind nur nicht dort, wo Discourse sie finden wird.