Aktivieren Sie die versteckte Einstellung, um S3-Uploads in die Backups einzubeziehen

[Discourse]

Diese Anleitung erklärt, wie Sie eine versteckte Einstellung in Discourse aktivieren, um Amazon S3 (Simple Storage Service) Uploads in Ihre Backups einzuschließen.

Discourse hat die Fähigkeit, Medien-Uploads auf Amazon S3 zu speichern, um Skalierbarkeit und Zuverlässigkeit zu gewährleisten. Diese Uploads sind jedoch standardmäßig nicht in Backups enthalten.

Diese Anleitung behandelt die Aktivierung einer versteckten Einstellung, um S3-Uploads in Backups einzuschließen, mit Optionen zur Konfiguration über die Rails-Konsole oder die Datei app.yml.

Verwendung der Rails-Konsole

Um S3-Uploads über die Rails-Konsole in Backups einzuschließen, können Sie die folgenden Schritte ausführen:

1. Greifen Sie über SSH auf Ihren Discourse-Server zu.
2. Betreten Sie den Discourse Docker-Container, indem Sie Folgendes ausführen:

cd /var/discourse
./launcher enter app

3. Starten Sie die Rails-Konsole:

rails c

4. Aktivieren Sie die Einstellung, indem Sie Folgendes ausführen:

SiteSetting.include_s3_uploads_in_backups = true

5. Beenden Sie die Konsole und den Container, indem Sie Folgendes eingeben:

exit
exit

Diese Änderung wird sofort wirksam. Es sind keine weiteren Maßnahmen erforderlich.

Ändern der Datei app.yml

Sie können diese Änderung auch vornehmen, indem Sie die Datei app.yml im Abschnitt env: ändern.

1. Greifen Sie auf das Discourse-App-Container-Verzeichnis zu:

cd /var/discourse

2. Öffnen Sie die Datei app.yml im Verzeichnis containers:

nano containers/app.yml

3. Fügen Sie unter dem Abschnitt env: die folgende Zeile hinzu:

DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true

4. Speichern Sie die Datei und beenden Sie den Editor.
5. Wenden Sie die Änderungen an, indem Sie die App neu erstellen:

./launcher rebuild app

Damit diese Änderung wirksam wird, müssen Sie den Befehl ./launcher rebuild app ausführen, um die Einstellung anzuwenden.

[pfaffman (Jay Pfaffman)]

@vinothkannans

Damit diese Änderung wirksam wird, müssen Sie den Befehl ./launcher rebuild app ausführen, damit diese Einstellung angewendet wird.

Reicht es nicht aus, den Container zu zerstören und neu zu starten?

[vinothkannans (Vinoth Kannan)]

Ich glaube, Sie müssen es nicht zerstören, ein Neustart reicht aus. Ich werde das später bestätigen.

Auf jeden Fall danke an @pfaffman für seine andere howto Anleitung, die ich als Vorlage für diese verwendet habe.

[pfaffman (Jay Pfaffman)]

@Vinoth Kannan

Ich glaube, Sie müssen nicht zerstören und ein Neustart reicht aus

Ich bin sicher, Sie müssen die Umgebungsvariablen, die auf den Container angewendet werden, zerstören und neu starten, um sie zu ändern.

Wenn sie Upgrades mit dem Docker-Manager durchgeführt haben, gehen diese natürlich verloren, wenn der Container zerstört wird. Deshalb ist der Neubau die sicherste Empfehlung. Vielleicht ist es am besten, den Neubau zu empfehlen, da er am narrensichersten ist.

[Bathinda (Bathinda Helper)]

Warum reicht diese Einstellung nicht aus, um alle Uploads in das Backup aufzunehmen:

[pfaffman (Jay Pfaffman)]

Das schließt lokale Uploads ein, lädt aber keine Dateien herunter, die sich in S3 befinden, um sie in das Backup aufzunehmen.

[Bathinda (Bathinda Helper)]

Ok. Das wusste ich nicht.
Aber was ist der Unterschied zwischen „Lokale Uploads“ und dem Ordner „In S3 gespeicherte Dateien ‚Uploads‘“?

Außerdem, obwohl ich die Einstellung in web_only oder in der Rails-Konsole noch nicht wie oben beschrieben geändert habe, sondern nur die eine Einstellung gewählt habe, die hier beschrieben wird.

