In a discussion titled “Prevent deletion of backups from interface,” MarcP proposes disabling the ability to delete backups via the Discourse interface to protect against compromised admins who might erase backups — potentially destroying the entire instance. He suggests relying on external storage (like S3) for deletion, allowing safe use of Discourse’s built-in backup feature without fear. pfaffman counters that users often need to delete backups to free disk space when sites go down, and removing deletion capability would break this workflow. MarcP replies that if the site is down due to disk space, admins must already use SSH anyway — so deleting via interface isn’t critical. pfaffman adds that if Discourse can auto-delete old backups (e.g., to keep only N copies), a rogue admin could manipulate those settings to erase all backups — so the only real solution is to restrict deletion permissions at the storage level (e.g., S3). MarcP acknowledges this workaround but notes it’s not available on his current provider (Vultr Object Storage), so he may switch services or use rclone to Google Drive as a fallback. The debate centers on balancing security against operational flexibility, with storage-level permissions emerging as the most viable mitigation — though not universally accessible.
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.
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.