Cela dure depuis longtemps — j’ai un rappel mensuel dans mon calendrier pour supprimer ces fichiers restants. Les journaux de sauvegarde sont vides : « Pas encore de journaux… » et rien dans les journaux d’erreurs n’indique de problèmes avec Amazon S3.
Discourse est mis à jour régulièrement et est actuellement en version 2.9.0.beta14.
Ceci est une installation standard, n’est-ce pas ? Y a-t-il une possibilité que le système d’exploitation (ou autre chose) interrompe le processus de sauvegarde pendant le téléchargement ? Parce que même en cas d’échec de la sauvegarde, le fichier local devrait être supprimé à la fin du processus.
J’ai utilisé un service compatible S3 pendant un certain temps, ce qui entraînait parfois des sauvegardes laissées sur le disque local, mais c’était intermittent.
Vous devriez regarder dans /var/discourse/shared/standalone/logs/rails/production.log. Il suffit d’exécuter une sauvegarde en ligne de commande et de voir si elle présente le comportement attendu.
Les journaux de production ne remontent qu’à une semaine, donc les anciennes sauvegardes « non supprimées » sortent de cette période, mais je garderai un œil sur les futures. La seule entrée d’erreur de sauvegarde était celle-ci dans le journal du 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")
Je vois une nouvelle sauvegarde non supprimée dans /var/discourse/shared/standalone/backups/default mais rien dans le fichier production.log. Rien non plus dans production_errors.log. Où puis-je chercher d’autre ?
P.S. J’ai lancé une sauvegarde depuis la ligne de commande et la sauvegarde a été supprimée avec succès - je vais essayer cela encore quelques fois pour voir si j’obtiens une erreur là-bas.
Je n’arrive pas à reproduire la sauvegarde locale non supprimée via la CLI, mais elle continue de se produire une ou deux fois par semaine lors de la sauvegarde nocturne. Je ne vois pas non plus de sortie de journal de sauvegarde dans production.log. Êtes-vous sûr que c’est là qu’elle est écrite, @pfaffman ?
Je pense que ça devrait l’être. Quand j’ai eu un problème similaire avec un autre service S3, je n’ai pas pu trouver d’erreurs dans Discourse ou dans leur service. Et j’ai abandonné et suis passé à autre chose. Mais vous utilisez AWS, S3, le vrai de vrai, donc je suis assez surpris.
J’ai essayé de chercher comme ceci : grep -r "Output file is stored on S3" /var/discourse
car cette phrase est la dernière ligne de la sortie de sauvegarde de la CLI, mais rien n’est trouvé.
Y a-t-il une chance que le serveur redémarre en raison de mises à jour automatiques du système d’exploitation hôte ? Elles pourraient se produire pendant le téléchargement vers S3. Y a-t-il quelque chose dans les journaux de votre système d’exploitation ? Peut-être réinitialiser le paramètre du site backup_time_of_day à la valeur par défaut ou à une heure différente et voir si le problème disparaît.
Non, la disponibilité actuelle est de 36 jours. J’avais suspecté que la sauvegarde du droplet DigitalOcean fonctionnant simultanément aurait pu en être la cause, mais cela se produit une fois par semaine et mes sauvegardes non supprimées se produisent plus fréquemment que cela.
J’essaierai une autre backup_time_of_day. Elle était réglée sur 2h00 UTC, nous verrons donc si le 3h30 UTC par défaut fait une différence.
OOOOH ! C’est une bonne idée. Cela expliquerait. Je parie que c’est ça. Et le milieu de la nuit est un bon moment pour les sauvegardes et les redémarrages. Cela n’explique pas tout à fait pourquoi le problème a disparu lorsque j’ai changé pour un autre service, mais peut-être que ma chance a juste changé, ou que ce que j’ai changé était plus rapide ou quelque chose comme ça.
Seize jours plus tard, il semble que ce fut la solution — plus de sauvegardes non supprimées. Je ne sais pas ce qui causait le conflit, mais il est sans objet maintenant.
