🇨🇳 Discourse를 S3에 백업하는 방법 | Discourse 如何备份到 S3

[honeymoose]

Discourse와 S3는 매우 잘 어울리는 조합입니다. S3에 익숙하시다면, 이 가이드가 큰 도움이 될 것입니다.

많은 사용자의 가상 호스팅 공간과 리소스는 제한적입니다.

S3를 백업에 사용하면 공간을 더 효율적으로 활용할 수 있습니다.

아래 단계에 따라 설정할 수 있습니다:

백업 주기 설정

admin > backup으로 이동하여 backup_frequency를 1로 설정합니다. 이 매개변수는 백업 주기를 나타내며 기본값은 7입니다.
1은 하루에 한 번 백업한다는 뜻입니다.
7은 7일에 한 번 백업한다는 뜻입니다.

일반적인 웹사이트 트래픽의 경우, S3를 백업 저장소로 사용할 때 하루에 한 번 백업하는 것이 가장 좋습니다.

백업용 Bucket 및 경로 설정

이 Bucket은 비공개(Private)로 설정할 수 있습니다. 참고로 S3를 이미 이미지 및 첨부 파일 저장에 사용하고 있다면, 해당 Bucket은 설정 시 public으로 선택해야 합니다.

편의를 위해 여기에서 별도의 Bucket을 하나 더 생성하는 것을 권장하며, 첨부 파일 및 이미지 저장용 Bucket과 혼동하지 않도록 주의하세요.

여기에서 디렉터리 경로를 하나 더 설정하는 것을 권장합니다. Discourse는 이 폴더 아래에 필요한 여러 하위 폴더를 자동으로 생성하기 때문입니다.

이를 통해 저장 구조가 더 명확해집니다.

s3_access_key_id 및 s3_secret_access_key 설정

다음 단계로, 백업 데이터를 저장하기 위해 s3_access_key_id, s3_secret_access_key, s3_region을 설정해야 합니다. 이 세 매개변수는 매우 중요하며, region을 잘못 선택하면 안 됩니다. 백업 업로드가 실패하는 대부분의 경우 권한 문제 때문입니다.

구체적인 설정 방법은 Setting up file and image uploads to S3 - sysadmin - Discourse Meta 문서의 내용을 참고하세요.

참고로, 업로드가 불가능하지 않도록 Key ID에 충분한 권한을 부여해야 합니다.

백업 저장소를 S3로 설정

백업 방식을 S3 저장소로 설정합니다.

이 매개변수 선택 부분에서 Local 저장을 S3 저장으로 변경해야 합니다.

백업 테스트

모든 설정이 완료되면 백업 테스트를 수행할 수 있습니다.

백업 메뉴에서 Backup 버튼을 클릭하여 테스트 백업을 실행합니다.

팝업 화면에서 업로드한 이미지와 첨부 파일을 포함할지 묻습니다.

일반적으로 여기서 Yes를 선택합니다. 이후 화면이 로그 화면으로 전환되며, 백업 정보가 로그로 표시됩니다. 로그에 Finished가 표시되는지 확인하여 백업 완료 여부를 판단할 수 있습니다.

더 중요한 것은 S3 계정에 로그인하여 최신 백업이 생성되었는지 확인하는 것입니다.

시간, 크기, 파일명을 확인하여 검증하면 됩니다.

S3 백업을 설정함으로써 Discourse의 저장 공간을 확장하여 사실상 무제한의 백업 및 저장 공간을 확보할 수 있습니다. 웹사이트 운영 측면에서 자동 백업 및 업로드는 매우 실용적인 기능입니다.

또한 여러 저장소에 백업을 보관할 수 있어, 웹사이트 복원 시 다양한 백업 포인트로 복구할 수 있습니다.

백업 파일을 Docker에서 분리하여 보관하므로 일상적인 백업 관리에 매우 유용하며, 저장 공간 사용량을 크게 줄일 수 있습니다.

이미지와 첨부 파일도 S3에 저장하도록 설정하는 것을 권장합니다. 이를 통해 이전 및 백업 복구에 큰 이점을 얻을 수 있습니다.

더 자세한 내용은 원문 iSharkFly - 飞鲨 을 참고하세요.

[copymonopoly]

확인하고 싶은 것이 있습니다. 백업과 첨부파일이 각각 다른 S3 버킷에 연결되어 있을 때, 백업을 실행하면 첨부파일에 사용된 S3 버킷의 내용도 함께 백업되나요? 만약 업로드된 이미지와 첨부파일을 포함하지 않도록 설정한 경우, 백업을 복원했을 때 첨부파일에 사용된 S3 버킷의 내용이 포럼에서 정상적으로 표시되나요?

[honeymoose]

Discourse의 백업 내용에는 대해 실제로는 자세히 확인해 본 적이 없습니다.

우리의 백업을 살펴본 후에야 알게 되었습니다:

첨부 파일이 AWS 클라우드 스토리지를 사용하는 경우, 백업 시 백업에 첨부 파일 포함을 선택하더라도

AWS에 업로드된 첨부 파일은 백업 파일에 포함되지 않습니다.

백업 파일에 포함된 첨부 파일은 AWS에 없고 로컬 컴퓨터에 저장된 내용뿐입니다.

우리의 웹사이트 백업 크기만 봐도 알 수 있습니다. 첨부 파일을 포함한다면 백업 크기가 80MB出头(약 80MB가 조금 넘는) 정도일 리가 없습니다.

