안녕하세요!
Support 채널을 검색해 보았지만 기존 답변을 찾지 못해, 간단한 지원 질문을 드려도 될까요:
저희는 2016년경부터 S3를 사용하여 Discourse 파일을 저장해 왔습니다. S3 버킷의 루트를 확인했을 때, 기대했던 optimized/ 또는 original/ 등의 디렉터리 구조보다 '위’에 있는 디렉터리 구조를 발견하여 놀랐습니다.
예전 어딘가에서 잘못된 복사 작업이 있었을 가능성이 있는데, 루트의 숫자 디렉터리(예: 99/)를 삭제하는 것이 안전할까요? 오래전에 잘못된 위치로 복사되었을 수도 있습니다. 게시물이 해당 위치를 가리키는 오래된 경로를 포함하고 있어서 이를 깨뜨리고 싶지 않은 경우가 있을 수 있나요?
현재 상태는 다음과 같으며, 제 목표는 정리하는 것입니다(정리가 필요한 경우):
다시 말해, S3를 이미 사용하시는 분들이 있다면, 저장소의 루트에 있는 객체 이름이 무엇인지 알려 주실 수 있을까요?
도움 주시면 감사하겠습니다. 감사합니다 
좋은 질문이네요, @sam님은 이 역사에 대해 얼마나 알고 계실까요?
우리도 약간 특이한 경우일 수 있겠다 
2015년경부터 Discourse를 운영해 왔고, 그동안 저장 위치를 여러 번 변경했기 때문이다.
처음에는 파일을 로컬 스토리지에 저장하다가, 규모가 커지면서 S3 기반 업로드로 전환했다. 당시 기존 파일들을 포스트를 다시 생성(rebaking)하는 방식으로 이동하지 않은 것으로 생각되며, 따라서 가장 오래된 포스트들은 여전히 로컬 스토리지 URL을 사용하고 있다.
한 가지 짚고 넘어갈 점은, 현재로서는 아무것도 삭제하지 않을 것이라는 점이다. 조직 구조가 몇 년간 변화해 왔지만, 우리가 다루는 데이터 양은 소규모이므로, 있는 그대로 두는 것이 가장 안전하다고 판단했기 때문이다.
솔직히 이 96->99 폴더들이 어떻게 생겼는지는 모르겠어요. 업로드 파일을 저장하는 곳이 아니거든요.
@sam 확인해 주셔서 감사합니다. 참고할 가치가 있는 정보네요. 우리가 가지고 있던 것을 S3로 수동으로 복사했는데 그 과정에서 문제가 생긴 건 아닌지 궁금합니다. 다행히 아무런 피해도 없었습니다.
S3 버킷 루트에는 다음과 같은 항목들이 있습니다.
_emoji/
_optimized/
optimized/
original/
tombstone/
그리고 1/부터 225/까지의 번호가 매겨진 디렉터리들이 많이 있습니다. 각 번호 디렉터리에는 '874c0706216382af.jpg’와 같은 이름의 이미지 파일 하나가 들어 있습니다.
tombstone에는 30일 후 삭제 처리하도록 설정된 S3 라이프사이클이 적용되어 있습니다.
추측이지만, 실제로 사용되는 것은 optimized/, original/, tombstone/ 디렉터리만인가요?
네, 대략 맞습니다.
해당 파일들은 아주 오래된 포럼(2014년경)에서는 항상 존재합니다. optimized와 original보다 이전부터 존재했을 것으로 생각되며, 여전히 참조되고 있을 가능성이 높습니다.
이걸 확인하지 않을 수 없었습니다. 실제로 오래된 업로드 방식입니다. 예상보다 늦게, 2015년 5월에 이 커밋과 함께 폐기되었습니다.
이러한 업로드는 실제로 여전히 사용되고 있으므로 삭제하지 마세요!
Michael, 감사합니다. 2014년에 처음 시작했을 당시의 파일들이라 파일 번호가 작아서, 현재 위치 그대로 유지할 예정입니다.
흥미롭게도 최근 서버를 이전하면서, 기본 Unix 버전에서 인플레이스 업그레이드하는 대신 Discourse 백업/복원 방식을 사용했습니다. (100% 확신은 못 하겠지만) 복원 과정에서 이 로컬 파일들이 제대로 배치되지 않은 것 같습니다. 백업 아카이브에는 포함되어 있었지만, 복원 프로세스는 최적화/원본(optimized/originals) 폴더 아래에만 정상적으로 작동한 것처럼 보였습니다.
큰 문제는 아니었습니다. 구 서버와 새 서버의 uploads/ 내용물이 다르다는 것을 발견했을 때, 백업 아카이브에서 직접 tar -x 명령으로 추출할 수 있었기 때문입니다. 하지만 다른 사용자들이 겪을 수 있는 함정이 될 수 있어서 여기서 언급하고 싶었습니다.
현재 업로드의 99.9%는 S3에서 서빙되고 있습니다(로컬에서 S3로 비교적 일찍 전환했거든요). 하지만 초기에 S3 버킷을 수동으로 생성할 때 로컬 파일을 복사해 올린 것 같습니다. 사후에 생각해보면 게시물을 다시 베이킹(rebake)하는 것이 옳았을 텐데, 로컬 파일 업로드 URL을 가진 아주 작고 오래된 게시물의 경우 항상 잘 작동했기 때문에 그러지 않았습니다.