Backups nehmen mein Forum immer wieder herunter

[piffy]

Ich durchlaufe immer wieder Zyklen, in denen die Erstellung von Backups meine Website aufgrund von Speicherplatzproblemen lahmlegt.

Ich habe es so eingerichtet, dass ich ein separates DO-Volume verwende, um die Backups und Uploads zu speichern. Das Volume ist 300 GB groß.

Meine Backup-Einstellungen:

Das Problem tritt seit Monaten immer wieder auf. Ich erhalte Nachrichten über fehlgeschlagene Backups in der Admin-Inbox (siehe unten).

Kein Speicherplatz mehr auf dem Gerät

[2024-02-14 03:43:34] Finalizing backup...
[2024-02-14 03:43:34] Creating archive: elite-fourum-2024-02-14-033845-v20240204204532.tar.gz
[2024-02-14 03:43:34] Making sure archive does not already exist...
[2024-02-14 03:43:34] Creating empty archive...
[2024-02-14 03:43:34] Archiving data dump...
[2024-02-14 03:43:58] Archiving uploads...
[2024-02-14 03:55:03] Removing tmp '/var/www/discourse/tmp/backups/default/2024-02-14-033845' directory...
[2024-02-14 03:55:03] Gzipping archive, this may take a while...
[2024-02-14 04:25:38] EXCEPTION: /var/www/discourse/lib/discourse.rb:138:in `exec': Failed to gzip archive.

gzip: /var/www/discourse/public/backups/default/elite-fourum-2024-02-14-033845-v20240204204532.tar.gz: No space left on device

[2024-02-14 04:25:38] /var/www/discourse/lib/discourse.rb:172:in `execute_command'
/var/www/discourse/lib/discourse.rb:138:in `exec'
/var/www/discourse/lib/discourse.rb:34:in `execute_command'
/var/www/discourse/lib/backup_restore/backuper.rb:253:in `create_archive'
/var/www/discourse/lib/backup_restore/backuper.rb:40:in `run'
/var/www/discourse/lib/backup_restore.rb:13:in `backup!'
/var/www/discourse/app/jobs/regular/create_backup.rb:10:in `execute'
/var/www/discourse/app/jobs/base.rb:297:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-5.0.0/lib/rails_multisite/connection_management.rb:82:in `with_connection'
/var/www/discourse/app/jobs/base.rb:284:in `block in perform'
/var/www/discourse/app/jobs/base.rb:280:in `each'
/var/www/discourse/app/jobs/base.rb:280:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:177:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:132:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in `local'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq.rb:44:in `block in <module:Sidekiq>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread'
[2024-02-14 04:25:38] Deleting old backups...
[2024-02-14 04:25:38] Cleaning stuff up...
[2024-02-14 04:25:38] Removing '.tar' leftovers...
[2024-02-14 04:25:39] Marking backup as finished...
[2024-02-14 04:25:39] Notifying 'system' of the end of the backup...

Aber dann bekomme ich eine Reihe von teilweise(?) vollständigen Backups, über die ich anscheinend nicht benachrichtigt werde. Sie sammeln sich an, bis der Punkt erreicht ist, an dem jeden Tag versucht wird, ein neues Backup zu erstellen, und das gleichzeitig meine Website lahmlegt.

Ich muss mich manuell per SSH einloggen und diese löschen, da sie auf der Seite /admin/backups nicht angezeigt werden.

Ich weiß, dass es schwierig ist, dieses Problem zu reproduzieren und daher schwer zu beheben, aber ich wollte fragen, ob ich etwas offensichtlich falsch mache oder ob andere das gleiche Problem haben?

[Ed_S]

Versuchen Sie als Erstes, nachdem Sie die nicht komprimierten Backup-Dateien entfernt haben, die maximale Anzahl der Backups auf 2 zu reduzieren.

Ich denke, es ist auf jeden Fall am besten, eine Möglichkeit zu haben, diese Backups woanders hin zu holen – zum Beispiel zu Ihnen nach Hause. Wenn Sie ein Problem mit Ihrem Hoster hätten und dieser Ihr Konto löschen würde, hätten Sie im Moment nichts mehr. Ebenso, wenn Ihr Konto kompromittiert würde, und vielleicht auch, wenn dort ein Brand ausbräche.

Sobald Sie eine Möglichkeit haben – vielleicht manuell, vielleicht automatisch –, um externe Kopien zu erstellen, sind Sie dem Überprüfen und Löschen von Fragmenten sehr nahe.

Ich habe schon früher vorgeschlagen, dass das Dashboard warnen sollte, wenn die Backup-Dateien seit ihrer Erstellung mehrere Tage lang nicht gelesen wurden. Das ist eine relativ einfache Prüfung und meiner Meinung nach ein guter Indikator dafür, dass eine externe Kopie vorhanden ist.

Sie können Ihre Backups auch in Block Storage speichern und dies bei einem anderen Anbieter tun. Dann wäre es unwahrscheinlicher, dass Sie sowohl Ihre Installation als auch Ihre Backups verlieren.

