Discourse automatische Backups konfigurieren

[Discourse]

Diese Anleitung erklärt, wie Sie automatische Backups für Discourse konfigurieren, einschließlich Speicheroptionen auf lokalen Servern und S3-kompatiblem Speicher.

Erfahren Sie, wie Sie automatische Backups für Ihre Discourse-Plattform einrichten.

Diese Anleitung behandelt die Konfiguration automatischer Backups, deren Speicherung auf lokalen Servern oder S3-kompatiblem Speicher und die Verwaltung von Aufbewahrungsoptionen wie Amazon Glacier.

Automatische Backups konfigurieren

1. Navigieren Sie zu den /admin-Einstellungen.
2. Wählen Sie den Abschnitt Backup (Sicherung).
3. Legen Sie backup_frequency auf das gewünschte Intervall in Tagen fest. Der Standardwert ist 7 (wöchentlich). Setzen Sie ihn auf 1 für tägliche Backups oder auf 0, um automatische Backups zu deaktivieren. Das Maximum ist 30.

backup_frequency100%75%50%

Zusätzliche Backup-Einstellungen

• backup_time_of_day — Die Tageszeit (UTC), zu der Backups ausgeführt werden. Standard: 3:30.
• backup_with_uploads — Schließt Uploads in geplante Backups ein. Standard: aktiviert. Wenn dies deaktiviert wird, wird nur die Datenbank gesichert.
• maximum_backups — Die maximale Anzahl der aufzubewahrenden Backups. Ältere Backups werden automatisch gelöscht. Standard: 5.
• remove_older_backups — Entfernt Backups, die älter als die angegebene Anzahl von Tagen sind. Leer lassen, um dies zu deaktivieren.

Backups auf dem lokalen Server speichern

Standardmäßig werden Backups auf Ihrem lokalen Server gespeichert. Für selbst gehostete Instanzen finden Sie diese unter /var/discourse/shared/standalone/backups/default.

Backups auf S3-kompatiblem Speicher speichern

Verwendung des Admin-Panels

1. Erstellen Sie einen S3-Bucket.
2. Legen Sie s3_backup_bucket im Admin-Panel fest.

• Folgen Sie den Schritten unter Einrichten von S3-Uploads.

3. Konfigurieren Sie s3_access_key_id, s3_secret_access_key und s3_region.
4. Setzen Sie backup_location auf „S3“.

WARNUNG

Das Speichern von Backups und regulären Uploads im selben Bucket und Ordner wird nicht mehr unterstützt und wird nicht funktionieren.

Der Pfad s3_backup_bucket sollte nur für Backups verwendet werden. Wenn Sie einen Bucket verwenden möchten, der andere Dateien enthält, stellen Sie sicher, dass Sie beim Konfigurieren der Einstellung s3_backup_bucket ein Präfix angeben (Beispiel: my-awesome-bucket/backups) und stellen Sie sicher, dass Dateien mit diesem Präfix privat sind.

Von nun an werden alle Backups zu S3 hochgeladen und nicht mehr lokal gespeichert. Der lokale Speicher wird nur für temporäre Dateien während Backups und Wiederherstellungen verwendet.

Gehen Sie zum Tab Backups im Admin-Dashboard, um die Backups zu durchsuchen – Sie können sie jederzeit herunterladen, um ein manuelles Offsite-Backup durchzuführen.

Verwendung von Umgebungsvariablen in app.yml

Sie können S3-Backups auch mithilfe von Umgebungsvariablen in app.yml konfigurieren. Weitere Informationen finden Sie unter Konfigurieren eines S3-kompatiblen Objektspeichers für Uploads.

Beachten Sie, dass der obige Artikel die S3-Einrichtung für Backups und für Datei-/Bild-Uploads in app.yml behandelt. Wenn Sie S3 nur für Backups (und nicht für Uploads von Dateien/Bildern) verwenden möchten, können Sie die folgenden Parameter aus Ihrer app.yml-Konfiguration weglassen:

• DISCOURSE_USE_S3
• DISCOURSE_S3_CDN_URL
• DISCOURSE_S3_BUCKET

In diesem Fall müssen Sie auch den Schritt after_assets_precompile nicht konfigurieren, ebenso wenig wie ein CDN.

Stellen Sie sicher, dass Sie alle anderen erforderlichen Parameter für Ihren Speicheranbieter einschließen, wie im Artikel erwähnt. Hier ist ein Beispiel für eine Konfiguration, die S3 nur für Backups aktiviert (für Scaleway S3):