Aber als ich vor 10 Minuten ein Backup durchführte, sah es so aus, als hätte es Tausende von Dateien heruntergeladen (was ich vermute, dass es sich nur um meinen AWS S3 Speicher-Bucket handeln könnte, und das Wort „Download“ selbst bedeutet, dass es aus dem entfernten S3-Bucket-Ordner herunterlädt).
Außerdem wird angezeigt, dass viele, sehr viele Dateien Download fehlgeschlagen sind. Ich vermutete also, wenn diese Dateien auf dem lokalen Cloud-Server wären, warum würden diese Dateien dann nicht in das Backup aufgenommen werden? Sehen Sie sich diesen Screenshot an:

[pfaffman (Jay Pfaffman)]

@Bathinda

Aber was ist der Unterschied zwischen „Lokale Uploads“ und dem Ordner „In S3 gespeicherte Dateien (Uploads)“?

Wenn Sie Konfigurieren eines S3-kompatiblen Objektspeicheranbieters für Uploads konfiguriert und Ihre lokalen Uploads nach S3 verschoben haben, dann sind Ihre Uploads dort. Sie werden nicht gesichert, da davon ausgegangen wird, dass S3 gesichert wird und das Herunterladen teuer und normalerweise unnötig ist.

Wenn Sie sie von S3 herunterladen müssen (z. B. wenn Sie auf discourse.org gehostet werden und zu einem anderen Hosting wechseln), benötigen Sie ein Backup, das die auf S3 gespeicherten Dateien enthält.

Warum möchten Sie Ihre Dateien von S3 herunterladen?

@Bathinda

es zeigt Download fehlgeschlagen für viele, sehr viele Dateien. S

Ja, es sieht so aus, als ob die Dateien nicht von S3 heruntergeladen werden können. Ich vermute, dass keine davon heruntergeladen wurde, obwohl es möglich ist, dass Ihre Festplatte voll ist, vielleicht (ich würde einen Festplattenvoll-Fehler erwarten, aber vielleicht auch nicht?).

[Bathinda (Bathinda Helper)]

Danke. Nochmals.

@pfaffman

Warum möchten Sie Ihre Dateien von S3 herunterladen?

Da meine Seite sehr, sehr klein ist, sind die paar Dollar, die jeden Monat mit kleinen Updates steigen, jeden Monat für die AWS S3-Speicherung für mich etwas unpraktisch. Ich werde den Speicherort für ‘Uploads’ (und vielleicht auch für den Ordner ‘backup’) zu anderen Anbietern wie Google One Drive, iDrive, Hetzner usw. verlegen, die günstigere Alternativen sind.
Ich stelle jetzt fest, dass selbst die verschiedenen Speichertypen von AWS (von den am häufigsten genutzten bis zu den Archivierungstypen) mich, wenn ich sie von Anfang an klug gewählt hätte, nur die Hälfte für die gleiche Menge/Anzahl von Dateien gekostet hätten.

Aber das würde ich jetzt tun.

[Bathinda (Bathinda Helper)]

@pfaffman

Ja, es sieht so aus, als ob die Dateien nicht von S3 heruntergeladen werden.

Als ich mich vor Jahren dafür entschied, meine Medien-Uploads in einem AWS S3-Bucket zu speichern, habe ich damals (soweit ich weiß) AUCH ALLE bestehenden, von den Benutzern hochgeladenen Medien nach S3 VERSCHOBEN.

Außerdem habe ich jetzt in meinem Ordner /var/discourse/shared/web_only/uploads/default/optimized/1X nachgesehen, dort befinden sich nur 63 PNG-Dateien und in /var/discourse/shared/web_only/uploads/default/original/1X sind es nur 3. (Außer 1x existieren keine anderen ähnlichen Ordner im Ordner ‘uploads oder default’).

Außerdem habe ich bisher noch keine Option in der Rails-Konsole oder in der YML-Datei geändert, um S3-Uploads in meine Backups einzuschließen. Warum wird dann angezeigt, dass so viele ‘Media Uploads’ von S3 heruntergeladen wurden!!!
Und so viele hochgeladene Dateien nicht heruntergeladen werden konnten? Screenshot hier.

Außerdem ist mein Upload-Ordner auf S3 etwa 3 GB groß (32.000 Dateien), während die Backup-Logs zeigten, dass nur etwa 3.200 Dateien (10 % des Gesamtbestands) heruntergeladen wurden.

Sehr verwirrend.

Gibt es einen ANDEREN Rails-Befehl, um sicherzugehen, dass diese Option nicht vor Jahren aktiviert wurde, als ich zu AWS S3 gewechselt bin?

Jede Erklärung ist hilfreich.