Unsicher, ob hier geantwortet oder ein neuer Beitrag erstellt werden soll: Funktionsanfrage – separate Zeitpläne für „Anhänge einschließen“ vs. „Anhänge nicht einschließen“.
Ich würde tägliche kleine Backups wirklich lieben, möglicherweise sogar mehrmals täglich, da die Datenbank klein ist. Anhänge würden mich nicht am Boden zerstören, wenn ich eine Woche davon verlieren würde, da sie viel begrenzter sind und die Leute ihre Quelle normalerweise wiederfinden können. Dies könnte den Sicherheitsfaktor erhöhen, ohne den Speicher zu überlasten.
Ich habe den Quellcode nicht angesehen, aber es wäre wahrscheinlich eine ziemliche Überarbeitung, da die Wiederherstellungen separate Entitäten sein müssten oder zumindest die Möglichkeit, verschiedene Wiederherstellungspunkte für die 2 Quellen zu haben.
Die empfohlene Vorgehensweise für diese Anfrage ist normalerweise, die anderen Datenbank-Backups mit einem externen Tool zu erstellen.\n\nWenn Sie Uploads nach S3 verschieben, können Sie nur Datenbank-Backups erstellen und sich keine Gedanken über Uploads machen.
Ziemlich vernünftig. Sobald ich anfange, externe Tools in Betracht zu ziehen, denke ich an „externe Wege, um die Dinge wirklich zu vermasseln“, da sie normalerweise mehr Unheil anrichten können als die integrierte idiotensichere (naja, fast) Admin-Konsole.
Wenn Sie viele Sicherungen mit WordPress (einer beliebten Webplattform) wünschen, benötigen Sie ein kostenpflichtiges Sicherungs-Plugin. Vielleicht tun das also nicht alle anderen Apps nativ. Zumindest mache ich das so, obwohl es lange her ist, dass ich diese Entscheidung getroffen habe, also war sie vielleicht schlecht.
Der Grund dafür ist, dass viele Sicherungen Ihren Speicherplatz füllen, was einer der häufigsten Gründe dafür ist, dass eine selbst gehostete Website ausfällt (was meiner Meinung nach in die “teure” Kategorie fällt). Die Idee ist also, dass Sie, wenn Sie über genügend Fähigkeiten verfügen, um eine Unmenge von Sicherungen zu verwalten und Ihren Speicherplatz zu verwalten, dies wahrscheinlich auf verschiedene Weise lösen können. Und wenn Sie stündliche Sicherungen wünschen, sollten dies reine Datenbank-Sicherungen sein und nicht Dutzende oder Hunderte von Kopien Ihrer Uploads.
Stündliche Sicherungen sind also nur sinnvoll, wenn Sie Uploads auf S3 haben, damit Sie dann reine Datenbank-Sicherungen durchführen können, und diese wahrscheinlich nach S3 verschieben, damit Sie sich keine Sorgen um Ihre lokale Festplatte machen müssen. Und dann gibt es nur eine ziemlich kleine Anzahl von selbst gehosteten Websites, die das wollen.
Wenn Sie all das eingerichtet haben, dann wäre ein Plugin, das stündliche reine Datenbank-Sicherungen durchführt, nicht mehr als ein oder zwei Stunden Arbeit, oder vielleicht 2-10, wenn Sie nicht wissen, wie man ein Plugin erstellt und herausfinden müssen, wie man einen stündlichen Job erstellt.
Das stimmt. WordPress selbst kann nicht viel tun. Deshalb gibt es so viele Plugins – schlechte und gute.
Das stimmt nicht. Nur Extras kosten, nicht das Sichern selbst.
Natürlich. Es hat keinen Sinn, Dateien oder das System selbst so oft zu sichern. Die Datenbank selbst ist eine ganz andere Sache. Sie sollte mindestens alle 15 Minuten gesichert werden, wenn viel Traffic vorhanden ist.
Die Frage ist wirklich einfach: Wie viele Inhalte können Sie verlieren?
Wenn der maximal zulässige Datenverlust so gering ist, sollten Sie vielleicht eine Postgres-Replikationslösung in Betracht ziehen, anstatt so häufig Backups zu erstellen.
Gibt es andere Daten, von denen ich nichts weiß? Oder verwenden Sie Daten im größeren Sinne, einschließlich aller Dateien; System, Docker/Discourse/usw., hochgeladen?
Diese Dateien können einfach oder mit geringen Kosten wiederhergestellt werden – nun ja, außer den hochgeladenen, aber dafür haben wir ja S3 .
Dann ist es meist klein, aber es ist das größte, wenn wir das Forum selbst betrachten. Aber aus irgendeinem Grund sind wir wieder hier:\n\n[quote="Jagster, post:4, topic:223312"]\n* Ein tägliches Backup reicht aus\n* Externe Tools wie Skripte und Cron verwenden\n[/quote]\n\nIch würde wirklich gerne hören, ob das Hauptproblem hier technisch oder mental ist. Oder ist dies tatsächlich Teil des Geschäftsmodells und wenn das Backup einfach und funktionierend ist, verliert das Hosting einen Verkaufsargument – und ich weiß nicht, ob es überhaupt solche Verkaufsargumente gibt. Ich versuche nur zu verstehen, warum ein besseres Backup so eine wichtige Frage ist, auch wenn es bereits angefordert wurde.
Es besteht kein Grund zu der Annahme, dass sich eine Strategie oder ein böser Plan dahinter verbirgt. Ich glaube nicht, dass es viel Interesse an häufigeren Backups gibt. Wenn es das gäbe, hätte jemand ein Plugin dafür geschrieben. Das wäre ein paar Stunden Arbeit. Ich sehe den Marketplace nicht mit Anfragen dafür überschwemmt.
Ich denke, es läuft auf Folgendes hinaus:
Bei kleinen Foren verliert man sowieso nicht viele Daten, da es pro Tag nicht viel Neues gibt, sodass sich häufigere Backups nicht wirklich lohnen.
Bei größeren Foren nehmen häufigere Backups Leistung und Speicherplatz in Anspruch.
Bei wirklich großen Foren sollte man sich nach anderen Lösungen umsehen (wie Replikation auf einen Hot-Standby-Datenbankserver).
Vergessen Sie nicht, dass die Wahrscheinlichkeit, tatsächlich ein Backup benötigen zu müssen, ebenfalls sehr gering ist. In der Geschichte von Communiteq (über 8 Jahre) mussten wir nur einmal ein Backup wiederherstellen, und das nur, weil wir ungeduldig waren und nicht ein paar Stunden auf eine Dateisystemwiederherstellung warten wollten.
*) (ausgenommen Wiederherstellungen auf Wunsch des Kunden, bei denen er nur Änderungen rückgängig machen wollte, meist in Nicht-Produktionsforen, und ausgenommen unseres monatlichen Wiederherstellungstests)
Wenn ich hier suche, finde ich also keine Themen, bei denen Discourse aus irgendeinem Grund abgestürzt ist und die einzige Lösung darin bestand, aus einem Backup wiederherzustellen?
Aber schön zu hören, dass Discourse so solide ist, dass es kein aktuelles Backup benötigt. Nun, wir wissen, dass das nicht ganz stimmt.
Der Kreis schließt sich also und wir sind wieder da, wo ich angefangen habe:
Und die dritte Option. Solange ich de facto einige Tests für Discourse durchführe, hier und bei mir selbst, bin ich nicht bereit, für eine solch grundlegende Funktionalität zu bezahlen.
Nun, wir reden hier ohne Kommentare vom Team. Wieder
Das ist der richtige Weg. Bitte folgen Sie Discourse mit einem separaten PostgreSQL-Server ausführen, um Ihre eigene PostgreSQL-Instanz auszuführen und Backup und Hochverfügbarkeit nach Bedarf zu handhaben, wenn das tägliche Backup für Ihren Anwendungsfall nicht ausreicht.
Ich denke 250-500 $, je nachdem, wie konfigurierbar es ist und wie viel Arbeit für das Frontend benötigt wird. Ich habe mir noch nicht angesehen, was dafür nötig wäre. @RGJ könnte es für weniger machen; er hat mich oft überrascht, wie schnell er Dinge erledigen kann.
EDIT: OH, dieses Thema ist geschlossen. Wenn du interessiert bist, kannst du mich kontaktieren oder im Marketplace posten.
.
