Ich habe über den schlimmsten Fall nachgedacht: Einer Ihrer Administratoren wird gehackt – ein Hacker kann dann viel Schaden anrichten, aber auch Ihre Backups an einem externen Speicherort über das Backups-Dashboard löschen. Dies könnte Ihre Discourse-Instanz komplett zerstören und Administratoren ohne Backup zurücklassen (falls ein Administrator nur die Discourse-Backup-Funktion und keine andere 3-2-1-Backup-Regel verwendet).
Wäre es eine Idee, zu verhindern, dass Benutzer Backups über die Benutzeroberfläche löschen können? Wenn wir Backups löschen wollen, können wir uns bei unserem externen (S3) Dienst anmelden und von dort löschen.
Mit dieser Funktion müssten wir keine alternativen Backup-Methoden verwenden und könnten uns mit einem guten Gefühl auf die integrierte Backup-Funktion verlassen.
Viele Leute haben ihre Websites, die ausfallen, weil ihre Festplatte voll ist, und sie müssen wirklich in der Lage sein, Backups zu löschen, um Speicherplatz freizugeben.
Wie können sie auf die Website zugreifen, wenn sie nicht erreichbar ist? Sie müssen immer noch einen anderen Weg (SSH) einschlagen, wenn ihre Website wegen Speicherplatzproblemen nicht erreichbar ist.
Das andere Problem ist, dass Discourse zum Lösen Ihres Problems niemals Backups löschen dürfte, da es diese sonst kürzen könnte und der böswillige Administrator die Anzahl auf 1 setzen und dann eines löschen könnte, um es zu vernichten.
Wenn Sie S3-Backups nur über das S3-Panel löschen möchten (wo Sie wahrscheinlich keinen böswilligen Administrator haben?), ändern Sie Ihre S3-Berechtigungen so, dass Discourse sie nicht löschen kann.
Dies könnte eine Alternative sein. In meinem Fall verwende ich jedoch Vultr Object Storage, wo dies keine Option ist. Ich werde mir andere Dienste ansehen oder einfach eine rclone-Übertragung zu GDrive als Failover-Lösung in Betracht ziehen.