The discussion explores how remove_older_backups interacts with maximum_backups in Discourse. pfaffman noticed an unexpected number of backups despite DISCOURSE_MAXIMUM_BACKUPS being set to 14, leading to confusion about the purpose of remove_older_backups. chrism explains that remove_older_backups was added for regulatory compliance, allowing retention of data only up to a certain age, which is distinct from maximum_backups. pfaffman clarifies that the issue might be related to permissions or the timing of backup creation, as performing an ad hoc backup didn’t trigger cleanup. The conversation concludes with chrism suggesting further investigation to confirm expected behavior.
I got a bigger-than-expected AWS bill this month and found that one site had an extra 500GB of backups. DISCOURSE_MAXIMUM_BACKUPS is set to 14, so I was surprised that there were many more than 14 backups. I noticed a new setting called remove_older_backups, which seems confusing since maximum_backups performs a very similar function. I can’t quite come up with a reason that maxium_backups isn’t a good-enough solution. I guess maybe if you make a bunch of manual backups then you’ll keep fewer backups than you want?
Maybe that site was some kind of fluke, since I don’t see any other sites that are not respecting maximum_backups.
@pfaffman the remove older backups was requested by a customer that, for regulatory reasons, couldn’t retain customer data older than a certain number of days. if its not set, it wont be in effect.
in the case of your customer, the DISCOURSE_MAXIMUM_BACKUPS value is read when a new backup is created (ie there’s no nightly script to delete them). it’s possible the customer lowered the value then didnt perform another backup after that point? Is it possible to perform an ad hoc backup and see if that deletes the older backups?
Compliance and regulations. Aha. Thanks. Now I get it.
I guess it’s just a strange coincidence that this appeared the same time that the 80 extra backups showed up.
Thath’s what I did, and it didn’t delete the extra backups, which is what lead me to blame the other setting. Maybe it’s something even more stupid like the bucket doesn’t have delete permissions.
I’ll look at it in another week or so and see if it’s behaving as expected, or if setting the new setting to 14 days will somehow help.