즉, 이 백업에는 데이터베이스와 로컬 첨부 파일만 포함되어 있다는 뜻입니다.

이 다운로드 파일을 열면 폴더가 2개만 있는 것을 볼 수 있습니다. 하나는 dump 폴더로, 이는 PGSQL 데이터베이스 덤프 파일입니다.

또 하나는 uploads 폴더로, 이 폴더에는 로컬에서 업로드한 첨부 파일만 있고 AWS에 저장된 것은 없습니다. 우리에게는 이 폴더가 매우 작아 파일 수도 얼마 되지 않습니다.

이는 커뮤니티 운영을 시작한 지 얼마 지나지 않아 모든 첨부 파일을 AWS로 업로드했기 때문입니다.

위 이미지는 PGSQL 덤프 파일의 내용을 보여줍니다. 덤프 파일을 통해 현재 Discourse 데이터베이스 컨테이너에서 실행 중인 PGSQL 버전을 확인할 수 있습니다.

로컬에서 데이터베이스를 확인하고 싶다면, 이 덤프 파일을 로컬 컨테이너에 직접 가져올 수도 있습니다.

AWS 복구 관련 문제

AWS 첨부 파일을 사용했지만 AWS CDN을 사용하지 않은 경우, 본문 내용은 AWS의 절대 경로 주소가 됩니다.

토론 주제 MD 파일에서의 표현 방식은 다음과 같습니다:

하지만, 콘텐츠가 게시되면 실제 HTML 코드는 Discourse에 의해 사용자의 CDN 절대 주소로 대체됩니다.

따라서, 위의 답변에 기반하여 백업 시 첨부 파일 백업을 선택하지 않더라도, 복원 시 첨부 파일 콘텐츠에는 영향을 주지 않습니다.

예외

사실 첨부 파일도 영향을 받을 수 있으며, 주로 도메인 변경 때문에 발생합니다.

초기에 한 번 도메인을 변경한 적이 있었는데, 첨부 파일 콘텐츠는 그대로였지만 본문에서는 연결이 되지 않았습니다. HTML을 재구성해도 연결이 되지 않았습니다.

이 경우 다소 번거로울 수 있으며, 데이터베이스를 직접 수정해야 할 수도 있습니다.

도메인을 함부로 변경하지 않는 한, 통상적으로 이는 문제가 되지 않습니다.

더 자세한 논의는 다음 주소를 방문하세요: Discourse 备份和恢复中有关附件的问题 - Discourse - iSharkFly

[copymonopoly]

혹시 다른 질문 하나만 더 해도 될까요? 저는 Amazon S3 대신 Cloudflare R2를 사용했고, R2에 백업을 성공적으로 완료했습니다. Cloudflare에서는 파일이 정상적으로 표시되지만, Discourse 관리자 화면에서는 백업 파일이 표시되지 않습니다. 어디에 문제가 있는 걸까요?

[honeymoose]

수동으로 한 번 더 백업을 수행하고 백업 로그를 확인하세요.

이 문제는 대부분 Discourse가 R2 스토리지에 백업된 후의 상태 확인 관련 API에서 오류가 발생하기 때문입니다.

로그의 내용이 모두 정상적으로 기록되어 있는지 확인해 보세요.

[copymonopoly]

방금 생성한 스크린샷인데, 화면상으로는 모든 것이 정상적으로 보입니다. 또한 R2에서 생성한 API는 최고 권한을 가진 것입니다.

[honeymoose]

@copymonopoly

방금 생성한 스크린샷인데, 모든 것이 정상적으로 표시되는 것 같습니다. 또한 R2에서 생성한 API는 최고 권한입니다.

제 백업 프로세스를 실행해 보니, 우리의 로그가 동일한 것 같습니다.

[2024-07-26 11:56:00] pg_dump: executing SEQUENCE SET category_custom_fields_id_seq
[2024-07-26 11:56:00] Finalizing backup...
[2024-07-26 11:56:00] Creating archive: isharkfly-2024-07-26-115540-v20240723030506.tar.gz
[2024-07-26 11:56:00] Making sure archive does not already exist...
[2024-07-26 11:56:00] Creating empty archive...
[2024-07-26 11:56:00] Archiving data dump...
[2024-07-26 11:56:00] Archiving uploads...
[2024-07-26 11:56:00] Skipping uploads stored on S3.
[2024-07-26 11:56:00] Removing tmp '/var/www/discourse/tmp/backups/default/2024-07-26-115540' directory...
[2024-07-26 11:56:00] Gzipping archive, this may take a while...
[2024-07-26 11:56:05] Uploading archive...
[2024-07-26 11:56:09] Executing the after_create_hook for the backup...
[2024-07-26 11:56:09] Deleting old backups...
[2024-07-26 11:56:10] Cleaning stuff up...
[2024-07-26 11:56:10] Removing archive from local storage...
[2024-07-26 11:56:10] Removing '.tar' leftovers...
[2024-07-26 11:56:10] Marking backup as finished...
[2024-07-26 11:56:10] Refreshing disk stats...
[2024-07-26 11:56:10] Notifying 'honeymoose' of the end of the backup...
[2024-07-26 11:56:18] Finished!

다음 단계로 데이터베이스 백업 테이블의 기록 문제인지 확인해 보겠습니다.

[copymonopoly]

당신도 R2를 사용하나요? 성공적으로 표시되는 거죠?

[honeymoose]

저는 AWS를 사용하고 있습니다.

이 부분은 쉽게 구성할 수 있어야 합니다.