I was thinking about the worst case: one of your admins getting hacked - now hacker can do a lot, but also deleted your backups on an external location from the Backups dashboard. Which could completely destroy your Discourse instance, leaving admins without any backup (in the case where an admin is just using Discourse backup function and no other 3-2-1 backup rule)
Would it be an idea to prevent any user from deleting backups from the interface? If we want to delete backups we can login to our external (S3) service and delete from there.
By having this feature, we do not have to use alternative backup methods and we can just stick with the build-in backup feature with a peace of mind.
Lots of people have their sites go down because their disk is full and they really need to be able to delete backups to free disk space.
How can they access the site if it’s down? They still need to go another way (SSH) if their site is down because of disk space.
The other issue is that to solve your problem Discourse would have to never delete backups since if it could trim them then the rogue admin could change the number to keep to 1 and then make one to erase it.
If you want to be able to delete s3 backups only from S3 panel (where you’ll never have a rogue admin?), then change your S3 permissions so that Discourse can’t delete them.
This might be an alternative. However in my case I use Vultr Object storage where this is not an option. I might check out other services, or just go with an rclone transfer to GDrive as a failover solution.