백업 데이터가 갑자기 줄어든 것을 발견했고, 줄어든 데이터의 백업 복구가 정상적으로 이루어지지 않았습니다. 또한 웹사이트에서 정상적인 상호작용이 불가능한 상태였습니다. 다행히도 아마존 S3 버킷에서 과거 데이터를 찾을 수 있었지만, 그렇지 했다면 그 손실은 헤아릴 수 없었을 것입니다.
해당 시간대에 업로드가 백업에 포함되는지에 영향을 미칠 수 있었던 설정 변경 사항이 있었나요?
그 시점에 2컨테이너 구성으로 변경했나요, 아니면 항상 그렇게 사용했나요?
이렇게 계속 사용하게 되면 발생할 수 있는 원인은 대체로 무엇일까요?
며칠 전에 최신 백업을 복원해 보았는데, 대시보드에 업로드를 시도했을 때 거부되었습니다. 순간 백업이 사라진 줄 알았죠. 그래서 FTP로 한 번 더 업로드를 시도해 보았습니다. 그리고 놀랍게도 복원이 성공했습니다. 그런데 이런 상황이 반복되고 있어서, 그 원인이 무엇인지 알고 싶습니다.
표준 설치 방식에는 더 익숙해서, 컨테이너 2개 구성 방식에 여기서 관련이 있을 수 있는 특이한 점이 있는지 잘 모르겠습니다.
#installation 채널로 넘겨서 더 경험이 많은 분들의 도움을 받아볼게요. 
(@pfaffman 
)
지금까지는 표준 설치(Standard Install)를 사용했지만, 표준 설치에는 문제가 있습니다. app.yml 파일을 수정할 때마다 웹사이트에 정상적으로 접근할 수 없었습니다. data.yml이나 web_only.yml을 사용하면 웹사이트 접근에 영향 없이 web_only.yml 파일을 수정할 수 있습니다. 표준 설치에도 이와 유사한 기능이 있는지, 있다면 구체적으로 어떻게 사용하는지 알고 싶습니다.
아니요. 유일한 차이는 재빌드(rebuild) 시 rails와 nginx 부분만 다시 빌드된다는 점입니다. 데이터베이스와 redis는 그대로 유지됩니다. 이 둘은 거의 변경되지 않으므로 재빌드가 필요하지 않습니다. 동작 방식은 똑같습니다. 이 부분은 충분히 이해하고 계실 것입니다. (유일한 복잡성은 postgres나 redis 업데이트가 있을 때인데, 보통 1년에 한 번 정도입니다. 다만 AI 플러그인의 요구 사항으로 인해 데이터베이스 업데이트가 몇 번 있었습니다. 따라서 AI 플러그인을 사용하지 않았다면 아무 문제가 없었을 것이고, 사용 중이었다면 데이터 컨테이너도 함께 재빌드하지 않으면 이해하기 어려운 데이터베이스 오류가 발생했을 것입니다.)
제 추측에 따르면, 그들은 자산을 S3로 이동시켰고, 그래서 로컬 업로드가 포함되지 않은 것 같습니다. 이는 그들이 S3에서 데이터를 복원할 수 있었다고 말한 내용과 일치합니다. 또는 업로드가 포함된 게시물을 삭제하여, 이후의 백업에 해당 업로드가 포함되지 않았을 수도 있습니다.
또한, 복원 작업을 수행하고 완료까지 기다리지 않은 것 같다는 인상을 받았습니다.
실제로 AI 플러그인을 사용했습니다. 백업 데이터를 사용할 수 있도록 하기 위해 무엇을 주의해야 하며, 이러한 문제를 어떻게 대응하고 처리해야 할까요?
I did use an AI plug-in. What should I pay attention to so that the backup data can be used? How should we deal with this kind of problem
data.yml를 리빌드하지 않는 한 문제가 없다는 뜻인지, 아니면 app.yml을 사용해야 하는지, 혹은 이러한 문제가 data.yml의 web_only 방식과 app.yml 방식 모두에 존재하는지 묻는 것입니다
It means that as long as data.yml is not rebuilt, there is no problem, or is it necessary to use app.yml, or this kind of problem exists in both the data.yml web_only plan and the app.yml plan
문제는 제가 백업할 때 data.yml로 생성된 컨테이너가 지원되지 않았고, 데이터베이스가 업그레이드되었다는 것입니다. data.yml 재구성이 업그레이드된다면, 여러분이 대규모 데이터베이스 업그레이드를 수행하더라도 문제가 발생하지 않으며, 그런 후에 백업과 복구를 수행하는 것에도 문제가 없습니다. 그런데 어떻게 여러분의 데이터베이스에 큰 변경 사항이 있었는지를 알 수 있을까요?
문제는 제가 백업할 때 data.yml로 생성된 컨테이너가 지원되지 않았고, 데이터베이스가 업그레이드되었다는 것입니다. data.yml 재구성이 업그레이드된다면, 여러분이 대규모 데이터베이스 업그레이드를 수행하더라도 문제가 발생하지 않으며, 그런 후에 백업과 복구를 수행하는 것에도 문제가 없습니다. 그런데 어떻게 여러분의 데이터베이스에 큰 변경 사항이 있었는지를 알 수 있을까요
@sober, 프로세스 관련 참고사항으로, 함께 읽고 있거나 도움을 주고자 하는 사람들에게는 게시글에 영어 번역을 포함해 두는 것이 훨씬 편합니다. 번역을 하나 편집해서 넣어 주시겠어요? 
이제 문제가 데이터베이스의 대규모 업그레이드로 인해 백업 문제가 발생했다는 것을 이해했습니다.
뭐? 확인이 올 때까지 기다릴게. 여기서 뭔가 깨질지 모르겠으니까.
저는 dev가 불안정할까 봐 beta2-dev가 아닌 beta2만 업그레이드하고 싶습니다. 최근 데이터 백업을 정상적으로 복원할 수 없어 거의 데이터 손실이 발생했기 때문입니다. 초기 백업을 사용했지만, 그 기간 동안에도 데이터가 손실되었습니다.
불안정하지 않습니다. 그것은 최근 버전 관리 시스템에 적용된 변경 사항일 뿐입니다. 기술적으로, -dev 라벨을 보는 것은 원래 허용되지 않습니다.