Ist nicht nur 1 Backup pro Tag zu riskant? Wenn dem Server etwas passiert und das letzte Backup gestern stattgefunden hat, was mache ich dann? Sind Benutzer, die sich zwischen gestern und heute registriert haben, nicht mehr registriert? Ich denke, es ist besser, Backups häufiger zu erstellen, vielleicht jede Stunde. Aber im Zweifelsfall muss man die Website vor dem Backup in den schreibgeschützten Modus versetzen? Danke im Voraus!
3 „Gefällt mir“
+1 dafür, erneut. Discourse ist das einzige dynamische System, bei dem man die Datenbank nur einmal täglich automatisieren kann.
Ich erwarte nicht, dass sich dies in absehbarer Zeit im Kern ändern wird. Ich hatte Gespräche über die Änderung des Standards auf mehr als einmal pro Woche, und das wird nicht passieren.
Ich denke, was gut wäre, ist ein Plugin, das eine Website-Einstellung hinzufügt, um nur-Datenbank-Backups in einigen Stunden zu erstellen (es gibt keinen Grund, eine Zillion Kopien von unkomprimierbaren Uploads in all diesen vollständigen Backups aufzubewahren). Wenn Sie interessiert sind, senden Sie mir eine private Nachricht oder fragen Sie auf dem Marktplatz.
2 „Gefällt mir“
Wenn Sie eine bessere Notfallwiederherstellung benötigen, empfehle ich die Lektüre von Discourse mit einem separaten PostgreSQL-Server ausführen und PostgreSQL selbst zu betreiben, wo Sie die genaue Hochverfügbarkeit steuern können, die Sie benötigen, wie z. B. Live-Sync-Replikate, Point-in-Time-Recovery und häufigere Backups.
3 „Gefällt mir“
Darf ich nach dem Grund für diese Richtlinie fragen, ist sie technisch oder eher klassenorientiert? Ein 24-Stunden-Intervall zwischen Backups ist bei stark frequentierten Foren ein äußerst kritisches Problem. Oder ist dies etwas, das Sie nur zahlenden Kunden anbieten?
1 „Gefällt mir“
Verringert der Betrieb von Discourse mit einem separaten PostgreSQL-Server die Geschwindigkeit, da er sich auf einem anderen Server befindet?
1 „Gefällt mir“
Sicher, das ist eine Lösung. Eine eher seltene Lösung unter Apps. In der PHP/MySQL-Welt wäre das Sichern der Datenbank mit Cron wirklich einfach zu machen, aber auch hier – in dieser Welt kann jede App das selbst tun, mit oder ohne ein Plugin.
Ja, ich bin ein bisschen mehr als nur ein durchschnittlicher Endbenutzer 
aber ich habe ein sehr geringes Verständnis dafür, wie Docker, Rails usw. funktionieren, und für mich ist eine Situation, in der alltägliche Aufgaben fast unmöglich sind, wirklich schwer zu verstehen. Sicher, vielleicht liegt es an meinen Einschränkungen, aber ich bin nicht der Einzige, der sich darüber wundert.
Nun. Wir werden in naher oder mittlerer Zukunft keine einfachen Datenbank-Backups bekommen, das habe ich verstanden.
1 „Gefällt mir“
Du kannst PostgreSQL-Backups auch mit Cron einrichten. Nichts anderes hier.
Nicht auf relevante Weise. Jede Discourse-Instanz, die wir hosten, wie diese hier, verwendet eine Datenbank auf einem dedizierten Server.
2 „Gefällt mir“
Ich stelle Ihnen nur zwei Fragen, um Sie besser zu verstehen.
- Ist die Datenbank das Einzige, was Sie benötigen, um alles wiederherzustellen? Sichert das tägliche Backup über die Einstellungen nur die Datenbank?
- Sollte das Forum beim Sichern der Datenbank im schreibgeschützten Modus sein? Oder kann es jederzeit ohne Probleme durchgeführt werden?
Vielen Dank im Voraus!
2 „Gefällt mir“
Einstellungen befinden sich in der Datenbank.
Technisch gesehen möchten Sie auch den Uploads-Ordner und die app.yml-Site-Definition sichern. Dies wird jedoch normalerweise dadurch gehandhabt, dass die app.yml in der Quellcodeverwaltung und die Uploads in einem Objektspeicher-Dienst gespeichert werden.
Kein Schreibschutz erforderlich.
4 „Gefällt mir“
Unter der Annahme, dass ich die Datenbank auf einem separaten Server habe und stündlich Backups dieser Datenbank erstelle. Wenn ich auch aus den Einstellungen im Admin-Panel Backups erstelle, wären nur die Dateien, einschließlich der app.yml-Datei und des uploads-Ordners, im Backup enthalten, aber nicht die Datenbank, oder? @Falco
1 „Gefällt mir“
Das Backup enthält die Datenbank und die Uploads (sofern diese nicht auf S3 liegen). Die Datei app.yml ist nicht im Backup enthalten, da Discourse sie nicht lesen kann.
Was ich den meisten Leuten empfehle, ist, die Backups auf S3 zu speichern und app.yml an einem Ort aufzubewahren, auf den Sie im Notfall zugreifen können. Dann können Sie einen neuen Container mit der Datei app.yml erstellen und ihn über die Befehlszeile wiederherstellen. Wenn Sie jedoch über die technischen Kenntnisse verfügen, um PostgreSQL mit einem anderen Tool zu sichern/wiederherzustellen, und die Bilder auf S3 liegen (oder vielleicht auch auf andere Weise gesichert sind), können Sie einfach den Container neu erstellen und sind wieder einsatzbereit.
Oder vielleicht möchten Sie mehrere ständig gespiegelte PostgreSQL-Server haben und dann automatisch auf das Backup umschalten, wenn der primäre Server ausfällt.
Es gibt unzählige Möglichkeiten, häufigere Backups als die von Discourse bereitgestellten zu ermöglichen. Wenn Sie häufigere Backups benötigen, müssen Sie diese auf andere Weise durchführen.
2 „Gefällt mir“
Ein weiterer wichtiger Punkt sind Risiko und Wartung: Wenn Sie die sofort einsatzbereite tägliche Lösung verwenden, ist diese wahrscheinlich robuster und zuverlässiger als eine Backup-Lösung, als wenn Sie Ihre eigene konfigurieren. Was passiert, wenn mit Ihrer eigenen Lösung etwas schief geht und Sie es erst merken, wenn es zu spät ist? Zumindest bei der Standardlösung testen täglich Hunderte von Websites diese.
Da ich in vier Jahren keine einzige Erfahrung mit Datenbeschädigung auf mehreren Websites hatte, ist das Risiko, das Backup überhaupt erst zu benötigen, ebenfalls gering …
Vielleicht können andere größere Risiken nennen, aber wahrscheinlich ist das größte Risiko, Probleme durch das Auffüllen des Servers? Behalten Sie also den Speicherplatz im Auge? Richten Sie eine Benachrichtigung ein?
3 „Gefällt mir“
Soweit ich das verstehe, ist der beste Weg, alles getrennt zu halten.
Hauptserver für den Betrieb von Discourse. Dann ein Server für PostgreSQL und S3 (oder einen anderen Objektspeicherdienst) für Uploads.
Die Datei app.yml ändert sich meiner Meinung nach nicht oft, sodass Sie sie nur einmal oder höchstens ein paar Mal im Monat speichern müssen.
Dies ermöglicht es Ihnen, Ihre Dateien auch auf organisiertere Weise zu sichern.
Wenn ja, finde ich, dass ihre Entscheidung, keine täglichen Mehrfach-Backups in den Kern zu integrieren, sinnvoll ist. Andererseits werden diejenigen mit komplexen Anforderungen sicherlich spezielle Konfigurationen wie diese vornehmen. Und am Ende müssen Sie nur die Installation (mit der irgendwo gespeicherten app.yml) wiederholen und sie dann wieder mit der Datenbank und dem S3 für die Daten-Uploads verbinden. Die Backups befinden sich separat auf diesen beiden Servern, sodass es für mich einfach zu verwalten ist. Ich finde das eine sehr faire Lösung.
Vielen Dank an alle für die Erklärung.
3 „Gefällt mir“
Es gibt hier einen weiteren Thread: Configure automatic backups for Discourse - #113 by Tris20
@pfaffman hat dort ein paar Empfehlungen mit Links gegeben. Das hat mich zur Kommandozeile geführt, um häufigere Backups zu planen, was für mich eine ziemlich vernünftige Lösung ist:
Beachten Sie, dass Sie mit dieser Lösung alles in einem Python-Skript kombinieren könnten, um gleichzeitig auch eine Kopie der YAML-Datei usw. zu planen.
2 „Gefällt mir“
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.