최악의 상황을 가정해 보았습니다. 관리자 중 한 명의 계정이 해킹당하는 경우입니다. 이렇게 되면 해커가 많은 일을 할 수 있지만, 백업 대시보드에서 외부 위치에 저장된 백업까지 삭제할 수 있습니다. 이는 Discourse 인스턴스를 완전히 파괴할 수 있으며, 관리자가 Discourse의 내장 백업 기능만 사용하고 3-2-1 백업 규칙과 같은 다른 백업 방식을 사용하지 않는 경우라면 어떤 백업도 남지 않게 됩니다.
인터페이스에서 사용자가 백업을 삭제하는 것을 방지하는 것이 좋은 아이디어일까요? 백업을 삭제해야 한다면 외부(S3) 서비스에 로그인하여 직접 삭제할 수 있습니다.
이 기능이 도입되면 대체 백업 방식을 사용할 필요가 없으며, 안심하고 내장 백업 기능만 사용할 수 있습니다.
디스크가 가득 차서 사이트를 백업 파일 삭제를 통해 디스크 공간을 확보할 수 있어야 하는데, 그렇지 못해서 웹사이트가 다운되는 경우가 많습니다.
사이트가 다운되어 있으면 어떻게 접속할 수 있을까요? 디스크 공간 부족으로 사이트가 다운된 경우에도 다른 방법(SSH)을 통해 접속해야 합니다.
또 다른 문제는, Discourse가 백업을 절대 삭제하지 않도록 해야 한다는 점입니다. 만약 백업을 정리할 수 있다면, 악성 관리자(rogue admin)가 유지할 백업 수를 1로 변경한 후 백업 하나를 만들어 기존 백업을 삭제할 수 있기 때문입니다.
S3 패널에서만 S3 백업을 삭제할 수 있도록 하려면(그곳에는 악성 관리자가 없으니까요), Discourse가 S3 백업을 삭제할 수 없도록 S3 권한을 변경하십시오.
이것이 대안이 될 수 있습니다. 하지만 제 경우엔 Vultr Object Storage를 사용하는데, 여기서 그런 옵션은 없습니다. 다른 서비스를 알아볼 수도 있고, 아니면 rclone으로 GDrive로 전송하는 것을 폴오버(failover) 솔루션으로 사용할 수도 있겠습니다.