안녕하세요, 방금 새로운 Discourse를 설정했고 S3에 업로드 버킷이 있습니다.
하지만 Discourse가 백업을 생성할 때 모든 파일을 zip으로 압축한다면, 이는 백업이 생성될 때마다 Discourse가 S3 업로드 버킷 전체를 다시 다운로드한다는 뜻인가요?
그렇게 할 때 대역폭 제한 관련 문제를 겪어 본 분이 계신가요?
안녕하세요, 방금 새로운 Discourse를 설정했고 S3에 업로드 버킷이 있습니다.
하지만 Discourse가 백업을 생성할 때 모든 파일을 zip으로 압축한다면, 이는 백업이 생성될 때마다 Discourse가 S3 업로드 버킷 전체를 다시 다운로드한다는 뜻인가요?
그렇게 할 때 대역폭 제한 관련 문제를 겪어 본 분이 계신가요?
로컬 파일을 가리키는 것 같습니다. S3에 있는 파일은 별도로 백업해야 합니다.
include_s3_uploads_in_backups 사이트 설정을 활성화할 때만 해당됩니다. 기본적으로 비활성화되어 있습니다.
해당 설정은 제 웹사이트에서 기본적으로 활성화되어 있는 것 같습니다. 하지만 어쨌든, S3 업로드 버킷을 효율적으로 백업하는 방법에 대한 추천이 있을까요?
백업이 단일 zip 파일인 경우, S3에 백업을 저장하고 Glacier로 아카이브하는 이 가이드는 합리적으로 보입니다. 하지만 Glacier 비용 구조는 파일당 요금이 부과되므로, 압축을 풀지 않은 버킷 백업의 경우 비용이 급격히 증가할 것으로 이해하고 있습니다.
저는 AWS 초보자이므로, 조언이 있다면 감사하겠습니다. 감사합니다!
수정: 간단하고 좋은 답이 없다면, 업로드에 S3를 사용하지 않는 것을 고려해 볼 수도 있습니다.
https://iolap.com/2020/04/06/how-to-avoid-hidden-amazon-glacier-charges/
이것은 많은 요인에 따라 달라집니다. 얼마 정도의 예산을 들이고 싶으신가요? 어떤 시나리오에 대비한 백업을 원하시나요? 소프트웨어 버그, 아마존 데이터센터에 소행성 충돌, 악의적인 관리자가 S3에서 파일을 삭제하는 경우 등…
죄송하지만 이 부분에 대해서는 도움을 드리기 어렵습니다. 사용 사례에 맞는 솔루션은 다른 곳에서 찾아보셔야 합니다. 선호하시는 검색 엔진이 좋은 출발점이 될 것입니다.
조사를 더 하고 주변 사람들과 이야기를 나눠봤습니다.
이 문제를 해결하는 최선의 방법은 S3 버킷을 다른 리전으로 복제하는 것인 것 같습니다. 설정 방법과 비용에 대해 더 조사해 봐야 합니다.
저희 경우처럼 디스코르스가 아닌 사이트의 경우, 서로 다른 계정의 서로 다른 리전 간에 aws s3 sync 명령을 사용해 버킷을 동기화합니다. 이렇게 하면 한 계정이 해킹되어 버킷이 삭제되거나, 운이 없게 소행성이 떨어져 아마존 데이터센터가 파괴되는 경우(희망사항은 아니지만)에도 다른 버킷에서 복구할 수 있습니다. 동기화를 수행하면 새 파일이나 변경된 파일만 동기화되므로 비용이 그렇게 높지 않을 것입니다.
물론, 짧은 시간 내에 두 계정이 모두 해킹되어 버킷이 삭제되거나, 아마존이 AWS를 종료하는 경우도 여전히 존재합니다. 둘 다 매우 매우 가능성이 낮지만, 만약 그런 일이 발생한다면 로또를 사서 자신이 틀렸다고 생각하는 번호를 고르는 수밖에 없습니다 ![]()