DISCOURSE_S3_REGION: nl-ams
DISCOURSE_S3_ENDPOINT: https://s3.nl-ams.scw.cloud
DISCOURSE_S3_ACCESS_KEY_ID: my_access_key
DISCOURSE_S3_SECRET_ACCESS_KEY: my_secret_access_key
DISCOURSE_S3_BACKUP_BUCKET: my_bucket/my_folder
DISCOURSE_BACKUP_LOCATION: s3

Archivierung in kostengünstigerem Speicher

Beachten Sie, dass Sie bei AWS S3 auch eine automatische Verschiebung in einen Glacier-Bucket mithilfe einer Lebenszyklusregel aktivieren können, um Ihre S3-Backupkosten niedrig zu halten. Andere Speicheranbieter haben oft ein ähnliches Angebot.

[olivermark83 (Oliver Mark)]

You are able to Archive Backups from your S3 Bucket to Glacier.
It is cheaper, but an Restore attemps more Time.

This Site will Help you to reduce Backup costs.:

Archiving Amazon S3 Data to Amazon Glacier | Amazon Web Services

[Frez (FOSS dev/hacker)]

@codinghorror

Note that you can also enable an automatic move to Glacier bucket lifecycle rule to keep your S3 backup costs low.

Setting this up can be rather confusing. Here’s a simple guide to help you out.

• Log into your Discourse admin panel
• Configure daily backups
• Set maximum backups to 7
• Log into your Amazon Web Services account
• Go in the S3 Dashboard
• Open the bucket containing the backups
• Click on the properties tab
• Activate versioning
• Open the Lifecycle menu
• Add a rule for the whole bucket
• Set current version to expire after 15 days
• Set previous version to
• Archive to Glacier after 1 days
• expire after 91 days
• Save and logout

How it works

Versioning will keep backups automaticly deleted by Discourse. One day after beeing deleted it will be moved to the Glacier storage. After 91 days it will be delete from the Glacier storage.

Warning

Amazon charge you for item stored in Glacier for 90 days even if you delete them before. Make sure your Glacier Lyfecicle keep your file at least 90 days.

[MarcP]

I may have missed this, but how to I make sure a bucket for backups is private the proper way? Setting up file and image uploads to S3 doesn’t seem to be described here.

[Alex_P]

@Frez

Set current version to expire after 15 days

Looks like there is no such option anymore.

UPD: ah, now it’s split into 2 steps of this wizard.

So I guess it should be like this:

[jorymorrison]

Does S3 backup functionality play nice without IAM access key and secret if using AWS roles assigned to the instance and s3 use iam profile is enabled in the settings menu?

Edit: The answer is YES! Just ensure you have region set appropriately.

[nathank (Nathan Kershaw)]

@misterjtc

Ich bin etwas verwirrt darüber, wie man diesen Leitfaden auch zur Konfiguration von Backups verwendet.

Ich habe das getan, was meiner Meinung nach sinnvoll war, aber ich habe mich unterwegs etwas verirrt und erhalte nun die Meldung „Zugriff auf den Backup-Speicher fehlgeschlagen: Zugriff verweigert".

Ich hatte das gleiche Problem, das gelöst wurde, indem ich ein paar Zeilen zum Richtlinien-Dokument hinzugefügt habe:

"Resource": [
        "arn:aws:s3:::your-uploads-bucket",
        "arn:aws:s3:::your-uploads-bucket/*",
        "arn:aws:s3:::your-backups-bucket",
        "arn:aws:s3:::your-backups-bucket/*"
      ]

Sollte dies dem OP hinzugefügt werden (der keine Wiki ist)? Oder vielleicht im OP von Set up file and image uploads to S3?

[pfaffman (Jay Pfaffman)]

@codinghorror

Sie möchten also alle Ihre Discourse-Daten täglich automatisch sichern?

Gibt es einen guten Grund, warum tägliche Sicherungen nicht standardmäßig aktiviert sind?

Korrekturbedürftige Punkte im Originalbeitrag

Etwas zum Verschieben von S3-Sicherungen nach Glacier hinzufügen?
Den S3-Teil löschen und auf Configure an S3 compatible object storage provider for uploads verlinken

[codinghorror (Jeff Atwood)]

@pfaffman

