업그레이드 중 Immich 설정 손실을 방지하는 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How to Prevent Immich Configuration Loss During Upgrades - Zima Store Online

업그레이드 중 Immich 구성 손실을 방지하려면 Compose 파일, 환경 값, 데이터베이스, 업로드 라이브러리, 외부 라이브러리 마운트 정의를 함께 캡처하고 복원해야 하는 별도의 영구 자산으로 취급하세요.

컨테이너는 교체할 수 있지만 컨테이너를 둘러싼 구성은 그렇지 않습니다. 상대 경로 바인드 마운트가 다른 프로젝트 디렉터리에서 확인되거나, 환경 변수 수정 사항이 재생성된 컨테이너에 전달되지 않거나, 새 스택이 빈 데이터베이스를 대상으로 시작하면 업그레이드로 Immich가 삭제된 것처럼 보일 수 있습니다. 먼저 현재 활성 배포를 파악하고, 호스트 외부에 버전별 사본을 보관하며, 운영 환경으로 전환하기 전에 제어된 재생성을 검증하세요.

모든 업그레이드 전에 활성 배포 캡처하기

시크릿을 가린 유효 Compose 구성을 내보내고, 이미지 버전 또는 다이제스트를 기록한 다음 Compose 파일과 환경 파일을 버전 관리 저장소에 복사하세요. 현재 컨테이너를 실행한 파일이 편집기에서 열어 둔 파일이라고 가정하지 말고 실행 중인 마운트를 점검하세요. 통과 조건은 각 런타임 경로가 알려진 호스트 위치에 매핑되는 것입니다.

외부 라이브러리 경로, 리버스 프록시 설정, 머신러닝 URL, 데이터베이스 연결 값, 사용자 및 그룹 ID, 네트워크 이름, 하드웨어 가속 장치를 기록하세요. 여기서 하나라도 빠지면 나중에 업그레이드 후 원인을 설명할 수 없는 차이가 발생합니다.

커뮤니티의 업그레이드 질문을 보면 어떤 Compose 세대 또는 환경 구성 레이아웃이 적용되는지 추적하지 못하는 운영자가 반복해서 나타납니다. 한 업그레이드 구성 논의에서 얻을 수 있는 유용한 교훈은 현재 정상적으로 작동하는 정의를 변환하기 전에 보존하라는 것입니다.

데이터베이스, 미디어, 배포 파일을 별도로 백업하기

데이터베이스 전용 백업과 함께 업로드 라이브러리 및 배포 디렉터리의 파일 시스템 백업 또는 스냅샷을 생성하세요. 시작 및 완료 시간, 아카이브 크기, 체크섬을 기록하세요. Compose YAML만 포함한 백업으로는 컨테이너를 재구축할 수는 있지만 계정, 메타데이터, 앨범 또는 에셋 레코드를 복원할 수 없습니다.

가장 단순한 일관성 경계를 원한다면 중지된 상태에서 백업하거나, 실행 중인 데이터베이스 덤프와 스토리지 스냅샷을 조정하여 두 백업의 관계를 문서화하세요. Immich가 외부 라이브러리의 원본을 소유하지 않더라도 경로와 접근 규칙이 복원된 서비스에 영향을 주므로 외부 라이브러리를 인벤토리에 포함하세요.

커뮤니티가 관리하는 주요 버전 업그레이드 절차에서는 데이터베이스, 미디어, Compose, 환경 입력을 보존하는 것을 강조합니다. 해당 순서를 운영 경험으로 참고하되, 실제로 배포하는 릴리스에 맞춰 각 단계를 확인하세요.

버전을 고정한 상태로 업그레이드 준비하기

건너뛴 각 버전의 릴리스 노트를 읽고 저장된 배포 정의를 신중하게 업데이트하세요. 대상 릴리스를 고정하고 기존 이미지를 삭제하지 않은 채 가져온 다음, 렌더링된 Compose 구성을 검증하세요. 알 수 없는 변수, 비어 있는 마운트 또는 서비스 버전 혼합이 발견되면 스테이징 검증을 통과할 수 없습니다.

용량이 허용된다면 백업을 별도의 포트와 운영 환경에 대한 쓰기 권한이 없는 격리된 테스트 스택에 복원하세요. 대상 버전으로 시작한 뒤 마이그레이션, 사용자, 스토리지 경로, 백그라운드 작업을 점검하세요. 컨테이너가 성공적으로 시작된 것만으로는 원래 라이브러리가 연결되었다고 입증할 수 없습니다.

관련 ZimaSpace 가이드인 안전한 셀프 호스팅 NAS는 업그레이드로 중단될 수 있는 단일 호스트 및 자격 증명 경계의 외부에 배포 파일과 백업을 배치하는 데 도움을 줍니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

재생성 후 구성의 지속성 검증하기

전환하기 전에 컨테이너를 기존 상태에서 재시작하지 말고 저장된 파일에서 테스트 컨테이너를 재생성하세요. 사용자, 서버 설정, 스토리지 템플릿, 라이브러리, 작업, 프록시 접근, 실제 적용된 환경 값을 확인하세요. 통과 조건은 구성이 문서화된 영구 구성 요소에 저장되어 교체 후에도 유지되는 것입니다.

운영 환경으로 전환한 후 테스트 에셋 하나를 업로드하고, 검색을 실행하고, 원본을 열고, 새로운 데이터베이스 백업을 생성하세요. 스택과 호스트를 재시작한 다음 이 과정을 반복하세요. 일반적인 워크로드가 관찰 기간 동안 안정적으로 유지될 때까지 이전 버전, 백업, 배포 정의를 보관하세요.

업그레이드가 이미 빈 상태로 시작되었다면 온보딩이나 새 업로드로 상태가 충돌하기 전에 중지하세요. 검증된 영구 경로만 다시 연결하거나 깨끗한 대상에 복원하세요. 예상한 사용자 또는 에셋이 없으면 롤백하고, 식별이 계속 불분명하다면 민감 정보를 제거한 유효 Compose 구성, 마운트, 버전, 백업 타임스탬프를 첨부해 에스컬레이션하세요.