2025년 커뮤니티 튜토리얼에서는 데이터베이스, 머신러닝 캐시, 서버의 볼륨 매핑을 수정하여 Immich 데이터를 ZimaOS 시스템 드라이브에서 다른 위치로 옮겼습니다. 원 작성자와 이후 여러 사용자에게는 정상적으로 작동했지만, 해당 스레드에는 설치 실패, 비정상 상태의 데이터베이스 컨테이너, 실험 후 업로드 파일이 손상되었다는 보고도 있습니다.
현재 시스템에서는 해당 스크린샷을 모든 경우에 그대로 적용하는 복사·붙여넣기식 레시피가 아니라 컨테이너 아키텍처에 대한 설명으로 이해하세요.
먼저 최신 ZimaOS 마이그레이션 경로 사용
최신 Immich 저장소 마이그레이션 문서는 기존 스레드의 내용을 구체적으로 보완합니다. 목적에 맞는 경우 ZimaOS 마이그레이션을 사용하고, 사용자 지정 저장소 구성이 필요할 때만 수동 볼륨 편집을 사용하세요. Immich가 관리하는 업로드 라이브러리 외부에 유지해야 하는 외부 라이브러리의 경우, Immich 외부 드라이브 설정에서 호스트 경로와 컨테이너 경로를 별도로 매핑하는 방식을 설명합니다.
기존 볼륨 편집의 역할
스크린샷에는 서로 다른 저장소 역할이 표시되어 있습니다. PostgreSQL 데이터, 머신러닝 캐시, 업로드된 미디어는 서로 대체할 수 없습니다. ZimaOS의 호스트 측 경로가 변경되더라도 컨테이너 내부 경로는 애플리케이션 계약의 일부입니다.
최신 Immich는 업로드와 데이터베이스 위치를 분리해 사용
공식 Immich Docker Compose 설정은 현재 UPLOAD_LOCATION과 DB_DATA_LOCATION을 분리하며, 데이터베이스 위치에는 네트워크 공유를 지원하지 않는다고 명시적으로 경고합니다. 이는 모든 경로를 동일한 RAID 디렉터리로 옮기는 것보다 더 강력한 지침입니다.
Docker의 Docker 바인드 마운트 규칙은 각 바인드 마운트의 양쪽 경로를 올바르게 이해해야 하는 이유를 설명합니다. 첫 번째 경로는 ZimaOS 호스트에 있고 두 번째 경로는 컨테이너 내부에서 보이는 경로입니다. 두 경로를 불필요하게 모두 변경하면 애플리케이션이 기대하는 구성이 깨질 수 있습니다.
모든 Immich 경로를 하나의 묶음으로 변경하지 마세요
데이터베이스 데이터, 모델 캐시, 업로드 파일, 외부 라이브러리를 개념적으로 분리해 유지하세요. 마이그레이션 전에 여유 공간, 파일 시스템 권한, 백업 상태를 확인하세요. 현재 앱 패키지에 지원되는 마이그레이션 작업이 이미 제공된다면, 기존의 수동 구성을 재현하기 전에 해당 기능을 사용하세요.
결론
커뮤니티 가이드는 Immich를 이동할 수 있는 이유를 보여 주지만, 이후 답변들은 볼륨 매핑을 단순한 표시용 항목으로 취급할 때의 위험도 보여 줍니다. 최신 ZimaOS에서는 먼저 기본 제공 마이그레이션 절차를 사용하세요. 수동 매핑이 필요한 경우에는 Immich가 기대하는 컨테이너 경로를 유지하고 각 영속 데이터 유형을 신중하게 옮기세요.
