Das geht schon lange so – ich habe eine monatliche Erinnerung in meinem Kalender, um diese übrig gebliebenen Dateien zu löschen. Die Backup-Logs sind leer: „No logs yet…“ und nichts in den Fehlerprotokollen weist auf Probleme mit Amazon S3 hin.
Discourse wird regelmäßig aktualisiert und ist derzeit 2.9.0.beta14.
Dies ist eine Standardinstallation, oder? Besteht die Möglichkeit, dass das Betriebssystem (oder etwas anderes) den Sicherungsprozess während des Hochladens unterbricht? Denn selbst wenn die Sicherung fehlschlägt, sollte die lokale Datei am Ende des Prozesses gelöscht werden.
Ich habe eine Zeit lang einen S3-kompatiblen Dienst genutzt, der manchmal dazu führte, dass Backups auf dem lokalen Laufwerk verblieben, aber das war sporadisch.
Sie würden in /var/discourse/shared/standalone/logs/rails/production.log nachsehen. Es würde einfach einen Befehlszeilen-Backup ausführen und sehen, ob es das Verhalten hat.
Produktionsprotokolle reichen nur eine Woche zurück, sodass die älteren „nicht gelöschten“ Backups aus diesem Bereich herausfallen, aber ich werde die zukünftigen im Auge behalten. Der einzige Fehler-Eintrag für Backups war dieser im Protokoll vom 30.11.:
Started GET „/.env.backup“ for 3.236.147.46 at 2022-11-29 19:15:57 +0000
ActionController::RoutingError (No route matches [GET] „/.env.backup“)
Ich sehe ein neues, nicht gelöschtes Backup in /var/discourse/shared/standalone/backups/default, aber nichts in der production.log. Auch in der production_errors.log ist nichts. Wo könnte ich noch nachsehen?
P.S. Ich habe ein Backup über die Befehlszeile ausgeführt und das Backup wurde erfolgreich entfernt - ich werde das noch ein paar Mal versuchen, um zu sehen, ob ich dort einen Fehler bekomme.
Ich habe keinen Erfolg bei der Reproduktion des nicht gelöschten lokalen Backups über die Befehlszeile, aber es passiert weiterhin ein- oder zweimal pro Woche während des nächtlichen Backups. Ich sehe auch keine Ausgabe des Backup-Protokolls in production.log. Sind Sie sicher, dass es dort geschrieben wird, @pfaffman?
Ich glaube schon. Als ich ein ähnliches Problem mit einem anderen S3-Dienst hatte, konnte ich weder in Discourse noch in deren Dienst Fehler finden. Ich gab auf und wechselte zu etwas anderem. Aber du benutzt AWS, S3, das Original, daher bin ich ziemlich überrascht.
Ich habe versucht, es so zu suchen: grep -r "Output file is stored on S3" /var/discourse
da dieser Satz die letzte Zeile der CLI-Backup-Ausgabe ist, aber nichts gefunden wurde.
Besteht die Möglichkeit, dass der Server aufgrund automatischer Updates des Host-Betriebssystems neu gestartet wird? Diese könnten während des Uploads nach S3 erfolgen. Gibt es etwas in den Protokollen Ihres Betriebssystems? Setzen Sie vielleicht die Site-Einstellung backup_time_of_day auf den Standardwert oder eine andere Zeit zurück und prüfen Sie, ob das Problem verschwindet.
Nein, die aktuelle Betriebszeit beträgt 36 Tage. Ich hatte vermutet, dass das gleichzeitig laufende Backup des DigitalOcean-Droplets die Ursache sein könnte, aber das geschieht einmal pro Woche und meine nicht gelöschten Backups treten häufiger auf als das.
Ich werde eine andere backup_time_of_day versuchen. Sie war auf 2:00 UTC eingestellt, mal sehen, ob die Standardeinstellung von 3:30 UTC einen Unterschied macht.
OOOOH! Das ist eine gute Frage. Das würde es erklären. Ich wette, das ist es. Und die Mitte der Nacht ist eine gute Zeit für Backups und Neustarts. Es erklärt nicht ganz, warum das Problem verschwand, als ich zu einem anderen Dienst wechselte, aber vielleicht hatte ich einfach Glück oder was auch immer ich gewechselt habe, war schneller oder so etwas.
Sechzehn Tage später scheint dies die Lösung gewesen zu sein – keine gelöschten Backups mehr. Ich weiß nicht, was den Konflikt verursacht hat, aber das ist jetzt irrelevant.
