Ich verwende Cloudflare R2 für Medien-Uploads, glaube aber, dass es nicht zum Sichern der Datenbank funktioniert. Welche Verzeichnisse muss ich mit rclone sichern?
Sie finden das folgende Thema hilfreich
Discourse-Dateien/Verzeichnisse, die für ProtonDrive gesichert werden sollen (neben R2/S3-Medien)
Schritt 1 – Was upload:// bedeutet
upload://
Kommentar
Discourse speichert nur den Verweis upload://<hash> im Beitrag-Inhalt (roh/gekocht). Zur Back-End-Zeit oder beim Rendern konsultiert Discourse seine Datenbanktabellen (wie uploads, post_uploads usw.), um diese Hashes auf tatsächliche URLs oder Pfade aufzulösen, je nachdem, wo Uploads gespeichert sind (lokal, CDN, S3/R2 usw.).
Schritt 2 – Wo das im Container landet
/shared/uploads/default
Kommentar
In der Standard-Docker-Installation (mit launcher und app.yml) wird /shared im Container vom Host /var/discourse/shared/standalone gemountet. Alles, was Discourse persistent schreibt – einschließlich Uploads, Protokolle, Backups usw. – befindet sich unter /shared.
Schritt 3 – Der Pfad im Host-Dateisystem
/var/discourse/shared/standalone/uploads/default
Kommentar
Wenn Sie keine externen Uploads (S3/R2) verwenden, ist dies der Hauptpfad, den Sie mit ProtonDrive synchronisieren müssen, um hochgeladene Beitragsmedien zu erhalten. Wenn Sie S3/R2 verwenden, werden die meisten Uploads nicht hier sein, aber einige Dateien (z. B. optimierte Varianten, Tombstones) können verbleiben. Entscheiden Sie, ob Sie diese auch sichern möchten.
Schritt 4 – Die Docker-Volume-Zuordnung (app.yml)
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
Kommentar
Alles unter /shared im Container wird zu /var/discourse/shared/standalone auf dem Host. Wenn Sie diesen Baum sichern, erhalten Sie Uploads, Backup-Tarballs, Protokolle und (optional) PostgreSQL-Daten, wenn sie auf der Festplatte gespeichert sind (obwohl die Backup-Tarballs im Allgemeinen für die Wiederherstellung ausreichen).
Konkrete Ziele für die Sicherung (lokaler Speicher)
Minimales Set (wenn Sie den Tarball-Backups von Discourse vertrauen):
/var/discourse/shared/standalone/backups/ # Von Discourse generierte vollständige Backups (Tarball .tar.gz-Dateien)
/var/discourse/shared/standalone/uploads/ # Nur wenn Sie Uploads lokal speichern
Kommentar
- Der Tarball-Backup bezieht sich auf die .tar.gz-Datei, die mit der Discourse-Backup-Funktion erstellt wurde. Sie enthält den gesamten Datenbank-Dump, die Site-Konfiguration, Themes und (optional, wenn ausgewählt) alle lokalen Uploads. Sie enthält keine Medien, die auf externem S3/R2 gespeichert sind; nur die Datenbankeinträge, die darauf verweisen.
- Wenn Ihre Uploads auf S3/R2 liegen, benötigen Sie lokal möglicherweise nur
/backups/und einen separaten Prozess zur Sicherung Ihres Object Storage Buckets.
“Alles, was ich jemals brauchen könnte”-Set (Dateisystem-Kopie):
/var/discourse/shared/standalone/backups/ # Vollständige Discourse-Backups (Tarballs)
/var/discourse/shared/standalone/uploads/ # Lokale Uploads/Medien (wenn nicht S3/R2)
/var/discourse/shared/standalone/log/rails/ # (Optional) Rails-Protokolle – nützlich für forensische Zwecke
/var/discourse/shared/standalone/tmp/backups/ # (Optional) temporärer Backup-Staging-Bereich (normalerweise leer)
/var/discourse/shared/standalone/postgres_data/ # (Optional) rohes PostgreSQL-Datenverzeichnis – normalerweise nicht notwendig
/var/discourse/containers/ # Ihre app.yml und alle Container-YMLs (Konfiguration)
/etc/letsencrypt/ # (Optional) TLS-Zertifikate, wenn SSL auf dem Host beendet wird
Kommentar
- Rohe PostgreSQL-Daten sind normalerweise nicht erforderlich, da das Tarball-Backup einen logischen Datenbank-Dump enthält, der für die Wiederherstellung sicherer ist.
- /containers ist klein, aber entscheidend für die Notfallwiederherstellung – es enthält Ihre Einstellungen und Volume-Zuordnungen.
- TLS-Zertifikate sind nur relevant, wenn Sie SSL außerhalb des Containers durchführen.
Schnelle Einzeiler-Zuordnung
upload://
↓
/shared/uploads/default (innerhalb von Docker)
/var/discourse/shared/standalone/uploads/default (auf dem Host)
Kommentar
Wenn Sie S3/R2 verwenden:
- Sichern Sie Ihren S3/R2-Bucket separat (z. B. mit Rclone).
- Sichern Sie trotzdem
/backups/(Tarballs, die DB und Konfiguration, Site-Uploads enthalten, aber keine externen Medien) und/containers/.
TL;DR für den ProtonDrive-Thread
- Lokale Uploads? Sichern Sie:
- /var/discourse/shared/standalone/uploads/
- /var/discourse/shared/standalone/backups/ # (enthält Tarball-Backups als .tar.gz)
- S3/R2-Uploads? Sichern Sie:
- /var/discourse/shared/standalone/backups/ # (Tarball-Backups: DB/Konfiguration/Uploads-Tabelle)
- Ihren S3/R2-Bucket mit einem anderen Tool
- Optional: /containers/, /log/rails/ und postgres_data für vollständige DR-Abdeckung
Kommentar
Tarball-Backup: Die .tar.gz-Datei, die vom Discourse-Backup-System erstellt wurde und einen logischen Datenbank-Dump, Themes, Konfigurationen und (optional) lokale Uploads enthält, aber niemals externe S3/R2-Medien.
Ich möchte hervorheben, dass jedes Mal, wenn ich den Server gewechselt habe und mich auf Tarball-Backups verlassen habe, um lokale Uploads zu sichern, die Standard-app.yml anders war.
Daher ist es wahrscheinlich besser, Teile der alten app.yml manuell zu kopieren und Teile der neuen Datei zu ersetzen.
Ich würde gerne docker cp ausprobieren, um eine Sicherungsdatei aus einem Discourse-Container zu holen und auf das Host-System zu übertragen, falls das notwendig ist.