Thanks for the hint. That pushed me towards the command line option which we can schedule to do whenever: ![]()
Ich habe das zum Laufen gebracht, aber es scheint, dass die Uploads-Checkbox nicht wirklich benötigt wurde, noch verstehe ich den Zweck. Was ist der Zweck? Das Einzige, was ich will, sind Backups nach S3 anstelle von lokal für meinen Server. Der Server hat nur wöchentliche automatische Backups.
Auch das JSON hatte Probleme. Ich konnte es mit einem anderen Website-Referenz zum Laufen bringen. Allerdings konnten keine Bilder hochgeladen werden, weil ich die Uploads-Checkbox aktiviert hatte (wie hier beschrieben). Das Deaktivieren dieser Box hat das Problem mit dem Hochladen von Bildern für Benutzer und ihre Profilbilder behoben.
Was ist der Zweck des Bild-Uploads? Ich hoffe ernsthaft, dass Bilder in den S3-Backups enthalten sind.
Ich musste die Anweisungen zweimal durchführen, weil ich “Uploads” nicht verstanden habe und nur einen Bucket erstellt habe. Dann musste ich es mit 2 Buckets noch einmal machen, und dann musste ich die Checkbox für Uploads entfernen. Es wäre vielleicht gut, wenn es ein separates, einfacheres Thema für S3-Backups gäbe, und nur für Backups.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:List*",
"s3:Get*",
"s3:AbortMultipartUpload",
"s3:DeleteObject",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:PutObjectVersionAcl",
"s3:PutLifecycleConfiguration",
"s3:CreateBucket",
"s3:PutBucketCORS"
],
"Resource": [
"arn:aws:s3:::classicaltheravadabucket",
"arn:aws:s3:::classicaltheravadabucket/*",
"arn:aws:s3:::classicaltheravadabackupbucket",
"arn:aws:s3:::classicaltheravadabackupbucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:*"
],
"Resource": "*"
}
]
}
Ich denke jedoch, dass dieses Thema aktualisiert werden sollte, um zu empfehlen, die S3-Konfiguration in app.yml und nicht in der Datenbank zu verschieben. Auf diese Weise können Sie eine Wiederherstellung der Datenbank über die Befehlszeile durchführen, ohne die Benutzeroberfläche zu verwenden, und müssen sie nicht mit einem Benutzer und der S3-Konfiguration konfigurieren, bevor Sie eine Wiederherstellung durchführen.
Ich bin mir nicht sicher, wovon Sie sprechen. Meine Backups funktionieren, siehe Bild.
Ich verwende S3, da die Backups von Digital Ocean nur wöchentlich erfolgen und wenn der Server abstürzt und gelöscht wird, ist dies nicht nützlich.
Andererseits hoffe ich, dass die Wiederherstellung von S3 oder einem heruntergeladenen S3-Bucket in Ordnung sein wird.
Ich lade die Bilder nicht hoch und hoffe, dass die S3-Backups einschließlich der Bilder (obwohl sehr wenige) gesichert werden.
Im Allgemeinen: nein.
Es ergibt nicht viel Sinn, Bilder in einem S3-Bucket in einem anderen S3-Bucket zu sichern?
Können Sie weniger missverständlich sein?
Die Anweisungen enthielten 2 S3-Buckets. Das konnte ich nicht zum Laufen bringen.
Ich habe nur einen S3-Bucket. Hoffentlich sind Bilder in diesem Backup enthalten. Ist das richtig?
Ich stelle mir vor, dass lokale Backups genauso funktionieren, richtig?
Bitte beantworten Sie meine Fragen in vollständigen Sätzen. Das Tutorial war auch sehr verwirrend.
Was ist an „nein“ unklar? (Und was ist an „Backups, die gesichert werden“ nicht unklar? ;))
Ich versuche es noch einmal.
Wenn Sie Uploads für S3 konfiguriert haben, sind Uploads nicht in Ihrem Backup enthalten.
Lassen Sie uns den Begriff „Bilder“ anstelle von Uploads verwenden, auch wenn es sich um andere Medien handeln kann.
Auf diese Weise verwechseln wir den Textinhalt nicht mit einem Upload, den ich nach s3 hochlade.
Enthalten die 62 MB großen Sicherungsdateien auf s3, wie in diesem Thread abgebildet und hochgeladen, also keine Bilder?
Wie stelle ich also sicher, dass die Sicherungen diese enthalten?
Enthalten die lokalen Sicherungen auch die Bilder?
Als ich s3 für „Uploads (von Medien)“ konfigurierte, was ebenfalls mehrdeutig war. Niemand konnte Bilder posten, weil sie von s3 abgelehnt wurden…
Gibt es eine Möglichkeit, sowohl lokale als auch tägliche s3-Backups zu haben?
Es wäre mir egal, wenn 5 Tage Bilder verloren gingen, wir sind hauptsächlich eine textbasierte Gruppe.
Aber es wäre mir wichtig, wenn 5 Tage Text verloren gingen. Digital Ocean führt nur 7-tägige Backups durch, wenn Sie dafür bezahlen.
Selbst wenn ich täglich sichern kann, wenn der Droplet gehackt oder beschädigt wird, verlieren wir diese Backups… Ich fange an zu denken, dass s3 nicht viel Mehrwert bietet.
Ich wünschte, es gäbe einfache Backups ähnlich wie bei WordPress, die es mir ermöglichen, auf mein Google- oder Dropbox-Konto zu sichern.
Nein, das ist eine schlechte Idee. Wenn Sie eine Textdatei als Anhang hochladen, ist dies ebenfalls ein Upload und wird zu Verwirrung führen. Und Text in einem Beitrag wird in der Datenbank gespeichert. Daher bleibe ich bei dem Begriff Uploads.
Wenn Ihre Uploads auf S3 gespeichert sind, sind sie nicht in Backups enthalten. In diesem Fall enthalten die Backups nur eine Kopie der Datenbank. Es spielt keine Rolle, ob Ihre Backups lokal oder auf S3 gespeichert sind.
Wenn Ihre Uploads nicht auf S3 gespeichert sind, sind sie in den Backups enthalten. In diesem Fall enthalten die Backups eine Kopie der Datenbank und eine Kopie der Uploads. Es spielt keine Rolle, ob Ihre Backups lokal oder auf S3 gespeichert sind.
Wenn Sie etwas auf S3 speichern, seien es Uploads oder Backups der Datenbank, gehen diese nicht verloren, wenn Ihr DO-Droplet gehackt oder beschädigt wird. Daher verstehe ich Ihren Punkt nicht.
Da sich Ihre Beiträge auf Backups und nicht auf Datei- und Bild-Uploads beziehen, verschiebe ich diese in ein anderes Thema.
Ich möchte meine S3-Backups automatisch nach Glacier verschieben, bin aber verwirrt von den Schritten, die im ersten Beitrag verlinkt sind und nicht viel erklären, vielleicht weil veraltete Dinge darin sind.
Welche Optionen sollten hier angekreuzt werden? ![]()
Darf ich noch einmal fragen, falls jemand diese Schritte durchgeführt hat und davon weiß?
Wissen Sie auch, was diese Schwankungen bei den S3-Gebühren verursacht?
Außerdem, seit dem Start des Forums (September 2020) ist die Größe der Backups um etwa 15 % gestiegen, aber die S3-Rechnungen haben sich verdoppelt, von 2,50 auf 5 . Irgendeine Idee, warum so viel?
Deshalb möchte ich Glacier verwenden.
Bearbeiten: Ich habe die Schritte befolgt, die hier beschrieben sind, und werde sehen, wie es läuft.
Nun, es läuft nicht. ![]()
Meine Lebenszykluskonfiguration:
Mein S3-Bucket:
Es gibt keine Sicherung auf Glacier.
Also… Zwei Fragen an diejenigen, die diesen automatisierten S3-zu-Glacier-Übergang erreichen konnten:
-
Was könnte in meiner Konfiguration falsch sein?
-
Die minimale Speichergebühr in Glacier beträgt 90 Tage. Bedeutet das, dass ich, wenn ich 1 Sicherung pro Tag mache, am Ende jeden Monat für 90 Sicherungen in Glacier berechnet werde?
Wenn dies der Fall ist, ist diese Glacier-Lösung keine gute Idee, es sei denn, ich reduziere meine Sicherungshäufigkeit erheblich.
Wo werden die Backups auf dem VPS gespeichert?
Ich habe dies zum OP hinzugefügt:
Können wir den Ordner für Backups auswählen oder gibt es eine Lösung ohne Programmierung?
Ich benutze Speicherdaten von meinem Hosting-Anbieter, die ich einbinden und wie lokale nutzen kann, aber sie sollen nicht im Standardpfad gespeichert werden.
Wenn Sie möchten, dass es an einem anderen Ort gespeichert wird, müssen Sie dies in Ihrer app.yml ändern.
Automatische Backups auf Backblaze B2
Hier ist, wie ich es für eine hypothetische Website eingerichtet habe, die auf example.com gehostet wird.
- Erstellen Sie ein Konto bei Backblaze (derzeit ist keine Zahlung für <10 GB erforderlich, was kostenlos ist).
- 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.
- In diesem Beispiel:
- Privater Bucket
- Verschlüsselung aktivieren (SSE-B2)
- Objektsperre aktivieren
- Name:
- 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.
- KeyName:
- Konfigurieren Sie die Discourse B2-Einstellungen (Discourse > Admin > Einstellungen)
backup_location:s3s3_backup_bucket:example-discourse-g87he56ht8vgs3_endpoint: Dies wird auf der Bucket-Seite angezeigt – stellen Sie sicher, dass Siehttps://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.
- 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
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:
- 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 ![]()
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.
Wenn Sie diese wie in Konfigurieren eines S3-kompatiblen Objektspeichers für Uploads beschrieben in Umgebungsvariablen einfügen, können Sie Ihre Website mit Ihrer YML-Datei von der Befehlszeile aus auf einen neuen Server wiederherstellen.
Der Rest scheint ein guter Plan zu sein.
discourse restore <backup.tar.gz>
Dies wird in Ihrem Bucket nachsehen, wenn Sie die Umgebungsvariablen gesetzt haben? Ziemlich cool, wenn ja.
Und in diesem Fall könnten Sie sie wahrscheinlich auch manuell mit export in bash setzen, falls Sie aus irgendeinem unwahrscheinlichen Grund wiederherstellen müssen. Das heißt, wenn Sie aus irgendeinem Grund keine Geheimnisse in Ihrer Container-YML aufbewahren möchten.
Nur zur Bestätigung, sobald ich zu S3-Backups gewechselt bin und getestet habe, dass sie funktionieren, kann ich den Inhalt dieses Ordners sicher löschen, um den belegten Speicherplatz zurückzugewinnen?




