자체 호스팅 서버에서 Discourse를 안전하게 백업하는 올바른 방법?

안녕하세요,

셀프호스트드 서버에서 포럼이 영구적으로 사라지는 것을 방지하는 가장 좋은 방법은 무엇일까요? 소중한 데이터를 어떻게 적절하고 안전하게 백업할 수 있을까요?

현재 삭제된 토픽에서 @falco 님은 이렇게 말씀하셨습니다:

파일 시스템 스냅샷은 지원되지 않으며 데이터 손실을 초래할 수 있습니다.

또한 Hetzner의 백업 기능에 대해 회사는 이렇게 설명하고 있습니다:

디스크의 데이터 일관성을 보장하기 위해 서버를 종료할 것을 권장합니다.

그러면 이 방법은 실제로 권장되지 않는 솔루션인 것 같습니다… 아니면 그렇지 않나요?

제 포럼에서는 rclone을 사용하여 로컬 백업 폴더를 구글 드라이브 폴더와 동기화하고 있습니다.

서버가 고장 나면 구글 드라이브에 있는 주간 백업이 있습니다.
로컬 백업이 사라지고 rclone이 이제 비어 있는 폴더를 동기화한 후 드라이브의 백업을 삭제하더라도, 삭제된 백업은 구글 드라이브 휴지통에 남아있을 것입니다.

따라서 포럼 데이터를 안전하게 보호하는 합리적인 방법이라고 생각합니다.

하지만 정말 그런가요? 설치하기 쉬운 다른 신뢰할 수 있는 솔루션이 있을까요?
rclone에 대해: 이는 많은 저장 시스템과 호환됩니다. 백업을 저장하고 동기화하는 데 더 나은 선택지가 있을까요?

데이터를 100% 안전하게 저장하는 방법은 결코 없으며, 이를 명확히 인식하고 있습니다. Discourse는 예약 기반으로 실행되는 매우 훌륭한 백업 프로세스를 갖추고 있습니다.

많은 기기에 대한 신뢰도가 낮고 월별 지출을 늘릴 수 있다면, S3에 백업을 오프로딩하고 S3 복제를 활성화하는 것부터 시작하겠습니다. 이후 로컬 머신으로 데이터를 복사하는 스크립트를 작성하고, 월 1회 정도 모든 데이터를 외장 드라이브에 오프로딩하는 방식입니다.

이러한 방식으로 구성하면 동시에 모두 실패하지 않을 수 있는 충분한 장애 지점을 확보할 수 있습니다. S3의 신뢰성은 상당히 높으며, 매일 사용 중이므로 로컬 머신의 상태도 상당히 양호할 것입니다(물론 실패할 수는 있지만, S3에서 광범위하게 발생하는 장애보다는 훨씬 빠를 것입니다).

이 안전한 접근 방식은 정보 보안(암호화 등)을 따르지 않습니다. 따라서 가장 좋은 방법은 여러 위치에 여러 사본을 두는 것입니다.

/var/discourse/containers와 /var/discourse/shared/standalone/backups를 원격으로 동기화하면 됩니다. 서버가 중단되는 경우, 컨테이너 yml 파일과 최신 백업만 있으면 됩니다. 일일 백업을 권장합니다. 특히 정교하고 헌신적인 사용자라면 rsync 대상에 주 단위, 월 단위, 연 단위 백업을 유지하는 정리(trim) 프로세스를 적용할 수 있습니다.

방금 이 글을 작성했습니다: Best Practices for Backups

이 내용도 참고하세요:

자동으로 내장된 Amazon S3에 백업합니다.

저희는 수년간 rsync를 사용해 왔으며, 우리에게 잘 작동하고 있습니다. 매일 저희가 직접 관리하는 오프사이트 백업 위치에 rsync로 백업을 전송합니다. 이를 통해 데이터센터에 재앙이 발생하더라도 모든 데이터를 안전하게 확보할 수 있습니다. :slight_smile:

또한 백업과 보안을 고려할 때, IT 보안은 세 가지 핵심 영역으로 구성됨을 명심해야 합니다:

  • 가용성 (Availability)
  • 무결성 (Integrity)
  • 기밀성 (Confidentiality)

데이터를 백업할 때는 이 세 가지 영역을 모두 고려해야 합니다.

높은 기밀성 요구 사항이 있는 경우, 제3자 솔루션(또는 엄격한 행정적 통제가 불가능하고 타인에게 속하는 클라우드)으로 백업하는 것이 최선의 선택이 아닐 수 있습니다.

보안은 만능 해결책이 아니며, 고유한 위험 관리 모델에 기반합니다. 이 역시 세 가지 핵심 영역으로 구성됩니다:

  • 위협 (Threat)
  • 취약점 (Vulnerability)
  • 중요도 (Criticality)

