Configure automatic backups for Discourse

Automatische Backups auf Backblaze B2

Hier ist, wie ich es für eine hypothetische Website eingerichtet habe, die auf example.com gehostet wird.

  1. Erstellen Sie ein Konto bei Backblaze (derzeit ist keine Zahlung für <10 GB erforderlich, was kostenlos ist).
  2. Erstellen Sie einen Bucket (Backblaze > B2 Cloud Storage)
    • Name: $sitename-discourse-$random, aufgefüllt auf 30 Zeichen
      • In diesem Beispiel: example-discourse-g87he56ht8vg
      • Discourse benötigt Bucket-Namen nur aus Kleinbuchstaben, Zahlen und Bindestrichen.
      • Ich empfehle, ihn auf 30 Zeichen oder weniger zu beschränken, da er in der Web-Oberfläche von Backblaze gut ohne Umbruch angezeigt wird.
    • Privater Bucket
    • Verschlüsselung aktivieren (SSE-B2)
    • Objektsperre aktivieren
  3. Erstellen Sie einen Application Key (Backblaze > Konto > App Keys)
    • KeyName: example-discourse
    • BucketName (Zugriff auf Bucket(s) erlauben): example-discourse-g87he56ht8vg
    • Fähigkeiten: Lesen und Schreiben
    • Lassen Sie namePrefix und validDurationSeconds leer.
  4. Konfigurieren Sie die Discourse B2-Einstellungen (Discourse > Admin > Einstellungen)
    • backup_location: s3
    • s3_backup_bucket: example-discourse-g87he56ht8vg
    • s3_endpoint: Dies wird auf der Bucket-Seite angezeigt – stellen Sie sicher, dass Sie https:// voranstellen.
    • s3_access_key_id: (aus dem vorherigen Schritt)
    • s3_secret_access_key: (aus dem vorherigen Schritt)
      • Backblaze zeigt Ihnen den Schlüssel nur einmal an (bei der Erstellung)!
    • Übrigens können Sie diese auch als Umgebungsvariablen in Ihrer Container-YAML festlegen. Dies würde es Ihnen ermöglichen, mit nur dieser Datei und nichts anderem wiederherzustellen:
env:
  ## Backblaze B2 Backups
  # DISCOURSE_BACKUP_LOCATION: 's3' # Auskommentieren, um aus der CLI wiederherzustellen
  DISCOURSE_S3_ENDPOINT: 'https://....backblazeb2.com'
  DISCOURSE_S3_BACKUP_BUCKET: 'example-discourse-g87he56ht8vg'
  DISCOURSE_S3_ACCESS_KEY_ID: '...'
  DISCOURSE_S3_SECRET_ACCESS_KEY: '...'
  # DISCOURSE_DISABLE_EMAILS: 'non-staff' # Auskommentieren, um E-Mails während eines Test-Restore zu deaktivieren
  ## Sie können mit keinen Daten über diese Container-YAML hinaus wiederherstellen.
  ## Kommentieren Sie DISCOURSE_BACKUP_LOCATION oben aus, erstellen Sie den Container (./launcher rebuild ...),
  ## und führen Sie dann dies innerhalb des Containers aus (es wird aus dem B2-Bucket wiederhergestellt):
  ##   discourse enable_restore
  ##   discourse restore <example-com-...tar.gz> # Wählen Sie den Restore-Dateinamen, indem Sie die B2-Web-Oberfläche durchsuchen
  ## Denken Sie daran, die Wiederherstellung danach zu deaktivieren.
  1. Konfigurieren Sie die Backup-Aufbewahrung
    • Discourse:
      • backup_frequency: 1 (tägliche Backups in diesem Beispiel, aber Sie könnten auch wöchentlich machen)
      • maximum_backups: Ignorieren Sie diese Einstellung – lassen Sie Backblaze das erledigen :sunglasses:
      • s3_disable_cleanup: true (Verhindert das Entfernen alter Backups aus S3, wenn mehr Backups als das Maximum erlaubt sind)
    • Backblaze (gehen Sie zu den Einstellungen Ihres Buckets):
      • Objektsperre (Standard-Aufbewahrungsrichtlinie): 7 Tage
      • Lifecycle-Einstellungen (benutzerdefiniert):
        • fileNamePrefix: default/example-com (optional)
        • daysFromUploadingToHiding: 8 Tage
          • Dies sollte Objektsperre + 1 sein
        • daysFromHidingToDeleting: 1 Tag
          um die Aufbewahrung in diesem Beispiel zusammenzufassen:
  • Discourse erstellt alle 1 Tag Backups.
  • Jede Backup-Datei ist 7 Tage nach dem Hochladen auf B2 unveränderlich (Objektsperre). Dies schützt Sie vor Unfällen, Ransomware usw.
  • 8 Tage nach dem Hochladen läuft die Objektsperre für das Backup ab. Da es wieder veränderbar ist, kann eine Lifecycle-Regel die Backup-Datei ausblenden.
  • Der nächste Teil der Lifecycle-Regel löscht jede Datei 1 Tag, nachdem sie ausgeblendet wurde.

Sie erhalten also tägliche Backups. Die Aufbewahrungszeit beträgt eine Woche, während der Backups auf keinen Fall gelöscht werden können. Dann werden Backups 2 Tage später gelöscht. Ein Backup ist also eigentlich etwa 9 Tage lang vorhanden.

Ich hoffe, das hilft jemandem :slight_smile:


Bei näherer Betrachtung ist es vielleicht besser, Discourse die Aufbewahrung handhaben zu lassen (maximum_backups). Auf diese Weise laufen Ihre Backups nicht automatisch ab, wenn Discourse ausfällt. Sie möchten nicht, dass eine Uhr auf ihnen tickt, während Sie versuchen, wiederherzustellen. Wenn Sie diesen Weg gehen würden, könnten Sie in diesem Beispiel maximum_backups=8 und s3_disable_cleanup=false festlegen und keine Lifecycle-Richtlinie in B2 verwenden. Sie würden jedoch immer noch die Objektsperre (7 Tage) verwenden.

Bearbeitung: Tatsächlich glaube ich, dass Sie immer noch eine B2-Lifecycle-Richtlinie benötigen, da Dateien meiner Meinung nach nur ‘ausgeblendet’ und nicht gelöscht werden, wenn ein S2-Client sie löscht. Ich verwende die Richtlinie “Nur die letzte Version der Datei behalten”, die daysFromHidingToDeleting=1, daysFromUploadingToHiding=null entspricht.

Ich denke, Sie sollten darüber nachdenken und entscheiden, welcher Ansatz für Sie der richtige ist.

Übrigens, ich merke, dass es in diesem Beitrag einige Hin und Her gibt. Ich denke, er ist so, wie er ist, informativ, aber wenn jemand möchte, könnte ich einen weiteren, etwas einfacheren Beitrag mit meinen tatsächlichen Empfehlungen erstellen.

6 „Gefällt mir“