Un problème similaire s’est reproduit pour nous. Je viens de remarquer que j’ai des dizaines de sauvegardes locales (1,6 Go chacune), alors que le paramètre est limité à la valeur 3. Cela fonctionnait depuis des années, mais je me souviens d’un incident il y a longtemps où un problème similaire s’était produit.
Les sauvegardes se terminent avec succès
Les téléversements vers S3 réussissent
Exécution de la branche stable. Mise à jour récente vers la version 2.3.7 et redémarrage.
Je devrai creuser plus en détail à un meilleur moment.
Le problème a commencé le 11 septembre. Cette date ne correspond ni à nos interruptions de service ni à aucune action que nous aurions effectuée sur le site.
Mise à jour :
Il ne s’agit pas d’un cas isolé, car mon autre petite instance de test semble rencontrer le même problème. Celle-ci repose sur une infrastructure complètement différente, hébergée chez Digital Ocean. Ici, les sauvegardes n’ont pas été supprimées depuis le 16 septembre. Les téléversements réussissent également ici.
Bon… là, ça commence à ressembler à une erreur d’utilisateur stupide — j’ai complètement manqué le changement dans la façon dont la gestion des sauvegardes fonctionne actuellement. Donc Discourse gère et supprime désormais directement les sauvegardes S3, sans qu’il soit nécessaire de purger les anciennes sauvegardes avec une règle de bac ? Je vais donc augmenter la valeur à 30, car les sauvegardes ne devraient pas consommer d’espace disque local.
Le nombre de sauvegardes stockées dans les bacs S3 ne correspondait pas au paramètre 3.
J’ai maintenant reconfiguré les sauvegardes et les règles du bucket avec des valeurs raisonnables, en accord avec le comportement actuel de Discourse. Comme mentionné, j’avais le nombre de sauvegardes défini à 3, basé sur l’ancienne logique de sauvegarde. Maintenant, il est réglé à 30.
Veuillez garder ce fil ouvert, et je reviendrai dans 30 jours pour vérifier que Discourse respecte désormais la nouvelle valeur redéfinie.
Ah, c’est de l’histoire ancienne. J’ai l’impression que cela a été résolu d’une manière ou d’une autre, mais nous utilisons CDCK SaaS depuis quelques années maintenant et je n’ai plus de souvenir clair de ce problème.
Je suppose que cela aurait été signalé par un autre auto-hébergeur, si cela posait encore problème ?
J’ai eu exactement le même problème et j’ai découvert il y a 10 minutes que la raison était que j’avais activé s3_disable_cleanup. Je pense que cela n’avait à voir qu’avec les téléchargements S3, pas les sauvegardes. Mais c’était faux.
