Les sauvegardes font planter mon forum

[piffy]

Je passe par des cycles où la création de sauvegarde fait planter mon site en raison d’un manque d’espace.

Je l’ai configuré de manière à utiliser un volume DO séparé pour stocker les sauvegardes et les téléchargements. Le volume fait 300 Go.

Mes paramètres de sauvegarde :

Le problème se reproduit depuis des mois. Je reçois des messages dans la boîte de réception de l’administrateur indiquant que la sauvegarde a échoué (voir ci-dessous).

Plus d'espace sur le périphérique

[2024-02-14 03:43:34] Finalisation de la sauvegarde...
[2024-02-14 03:43:34] Création de l'archive : elite-fourum-2024-02-14-033845-v20240204204532.tar.gz
[2024-02-14 03:43:34] Vérification que l'archive n'existe pas déjà...
[2024-02-14 03:43:34] Création d'une archive vide...
[2024-02-14 03:43:34] Archivage du dump de données...
[2024-02-14 03:43:58] Archivage des téléchargements...
[2024-02-14 03:55:03] Suppression du répertoire temporaire '/var/www/discourse/tmp/backups/default/2024-02-14-033845'...
[2024-02-14 03:55:03] Compression de l'archive avec gzip, cela peut prendre un certain temps...
[2024-02-14 04:25:38] EXCEPTION : /var/www/discourse/lib/discourse.rb:138:in `exec': Échec de la compression de l'archive avec gzip.

gzip: /var/www/discourse/public/backups/default/elite-fourum-2024-02-14-033845-v20240204204532.tar.gz : Plus d'espace sur le périphérique

[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] Suppression des anciennes sauvegardes...
[2024-02-14 04:25:38] Nettoyage...
[2024-02-14 04:25:38] Suppression des restes de '.tar'...
[2024-02-14 04:25:39] Marquage de la sauvegarde comme terminée...
[2024-02-14 04:25:39] Notification à 'system' de la fin de la sauvegarde...

Mais ensuite, je reçois une série de sauvegardes partiellement (?) complètes dont je ne suis pas informé, à ma connaissance. Elles s’accumulent jusqu’à ce qu’une nouvelle sauvegarde soit tentée chaque jour et qu’elle fasse planter mon site en même temps.

Je dois me connecter manuellement via SSH et les supprimer car elles n’apparaissent pas sur la page /admin/backups.

Je sais qu’il est difficile de reproduire ce problème et donc de le résoudre, mais je me demandais s’il y avait quelque chose d’évident que je fais mal ou si d’autres rencontraient le même problème ?

[Ed_S]

La première chose à essayer, après avoir supprimé les fichiers qui ne sont pas des sauvegardes compressées, est de réduire le nombre maximum de sauvegardes à 2.

Je pense qu’il est préférable dans tous les cas d’avoir un moyen de récupérer ces sauvegardes ailleurs – chez vous, par exemple. Si vous aviez un problème avec votre hébergeur et qu’il supprimait votre compte, vous n’auriez plus rien. De même si votre compte était compromis, et peut-être aussi s’il y avait un incendie.

Une fois que vous aurez un moyen – manuel ou automatique – d’obtenir des copies hors site, vous serez très proche d’un moyen de vérifier et de supprimer les fragments.

J’ai déjà suggéré que le tableau de bord devrait avertir si les fichiers de sauvegarde n’ont pas été lus pendant plusieurs jours depuis leur création. C’est une vérification relativement facile, et à mon avis un bon indicateur pour vérifier qu’il existe une copie hors site.

Vous pouvez également choisir de placer vos sauvegardes dans un stockage par blocs, et vous pourriez le faire en utilisant un fournisseur différent. Ainsi, vous seriez moins susceptible de perdre à la fois votre installation et vos sauvegardes.

Je pense qu’il y a un travail en attente depuis longtemps qui ne nécessiterait pas d’avoir à la fois la sauvegarde et brièvement le fichier de sauvegarde compressé, mais cela ne vaut pas la peine d’attendre. En attendant, vous avez besoin d’espace pour les N sauvegardes que vous conservez, plus 1 pour la sauvegarde en cours de création sous forme non compressée, plus 1 pour la sauvegarde compressée dont vous avez besoin brièvement avant que la plus ancienne des N ne soit supprimée.

Vous avez besoin d’espace disque pour N+2 sauvegardes, et si une sauvegarde échoue, vous devez supprimer les fragments.

[pfaffman (Jay Pfaffman)]

@piffy

/var/www/discourse/tmp/

Vous devez vous assurer que vous avez également placé ce répertoire sur votre partition de 300 Go. C’est celle qui remplit le disque.

Vous pourriez également envisager de déplacer les téléchargements vers cette partition.

[piffy]

Savez-vous d’emblée comment faire ? Y a-t-il un paramètre yml ou quelque chose que je dois changer ?

J’ai également configuré un écran statique hors ligne lors de la reconstruction, donc je ne sais pas si cela complique les choses.

[pfaffman (Jay Pfaffman)]

Quelque chose comme

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

Vous faites probablement déjà quelque chose comme ça pour mettre les sauvegardes sur la grande partition ?

@piffy

Je l’ai aussi configuré pour avoir un écran statique hors ligne lors de la reconstruction, donc je ne sais pas si cela complique les choses

Ça complique. Ce n’est probablement pas le problème, à moins que le problème ne soit qu’il continue d’afficher la page statique hors ligne même si Discourse est en ligne.

[piffy]

J’ai découvert après avoir créé ce sujet que vous devez exécuter une commande dans la console lorsque vous augmentez la taille de votre volume DigitalOcean. Donc, en fait, je n’utilisais pas la totalité de mes 300 Go.

Je l’ai corrigé et n’ai rien d’autre changé, et le problème s’est reproduit aujourd’hui. Il y avait 2 fichiers tar décompressés et 3 fichiers gzip lorsque mon site est tombé en panne.

J’essaierai la stratégie discutée ci-dessus ensuite.

Mais ce que je voulais dire, c’est qu’il serait agréable d’avoir un indicateur sur l’interface d’administration indiquant qu’il y a des sauvegardes échouées. Ou peut-être effacer tous les fichiers *.tar lors du déclenchement d’un nouveau processus de sauvegarde ? Dans ce cas, j’avais 90 Go de sauvegardes non décompressées qui ne sont pas visibles depuis l’interface d’administration. Et aussi aucune notification DM de “sauvegarde échouée” de la part de l’un ou l’autre.

[gerhard (Gerhard Schlager)]

Quelle est l’utilisation de la mémoire sur votre droplet ? Le processus de sauvegarde doit exécuter des routines de nettoyage et envoyer une notification aux administrateurs en cas d’échec. Cela ne se produira pas si le processus est terminé par le tueur de mémoire insuffisante.

[pfaffman (Jay Pfaffman)]

@gerhard

Cela n’arrivera pas si le processus est terminé par le tueur de mémoire insuffisante.

C’est peut-être ce qui se passe ! J’ai vu ce scénario de « sauvegardes interrompues laissant des sauvegardes partielles qui remplissent le disque » sur quelques sites. Mon explication la plus probable était un redémarrage du système d’exploitation au milieu d’une sauvegarde, mais je l’ai vu sans redémarrage du système d’exploitation…

Le fait que le processus de sauvegarde soit terminé par un manque de mémoire semble être une explication probable qui est suffisamment difficile à reproduire pour expliquer cela.

. . . .

Oh. Zut. Un site dont je me souviens avoir eu ce problème a 16 Go de RAM, donc je ne pense pas que cela l’explique. Sur ce site, le problème est que toutes les semaines environ, une sauvegarde reste sur le disque local après avoir été (ou peut-être pas) envoyée vers S3. Ils ont également plus de 100 Go d’espace disque libre, il faut donc des mois pour que le problème devienne suffisamment important pour que le disque soit plein.

Voici l’ensemble des fichiers que je viens de supprimer :

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 pour ça, le forum que j’aide à gérer a aléatoirement des sauvegardes laissées sur le serveur au lieu d’être poussées vers S3, et cela a mis le forum hors service au moins une fois.

[piffy]

Pas sûr que ce soit utile, mais voici les métriques de DO

7 jours

24h

Zoom avant