Ich denke, es gibt lang erwartete Arbeiten, die nicht beide Backups und kurzzeitig die komprimierte Backup-Datei benötigen würden, aber es lohnt sich nicht, darauf zu warten. In der Zwischenzeit benötigen Sie Speicherplatz für die N Backups, die Sie aufbewahren, plus 1 für das Backup, das in unkomprimierter Form erstellt wird, plus 1 für das komprimierte Backup, das Sie kurzzeitig benötigen, bevor das älteste der N gelöscht wird.

Sie benötigen Festplattenspeicher für N+2 Backups, und wenn ein Backup fehlschlägt, müssen Sie die Teile löschen.

[pfaffman (Jay Pfaffman)]

@piffy

/var/www/discourse/tmp/

Sie müssen sehen, dass Sie dieses Verzeichnis auch auf Ihrer 300-GB-Partition ablegen. Das ist dasjenige, das die Festplatte füllt.

Sie könnten auch erwägen, Uploads auf diese Partition zu verschieben.

[piffy]

Kennen Sie das auswendig, wie das geht? Gibt es eine YML-Einstellung oder etwas, das ich ändern muss?

Ich habe es auch so eingerichtet, dass es einen statischen Offline-Bildschirm beim Wiederaufbau gibt, daher weiß ich nicht, ob das die Dinge verkompliziert.

[pfaffman (Jay Pfaffman)]

Etwas wie

volumes:
  - volume:
      host: /your/big/partition/tmp
      guest: /var/www/discourse/tmp

Vermutlich machst du das schon, um die Backups auf der großen Partition zu speichern?

@piffy

Ich habe es auch so eingerichtet, dass es einen statischen Offline-Bildschirm gibt, wenn ich es neu aufbaue, daher weiß ich nicht, ob das die Sache verkompliziert.

Das tut es. Es ist wahrscheinlich nicht das Problem, es sei denn, das Problem ist, dass die statische Offline-Seite immer noch angezeigt wird, obwohl Discourse läuft.

[piffy]

Ich habe nach dem Erstellen dieses Themas herausgefunden, dass Sie einen Befehl in der Konsole ausführen müssen, wenn Sie Ihren Digital Ocean-Datenträger erweitern. Effektiv habe ich also nicht meine gesamten 300 GB genutzt.

Ich habe das behoben und nichts anderes geändert, und das Problem trat heute erneut auf. Als meine Website ausfiel, gab es 2 entpackte Tar-Dateien und 3 gzipte.

Ich werde die oben besprochene Strategie als nächstes ausprobieren.

Aber was ich sagen wollte ist, dass es schön wäre, eine Anzeige in der Admin-Oberfläche zu haben, dass es fehlgeschlagene Backups gibt. Oder vielleicht alle *.tar-Dateien löschen, wenn ein neuer Backup-Prozess ausgelöst wird? In diesem Fall hatte ich 90 GB an entpackten Backups, die von der Admin-Oberfläche nicht eingesehen werden konnten. Und auch keine “Backup fehlgeschlagen”-DM von beiden.

[gerhard (Gerhard Schlager)]

Wie ist die Speichernutzung auf Ihrem Droplet? Der Backup-Prozess sollte Bereinigungsroutinen ausführen und eine Benachrichtigung an die Administratoren senden, wenn er fehlschlägt. Das wird nicht passieren, wenn der Prozess vom Out-of-Memory-Killer beendet wird.

[pfaffman (Jay Pfaffman)]

@gerhard

Das wird nicht passieren, wenn der Prozess vom Out-of-Memory-Killer beendet wird.

Vielleicht passiert das! Ich habe dieses Szenario “unterbrochene Backups hinterlassen teilweise Backups, die die Festplatte füllen” auf einigen Websites gesehen. Meine beste Erklärung war ein Neustart des Betriebssystems mitten in einem Backup, aber ich habe es auch gesehen, wenn keine Neustarts des Betriebssystems stattfinden.

Dass der Backup-Prozess vom Out-of-Memory-Killer beendet wird, scheint eine wahrscheinliche Erklärung zu sein, die schwer genug zu reproduzieren ist, um dies zu erklären.

. . . .

Oh. Mist. Eine Website, an die ich mich erinnere, dass sie dieses Problem hatte, hat 16 GB RAM, daher glaube ich nicht, dass das die Erklärung ist. Auf dieser Website ist das Problem, dass etwa einmal pro Woche ein Backup auf der lokalen Festplatte verbleibt, nachdem es nach S3 übertragen wurde (oder vielleicht auch nicht). Sie haben auch über 100 GB freien Festplattenspeicher, sodass es Monate dauert, bis das Problem groß genug wird, dass die Festplatte voll ist.

Hier ist die Reihe von Dateien, die ich gerade gelöscht habe:

forum-2024-03-11-123904-v20240202052058.tar.gz
forum-2024-03-09-123159-v20240202052058.tar.gz                           
forum-2024-03-07-123727-v20240202052058.tar.gz                           
forum-2024-03-05-123019-v20240202052058.tar.gz
forum-2024-03-03-123934-v20240202052058.tar.gz  

[Firepup650 (Firepup Sixfifty)]

+1 dazu, das Forum, bei dem ich helfe, hat zufällig Backups auf dem Server statt auf S3, und das hat das Forum mindestens einmal zum Absturz gebracht.

[piffy]

Bin nicht sicher, ob das hilfreich ist, aber hier sind die Metriken von DO

7 Tage

24h

Reinzoomen