Я думал о наихудшем сценарии: один из ваших администраторов взломан. Хакер теперь может многое, включая удаление ваших резервных копий во внешнем хранилище через панель управления резервными копиями. Это может полностью уничтожить ваш экземпляр Discourse, оставив администраторов без каких-либо резервных копий (в случае, когда администратор использует только встроенную функцию резервного копирования Discourse и не следует правилу резервного копирования 3-2-1).
Не было бы хорошей идеей запретить любому пользователю удалять резервные копии через интерфейс? Если мы хотим удалить резервные копии, мы можем войти в наш внешний сервис (например, S3) и удалить их оттуда.
Реализовав эту функцию, нам не придется использовать альтернативные методы резервного копирования. Мы сможем просто пользоваться встроенной функцией резервного копирования со спокойной душой.
Многие пользователи сталкиваются с тем, что их сайты перестают работать из-за переполнения диска, и им действительно необходимо иметь возможность удалять резервные копии, чтобы освободить место на диске.
Как они могут получить доступ к сайту, если он недоступен? Если сайт недоступен из-за нехватки места на диске, им всё равно нужно использовать другой способ (SSH).
Другая проблема заключается в том, что для решения вашей проблемы Discourse должен был бы никогда не удалять резервные копии, поскольку если бы он мог их обрезать, то злонамеренный администратор мог бы изменить число сохраняемых копий на 1, а затем создать новую, чтобы удалить её.
Если вы хотите иметь возможность удалять резервные копии S3 только через панель S3 (где у вас никогда не будет злонамеренного администратора?), то измените права доступа S3 так, чтобы Discourse не мог их удалять.
Это может быть альтернативным решением. Однако в моём случае я использую объектное хранилище Vultr, где такой вариант недоступен. Возможно, я рассмотрю другие сервисы или просто перейду на резервное копирование через rclone в GDrive как решение на случай сбоя.