여러분 안녕하세요 - 호스팅된 Discourse에서 자체 호스팅으로 이전하는 과정에 있습니다. 여러 가지 테스트를 성공적으로 수행해 보았지만, 모든 업로드를 포함한 실제 이전을 시도할 때, 아카이브를 몇 시간 동안 압축 해제한 후 덤프 파일을 추출하려고 하면 해당 파일이나 디렉터리가 존재하지 않는다고 표시됩니다. 그래서 누군가 아이디어가 없다면 약 140GB의 업로드 파일을 잃을 처지에 놓여 있습니다.
로그를 제공해 주시겠어요?
명령줄에서 복원 중이신가요, 아니면 웹 인터페이스에서 복원 중이신가요? 웹 인터페이스 사용을 권장합니다.
안녕하세요 - 이전 이메일에 로그를 첨부해 드렸고, 여기에도 다시 첨부합니다. 처음에는 웹 인터페이스를 통해 시도했고, 두 번째로는 명령줄을 통해 시도했습니다. S3에 업로드할 때 인식되지 않고, 브라우저를 통해 업로드를 시도하면 거의 즉시 거부되므로 백업이 어떤 방식으로든 손상된 것 같다는 의심을 하고 있습니다.
restore-failure-log.txt (3.28 KB)
그렇게 보입니다. 웹 브라우저로 업로드했나요, 아니면 scp/rsync를 사용했나요? rsync로 다시 업로드해 보시는 것이 좋습니다.
제이, 안녕하세요. 이번 마이그레이션 과정에서 Discourse와 이메일로 계속 논의해 왔는데, 그 과정에서 로그 파일을 첨부했었습니다. 그래서 조금 혼동하게 된 것 같습니다.
에러를 살펴본 결과, 타르볼에 실제로는 SQL 덤프가 포함되어 있지 않고 이미지만 들어 있는 것 같습니다. 해당 파일은 Discourse가 저희 대신 생성하고 확인했습니다. 브라우저 업로드가 거부되어 HTTP로 다운로드한 후 SCP를 통해 서버에 업로드했습니다.
네, 타르볼의 내용을 확인하는 명령어를 실행해 봤는데, 이미지만 포함되어 있고 SQL 덤프는 없습니다.
타르볼의 크기가 정확히 동일한지 확인해 주실 수 있나요?
- CDCK 인스턴스
- 다운로드한 파일
- scp를 사용하여 업로드한 파일
아카이브가 잘리지 않았는지 확인하려면 tar tfvz를 실행해 보시는 것이 좋습니다.
아카이브 크기의 배수만큼 디스크 공간이 필요하므로, 어딘가에서 디스크 공간이 부족하지 않은지 확인해 보시는 것이 좋습니다.
잠깐 나갔다가 나중에 확인하겠습니다. 용량은 512GB이고 백업 파일이 70GB이므로 공간은 문제가 되지 않을 것입니다. 이전에 생성했던 백업 파일보다 몇 GB 정도 작다는 것에 놀랐습니다. 오히려 약간 더 클 것이라 예상했거든요. 아마도 어떤 이유로 SQL 덤프가 포함되지 않은 것 같습니다. 용량 차이가 바로 그 부분 때문일 것입니다.
@pfaffman @RGJ 안녕하세요, 진행 상황 업데이트를 드리겠습니다.
다운로드한 아카이브에서 SQL 덤프가 실제로 누락되어 있었고, 별도의 DB 백업을 받아 아카이브에 삽입하는 방식이 작동할지(그리고 테스트하는 데 몇 시간이 걸릴지) 확신이 없었습니다. 그래서 결국 데이터베이스를 복원하고 마이그레이션을 수행했는데, 성공적으로 완료되었습니다.
하지만 현재 문제는 Discourse가 모든 것을 중단하고 S3 버킷/CDN을 꺼버리면, 우리의 모든 과거 이미지 링크가 깨진다는 것입니다.
이미지는 모두 확보해 두었고, 동일한 폴더 구조를 유지하면서 모두를 우리의 S3 버킷에 업로드할 수 있을 것 같습니다. 데이터베이스 수준에서 링크를 일괄 업데이트하기 위해 discourse.remap / dbhelper.remap을 사용할 수 있다는 몇 가지 스레드를 봤습니다. 이에 대한 여러분의 의견이 정말 감사하겠습니다!
그 일이 어떻게 일어날 수 있었는지 상상하기 어렵습니다. 브라우저가 어떻게든 백업을 압축 해제하고 타르(tar)를 풀어서, 다시 원래대로 복원하려고 시도한 건가요?
uploads(업로드된 파일)가 포함된 백업을 제공해 달라고 discourse.org 팀에 요청할 수 있습니다. 그것이 여러분이 해야 할 일입니다. 그들은 include_s3_uploads_in_backup 설정을 켜줍니다(이것은 정확한 이름은 아니지만, 거의 확실하게 숨겨진 설정의 이름에 가깝습니다).
또는 S3 도구를 사용하여 버킷에서 모든 파일을 내려받아 다시 업로드하는 방법을 강구할 수도 있습니다. 이에 대한 주제들이 몇 개 있습니다. 저는 이를 권장하지 않습니다.
최근 저는 약 100GB짜리 백업을 CDCK에서 Digital Ocean으로 이주했습니다. 드롭렛(droplet), 스페이스스 버킷(spaces bucket), 그리고 bunny.net CDN을 사용했으며 비용은 1,000달러였습니다. 저는 그 비용에 대해 아쉬움을 느꼈습니다.
그것은 데이터베이스만인가요?
아, 이미지들이 tar 파일에 있음에도 불구하고 데이터베이스만 복구한 건가요?
데이터베이스와 업로드 파일이 모두 포함된, 그들이 만든 정확한 파일을 사용하여 Discourse로 복원해야 합니다. 또는 복구 코드를 살펴보고, 코드가 수행하는 이미지 위치 재매핑 작업을 수동으로 수행하는 방법을 강구할 수도 있습니다. 리처드(Richard)에게는 이를 수행할 기술과 도구가 있다고 생각하지만, 그 방식으로 진행하는 것은 원하지 않을 것입니다.
몇 달 전 테스트를 해본 적이 있는데, 당시에는 모두 정상적으로 작동했습니다. 이번에는 그 숨겨진 설정이 켜진 채로 남아 있었던 것 같습니다. 이번에는 백엔드에서 업로드를 포함하는 백업을 트리거할 수 있었지만, 약 12시간 후 실패했다는 알림을 받았습니다. 이후 Discourse에 연락을 취했고, 그들은 그들의 쪽에서 백업을 생성하겠다고 했습니다. 몇 시간 후 제가 시작한 백업이 완료된 것처럼 보였지만, Discourse의 조언에 따라 해당 파일을 폐기했습니다. 이후 Discourse 측에서 백업 타임아웃과 오류가 발생하는 여러 문제를 겪었으며, 마침내 완전한 파일이 있다고 통보했습니다. 그러나 해당 파일을 복원하려고 시도했을 때, 아카이브 추출에 몇 시간이 걸린 뒤 덤프 파일이 누락되었다고 오류가 발생했습니다. tar -tf 명령으로 파일을 검사해보니 실제로 덤프 파일이 없었습니다(다른 전체 백업 아카이브를 보면 보통 첫 번째 파일이 덤프 파일입니다). 일요일이어서 Discourse에 연락할 수 없었고, 월요일 오전까지 마이그레이션을 완료하기로 약속해 두었기 때문에, 데이터베이스만 백업(약 7GB)을 받아서 이를 사용하여 마이그레이션을 진행했습니다.
Discourse는 도움을 주려 하고 있지만, 우리는 일요일 오후부터 자체 호스팅 환경으로 이전을 완료했기 때문에 지금 그들이 할 수 있는 일은 제한적입니다. 가장 쉬운 해결책은 S3 버킷과 CDN을 (비용을 지불하는 조건으로) 계속 활성화해 두는 것이겠지만, 그들은 이것이 불가능하다고 말했습니다. 솔직히 말해, 과거 이미지들은 잃어버릴 수밖에 없을 것 같습니다.
이것은 수정 가능합니다. S3 버킷의 내용을 로컬 업로드 디렉터리로 다운로드한 후, 데이터베이스에서 remap을 수행하여 CDN 및 버킷 URL을 해당 인스턴스의 URL로 다시 작성하면 됩니다.
두 가지 문제가 있습니다. 업로드된 이미지의 크기가 새 VPS의 SSD 용량을 가득 채울 수 있고, 추가 디스크를 연결할 수 있는 기능이 없습니다. 디렉터리 구조를 보면 어떻게 작동할지 확실하지는 않지만, 부분만 가져오는 것도 고려해볼 수 있을 것 같습니다. 또한 이미 사이트 설정을 로컬 저장소가 아닌 S3를 업로드로 사용하도록 변경해 두었습니다.
좋아요, 그러면 그들의 S3(또는 S3 백업)를 내 S3로 복사하고 재매핑하는 건가요?
네, 그게 가능하길 바라고 있어요!
아, 그렇군요. 네, 일단 라이브로 올라가면 그걸로 확정되는 거죠. 파일이 삭제되기 전에 S3로 이동시키는 것은 여전히 충분히 가능합니다.
복구를 수행하려면 모든 이미지를 담을 수 있는 충분한 공간이 항상 필요했습니다. 이미지를 하나씩 복사할 수도 있습니다. 또한 파일이 직접 복사되는 도구가 있다고 생각합니다.
네, 원래 계획은 대용량 디스크가 연결된 임시 Azure VM을 사용해 복원한 후 S3로 다시 푸시하고, 완료 후 백업을 한 번 더 수행한 뒤 최종적으로 VPS로 이전하는 것이었습니다(비용 절감을 시도 중입니다).
현재 업로드된 모든 파일이 포함된 tar.gz 파일이 있으며, 디렉터리 구조를 유지하면서 이를 S3 버킷에 직접 업로드할 수 있습니다(요즘 표준 AWS 업로더로 가능한 것으로 생각되며, 그렇지 않다면 CLI를 사용할 수 있습니다). 소유권/권한 설정에 대한 고려가 필요할 수도 있지만, 아마도 그렇지 않을 수도 있습니다.
그 후에는 리맵(remap) 작업이 필요합니다. discourse.remap과 dbhelper.remap의 차이점에 대해서는 잘 모르겠습니다. 이 모든 것을 먼저 더미 설치 환경에서 몇 개의 파일로 테스트해 볼 예정입니다.