여기서 주목할 만한 점은, Manjaro(컴퓨터와 모바일 기기를 위해 개발되는 주요 Linux 배포판 중 하나)가 Discourse 기반 포럼에서 치명적인 장애를 겪었다는 것입니다. 업데이트 실패로 인해 모든 업로드 파일과 기타 데이터가 손실되었고, 결국 이들은 거대한 Discourse 포럼을 처음부터 다시 구축하기로 결정했습니다. 단순한 참고 사항(fyi)이지만, meta* 커뮤니티에 이 사실을 알리는 것이 적어도 흥미롭다고 생각했습니다. 더 자세한 정보를 가지고 있지 않아 죄송합니다. 해당 포럼에서 논의를 계속하는 것이 더 적절할 수도 있습니다. 
7개의 좋아요
정말 끔찍하네요. 하지만 /var/discourse/shared 디렉터리를 모두 잃어버렸다면, 그들은 그냥 운이 나쁜 것입니다.
백업을 S3로 푸시하는 것은 좋은 아이디어입니다. Backblaze에는 10GB까지 무료로 업로드할 수 있고, 그 이후에도 여전히 저렴합니다.
4개의 좋아요
네, S3(또는 S3 호환) 자동 백업 업로드를 설정하는 것이 좋습니다. 기본값은 주 1회입니다.
4개의 좋아요
수동으로 해제해야 하는 대시보드 경고가 필요할까요?
현재 설치 환경은 서버 외부로 백업을 자동으로 전송하도록 설정되어 있지 않습니다.
기본적인 재해 복구(DR) 및 프로덕션 릴리스 프로세스에 대해 인지하지 못하는 사이트가 점점 더 많아지고 있습니다. 모든 사이트 소유자가 스테이징 복사본에서 테스트하는 번거로움을 감수하지는 않겠지만, 복원할 수 있는 것이 전혀 없는 사이트 소유자에게는 우리가 할 수 있는 일이 없습니다.
3개의 좋아요
그럴 수도 있겠지만, 웹 브라우저를 통해 가끔씩 수동으로 백업을 다운로드하거나, 실행할 전용 로컬 백업 스크립트를 사용하는 것도 방법입니다.
다행히도 이제 S3 지원이 다양한 서비스와 "S3 호환"이 되도록 개선되어(고맙습니다 @falco), 자동 백업에 대해 Amazon에 종속되지 않아도 됩니다!
3개의 좋아요
클라우드에 대한 이런 이야기들이 결국 플랫 설치(flat install)가 얼마나 취약한지를 잊게 만든다고 생각합니다.
$5짜리 VPS를 쓰든, $500짜리 인프라를 쓰든, 심지어 $5000짜리를 쓰든 마찬가지입니다. 백업을 서버 밖으로 보내지 않고, 이상적으로는 이미지를 s3에 저장하지 않는다면, 모든 것이 /var/discourse/shared 안에 존재하게 되며, 그 모든 것이 손실될 수 있습니다.
7개의 좋아요
데이터를 두 개 이상의 디바이스에 저장해야 한다는 사실을 사람들이 모른다면, 그들을 교육하는 것이 불가능하다고 생각합니다. 운영체제를 개발하는 사람이 데이터가 단 하나의 디바이스에만 저장되어 있다는 가능성을 이해하는 데 꽤 오랜 시간이 걸렸고, 어떤 방법으로든 이를 해결할 수 있다고 가정했지만, 아무도 저에게 질문하지 않았습니다.
제 계획 목록에는 자동 설치에 Backblaze 지원을 추가하는 것이 있습니다. 작은 사이트의 경우, 무료로 상당한 양의 백업(10GB)을 유지할 수 있습니다.
4개의 좋아요
문제는 아직 모든 이미지(예: 아바타 등)가 S3에 저장되어 있지 않다는 점입니다.
1개의 좋아요