호환되지 않는 릴리스 이후 Immich를 안전하게 롤백하는 방법

현재 상태를 보존하고 최신 릴리스가 이전 이미지에서 읽을 수 없는 방식으로 데이터베이스나 구성을 변경했는지 확인한 후에만 Immich를 롤백하세요.

컨테이너 이미지는 교체할 수 있지만 영구 상태는 이미 마이그레이션되었을 수 있습니다. 업그레이드에 문제가 발생하면 자동 업데이트와 새 쓰기 작업을 중지하고, 이전 버전과 새 버전을 기록하며, 현재 데이터베이스와 미디어를 보호한 다음 간단한 이미지 롤백을 진행할지 업그레이드 전 복구 지점을 복원할지 결정하세요.

상태가 더 변경되기 전에 실패한 업그레이드 동결하기

증거를 수집하는 동안 자동 이미지 업데이트를 비활성화하고 클라이언트가 새 사진을 추가하지 못하게 하세요. 이전 버전과 새 Immich 이미지의 정확한 버전 또는 다이제스트, PostgreSQL 버전, Compose 및 환경 파일, 마운트 경로, 최초 시작 또는 마이그레이션 오류를 기록하세요.

컨테이너 롤백 경계에 관한 ZimaSpace 가이드는 중요한 차이를 설명합니다. 영구 볼륨은 이미지 교체 후에도 유지되지만, 볼륨 내부의 상태와 이전 애플리케이션이 호환될 때만 안전합니다.

데이터베이스를 읽을 수 있다면 현재 실패한 상태를 데이터베이스 자체 방식으로 백업하고, 업그레이드 전 백업은 별도로 보존하세요. 반복적인 실험으로 어느 백업도 덮어쓰지 마세요. 당장의 목표가 이전 버전으로 돌아가는 것이더라도 나중에 복구를 진행하려면 현재 사본이 필요할 수 있습니다.

릴리스가 데이터베이스 마이그레이션 경계를 넘었는지 확인하기

업그레이드 후 최초 오류를 살펴보고, 데이터베이스 마이그레이션 전이나 도중에 발생했는지, 마이그레이션 후 애플리케이션 시작 과정에서 발생했는지, 아니면 특정 사용자 작업 중에만 발생했는지 확인하세요. 이전 이미지가 최신 릴리스에서 이미 변경한 스키마를 이해하지 못할 수 있으므로, 이 시점에 따라 롤백 계획이 달라집니다.

서비스가 업그레이드 경로 이후 시작되지 않은 최근 Immich 보고서는 지원되지 않거나 건너뛴 마이그레이션 경로가 단순한 버전 교체를 불안정하게 만들 수 있는 이유를 보여줍니다. 해당 글은 사례 연구로만 참고하고, 사용 중인 버전에 맞는 정확한 마이그레이션 순서를 확인하세요.

최신 애플리케이션이 데이터베이스를 전혀 수정하지 않았고 문제가 이미지 또는 런타임 호환성에 국한된다면, 특정 이미지로 고정한 롤백만으로 충분할 수 있습니다. 마이그레이션이 완료되었다면, 명시적인 호환성 근거가 없는 한 업그레이드 전 데이터베이스 백업이 이전 이미지와 함께 사용하는 더 안전한 선택이라고 가정하세요.

서로 다른 시기의 구성 요소를 섞지 말고 호환되는 데이터베이스와 런타임 복원하기

마지막으로 정상 작동한 애플리케이션 버전, 이에 호환되는 배포 구성, 호환되지 않는 변경 전의 데이터베이스 복구 지점을 사용해 롤백 대상을 구성하세요. 릴리스가 문서화된 방식으로 미디어 파일을 변경한 경우가 아니라면 미디어 트리는 그대로 유지하세요. 애플리케이션 이미지만 변경되었다는 이유로 수 테라바이트의 데이터를 다시 복사하지 마세요.

데이터베이스 호환 롤백 계획에 관한 논의에서는 더 이상 이해하지 못하는 스키마에 이전 코드를 배포할 때의 일반적인 위험을 설명합니다. 컨테이너 자체가 성공적으로 시작되는지보다 이 원칙이 더 중요합니다.

검증이 끝날 때까지 모바일 클라이언트와 예약 작업이 쓰기 작업을 수행하지 못하도록 롤백 인스턴스를 격리된 상태로 시작하세요. 이전 버전에서 즉시 스키마 오류를 보고하면 중지하세요. 테스트된 버전별 복구 절차가 없는 한 유일한 데이터베이스 사본에서 마이그레이션을 수동으로 되돌리려 하지 마세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

정확히 정상 작동이 확인된 이미지를 고정하고 구성을 재현하기

변경되는 태그 대신 특정 버전 또는 변경 불가능한 이미지 참조를 사용하세요. 마지막으로 정상 작동한 배포의 환경, 서비스 종속성, 장치 매핑, 네트워크, 포트, 리버스 프록시 대상을 일치하도록 복원하세요. 여러 인프라 계층을 아무도 모르게 변경하는 롤백은 또 다른 장애를 만듭니다.

실패한 최신 이미지와 구성은 롤백 기록과 함께 보존하세요. 이렇게 하면 호환성 문제를 파악한 후 통제된 정방향 복구를 진행할 수 있습니다. 모든 새 아티팩트를 즉시 삭제하면 실패한 상태와 작동하는 상태를 비교하거나 테스트 환경에서 업그레이드를 재현하기가 어려워질 수 있습니다.

복원된 상태에서 이전 서비스가 시작되면 클라이언트를 활성화하기 전에 로그를 확인하세요. 예상치 못한 마이그레이션 시도, 신규 설치 초기화, 누락된 스토리지 마운트 또는 권한 재설정이 없는지 확인하세요. 로그인 페이지가 표시되는 것만으로 롤백이 의도한 데이터를 사용하고 있다고 판단할 수는 없습니다.

원래 트리거 조건에서 이전 버전을 검증하고 정방향 복구 경로 유지하기

대표적인 사용자, 기존 및 최근 에셋, 앨범, 공유, 검색, 통제된 새 업로드 1건, 백그라운드 작업, 데이터베이스 백업 생성, 리버스 프록시 경로를 테스트하세요. 스택을 한 번 재시작한 뒤 수동 개입 없이 동일한 마운트와 데이터베이스가 다시 연결되는지 확인하세요.

검사가 통과할 때까지 새 업로드를 일시 중지한 다음 액세스를 다시 열고 정상적인 작업 시간 동안 상태를 관찰하세요. 호환성 문제를 파악한 후 격리된 사본에서 업그레이드를 다시 시도할 수 있도록 업그레이드 전 백업과 실패한 최신 상태의 백업을 모두 보존하세요.

이전 버전에서 스키마 비호환성을 보고하거나, 알려진 데이터가 누락되거나, 쓰기 작업이 예상치 못한 경로에 저장된다면 롤백은 실패한 것입니다. 복구 지점을 다시 보존한 상태로 복원하고 수리를 계속 덧붙이지 마세요. 정확한 버전, 마이그레이션 로그, 데이터베이스 백업 시각, Compose 차이점, 최초로 실패한 검증 단계를 포함해 문제를 에스컬레이션하세요.