이 세 가지 영역의 교차점이 여러분의 백업 및 복구 전략을 결정하는 데 도움을 줍니다.

  • 콘텐츠나 도메인(비즈니스 모델)에 따라 위협을 더 많이 받는 웹사이트가 있는 반면, 악의적 공격자의 관심을 거의 받지 않는 곳도 있습니다.
  • 일부는 안전하게 호스팅하는 방법, 최신 패치 설치, 파일 시스템 보안 설정 등을 잘 알고 있어, 이 분야에 지식이 부족하거나(또는 게을러서) 그렇지 않은 사람들보다 취약점이 적습니다.
  • 일부는 매우 임무 중요한 웹사이트나 포럼을 운영합니다. 예를 들어 웹사이트가 다운되면 하루(또는 한 시간) 만에 막대한 금전적 손실을 입거나 브랜드의 신뢰성이 훼손될 수 있습니다.
  • 반면, 웹사이트가 다운되어도 몇 명만 알아채거나 신경 쓰고 금전적 손실이 없는 경우도 있습니다.

따라서, 이 흥미로운 주제를 보안 전문서로 만들지 않으면서도, 타인의 위험 관리 모델이 아닌 여러분의 고유한 비즈니스 모델과 위험 요인에 기반한 자체 위험 관리 요구 사항을 이해해야 합니다.

“만능 해결책은 없다”… 그리고 이는 IT 보안에 대해 IT 전문가들이 이해할 수 있는 가장 중요한 교훈 중 하나입니다(하지만 실제로 이해하는 사람은 매우 적습니다). 백업과 복구는 이 방정식의 핵심 부분입니다.

참고로: 저희는 백업을 절대 제3자에게 위탁하지 않습니다(절대). 그리고 항상 저희의 기술적 및 행정적 통제 하에 있는 안전한 위치에 보관합니다.


부연 설명으로, 제 친구는 세계 최고의 동굴 탐험가(수중 동굴 탐험가) 중 한 명입니다. 그가 수중 동굴을 다이빙하며 탐험할 때, 그는 이중 및 삼중의 중복 구조(가스, 마스크, 컴퓨터, 조명, 배터리, 칼, 스쿠터 등)를 갖추고 있습니다. 저는 그가 40개 이상의 가스 병을 준비하고 최소 두 개의 수중 스쿠터를 휴대하는 것을 본 적이 있습니다. 그는 수중에서 위험을 관리하는 방법을 잘 알고 있습니다.

그러나, 이 세계적으로 유명한 스쿠버 다이빙 동굴 탐험가는 데스크톱 컴퓨터를 백업하지 않으며, 노트북이 충돌하여 모든 데이터를 잃고 온라인에 접속하는 경우가 종종 있습니다. 그는 파워포인트 프레젠테이션을 잃는 것이 신경 쓰이지 않는다고 말합니다… 이는 그의 개인적인 위험 관리 전략입니다. 그는 몇 개의 디지털 파일보다 자신의 생명을 훨씬 더 중요하게 여깁니다.

인생이란 그런 것이죠…


그러므로, 질문에 답하자면. 저희는 거의 30년 동안 자체 호스팅을 해 왔습니다. 항상 rsync와 sftp를 사용하여 저희가 접근할 수 있는 서버에 오프사이트로 백업을 유지해 왔으며, 인터넷에 서버를 운영한 30년 동안 한 번도 문제가 없었습니다. 심지어 제 가정 네트워크의 작은 Mac Mini에 사적인 저장 장치로 여분 카피를 하나 더 두고 있습니다. 이것이 제가 "안전"이라고 생각하는 것입니다… 제 위험 관리 모델에 기반하여 말이죠.

이 모든 정보에 대해 감사합니다 :+1:t6:

왜 s3에 대해 언급하지 않았는지 궁금하네요 :thinking: 무의식적으로 무료 백업 방법을 생각하고 있었는지도 모릅니다… gdrive 구독은 가지고 있는데도요 :upside_down_face:

그렇다면 Discourse 백업 저장에 관한 s3 비용을 적절하게 추정하는 방법은 무엇일까요?
계산기 필드를 어떻게 채워야 할지 확실하지 않습니다:


제 경우, 업로드를 포함한 백업은 약 1GB이고, 하루에 한 번 백업을 수행하며 백업 보존 기간은 4~7일 정도일 것 같습니다.

또한 언급하지 않은 또 다른 점은 공동 관리자(co-administrator)에게도 원격 백업에 대한 접근 권한을 부여하고 싶다는 것입니다.
현재 gdrive에서는 백업이 저장된 디렉토리를 그와 공유하고 있습니다.
s3 백업에 대한 접근 권한도 공유할 수 있을까요?

월 7GB-개월(향후 확장 여지 포함)의 비용을 예상해야 하며, 백업 파일을 실제로 다운로드할 때마다 추가 전송 요금이 부과됩니다.

백업 전송 또는 검색 = 1개의 요청?