Gibt es einen guten Grund, warum tägliche Backups nicht standardmäßig aktiviert sind?

Das wäre übertrieben und teuer. Aus demselben Grund, aus dem wir nicht empfehlen, alle 500 Meilen das Öl im Auto zu wechseln.

[pfaffman (Jay Pfaffman)]

@codinghorror

Das wäre übertrieben und teuer.

Sichern Sie Ihre Server einmal pro Woche?

Ich denke, Ihre Analogie mit dem 500-Meilen-Ölwechsel wäre eine gute Antwort auf die Frage, warum man nicht 30 Backups aufbewahrt, aber hier ergibt sie für mich keinen Sinn.

Meinen Sie nicht, dass die meisten Menschen, wenn sie ohnehin 5 Backups vorhalten, lieber tägliche Backups hätten, sodass sie im Falle einer Wiederherstellung höchstens einen Tag an Daten verlieren? Der einzige Fall, an den ich mich erinnere, in dem ein älteres Backup nützlich war, war, als Bilder aus „tombstone

[codinghorror (Jeff Atwood)]

@pfaffman

Sichern Sie Ihre Server einmal pro Woche?

Ja, das ist korrekt, für meine selbst gehosteten Server.

Wenn Sie andere Einstellungen bevorzugen, können Sie diese problemlos von den Standardwerten ändern. Was hindert Sie daran, dies zu tun?

[pfaffman (Jay Pfaffman)]

@codinghorror

Ja, das ist korrekt, für meine selbst gehosteten Server.

Na, wenn das mal nichts ist!

@codinghorror

Was hindert dich daran?

Ich räume Themen wie dieses hier auf. Wenn die Standardwerte geändert würden, wäre das gar nicht nötig!

Ich bin überzeugt, dass die Standardwerte nicht geändert werden, also werde ich weitermachen. :wink

[codinghorror (Jeff Atwood)]

Einmal pro Woche ist ein guter Ausgangspunkt und eine solide Standardoption.

[Discoursecurious]

@nathank

@misterjtc

Ich bin etwas verwirrt darüber, wie man diesen Leitfaden auch zur Konfiguration von Backups verwendet.

Ich habe das getan, was für mich sinnvoll erschien, bin aber unterwegs etwas den Überblick verloren und erhalte nun die Meldung „Zugriff auf den Backup-Speicher fehlgeschlagen: Zugriff verweigert“.

Ich hatte dasselbe Problem, das durch das Hinzufügen einiger Zeilen zum Richtlinien-Dokument behoben wurde:

"Resource": [
        "arn:aws:s3:::your-uploads-bucket",
        "arn:aws:s3:::your-uploads-bucket/*",
        "arn:aws:s3:::your-backups-bucket",
        "arn:aws:s3:::your-backups-bucket/*"
      ]

Sollte dies dem Eröffnungsbeitrag (der kein Wiki ist) hinzugefügt werden? Oder vielleicht dem Eröffnungsbeitrag von Einrichtung von Datei- und Bild-Uploads zu S3?

Ich hatte genau dasselbe Problem!

Ich schlage vor, auch im Eröffnungsbeitrag einen Hinweis dazu aufzunehmen!

[jessicah (Jessica Hamilton)]

Es wäre schön, wenn dies zum Hochladen bei einem anderen S3-kompatiblen Anbieter genutzt werden könnte, wie z. B. einem selbst betriebenen MinIO.

[pfaffman (Jay Pfaffman)]

Wenn du MinIO verwenden möchtest, siehe Verwendung von Objektspeicher für Uploads (S3 & Klone). Wenn du unterschiedliche Dienste für Backups und Assets benötigst, hast du Pech gehabt (obwohl es Möglichkeiten gibt, Trigger einzurichten, um Daten von einem Bucket in einen anderen zu kopieren).

[jessicah (Jessica Hamilton)]

Nein, nur für Backups, damit diese automatisch auf einen anderen Rechner in meinem Netzwerk übertragen werden.

[pfaffman (Jay Pfaffman)]

Dann ist der von mir verlinkte Leitfaden genau das, wonach du suchst.

[Tris20 (Tristan)]

Ist es möglich, häufiger als einmal pro Tag zu sein? Ich möchte keine Annahmen treffen und die Backup-Häufigkeit lieber als Gleitkommazahl festlegen.

[pfaffman (Jay Pfaffman)]

Wenn du häufigere Backups benötigst, musst du sie extern durchführen.