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.
Okay…now this is starting to look like a stupid user error – I have completely missed the change in how the backup management is currently working. So Discourse now manages and deletes S3 backups directly, without the need to purge the old backups with a bucket rule? Now increasing the value to 30, as backups should not eat up local disk space.
The number of backups that were stored in the S3 buckets did not match the setting 3 though.
I have now reconfigured backups and bucket rules to sane values, matching the current Discourse behavior. Like said, I had the number of backups set to 3, based on the old logic of backups. Now it is set at 30.
Please keep the thread open, and I’ll report back in 30 days to verify that Discourse now respects the re-defined new value.
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.
