저장 경로를 변경한 후 Immich에 오래된 데이터가 표시됨

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

스토리지 경로를 변경한 후 Immich에 오래된 데이터가 남는 원인은 서로 혼동해서는 안 되는 세 가지로 나뉩니다. 관리형 미디어 루트 이동, 외부 라이브러리 가져오기 경로 변경, 또는 여전히 캐시된 상태를 표시하는 클라이언트입니다. 최신 Immich 버전에서는 구성된 미디어 위치와 볼륨 마운트가 일관되게 유지되면 이동된 관리형 미디어 위치를 조정할 수 있지만, 외부 라이브러리 이동은 여전히 새로운 자산 ID로 처리될 수 있습니다.

다시 스캔하기 전에 기존 경로와 데이터베이스를 보존하세요. 먼저 실행 중인 컨테이너에서 어떤 경로가 보이는지 확인한 다음, Immich 서버 측 기록이 잘못된 것인지 아니면 특정 클라이언트만 오래된 상태인지 파악하세요. 이 구분에 따라 마운트를 수정할지, 컨테이너에서 안정적으로 보이는 경로를 복원할지, 테스트 하위 집합을 다시 스캔할지, 또는 클라이언트 캐시만 지울지가 결정됩니다.

관리형 미디어 루트 이동과 외부 라이브러리 이동 구분하기

Immich 관리형 업로드의 호스트 위치를 변경했다면 실제 미디어 위치 설정과 호스트-컨테이너 마운트가 함께 변경되었는지 확인하세요. 최신 관리형 미디어 이동은 외부 라이브러리 가져오기 경로의 이름을 변경한 경우와 같은 방식으로 진단해서는 안 됩니다.

여기서는 ZimaSpace의 Immich 영구 상태 지도가 유용합니다. 데이터베이스와 파일 시스템 경로는 하나의 복구 경계를 구성하기 때문입니다. 호스트에 올바른 파일이 있어도 컨테이너가 다른 위치에 마운트되어 있다면 충분하지 않습니다.

관리형 미디어 루트가 일치하지 않는다면 라이브러리 작업을 실행하기 전에 환경과 볼륨 매핑을 먼저 수정하고 서비스를 다시 시작하세요. 변경된 경로가 외부 라이브러리에 속한다면 데이터베이스를 그대로 유지하고 해당 경우를 별도로 테스트하세요.

가능하면 외부 라이브러리의 컨테이너 경로를 그대로 유지하기

외부 라이브러리의 경우 컨테이너에 표시되는 가져오기 경로를 그대로 유지할 수 있을 때 호스트 측 스토리지 이동이 가장 안전합니다. Immich에 표시되는 경로가 변경된다면 스캔 전에 소수의 자산 ID, 앨범, 사람 정보 및 기존 경로를 기록해 두세요. 이를 통해 기존 자산이 다시 연결된 것인지 새로 생성된 것인지 확인할 수 있습니다.

Immich의 외부 라이브러리 경로 변경 보고서에서는 이동된 파일이 새 자산으로 처리되고 재처리와 Immich에서만 유지되는 관계 정보의 손실이 발생했다고 설명합니다. 버전에 따라 달라지는 사례이지만, 변경된 외부 라이브러리 경로가 자동으로 투명한 이름 변경으로 처리된다고 가정해서는 안 된다는 보수적인 원칙을 뒷받침합니다.

테스트 하위 집합이 새 자산으로 나타나고 기존 기록이 누락되거나 휴지통으로 이동한다면 전체 재스캔을 중지하세요. 가능하다면 기존 컨테이너 표시 경로를 복원하거나 버전에 맞는 마이그레이션 방법을 사용하세요. 테스트된 백업 없이 운영 데이터베이스의 경로를 수동으로 수정하지 마세요.

이 경우를 Immich 관리형 파일의 저장 템플릿 마이그레이션과 혼동하지 마세요. 타임라인에서 증상이 비슷해 보일 수 있지만 파일의 소유권과 지원되는 마이그레이션 경로가 다릅니다.

저장된 서버 경로와 클라이언트 캐시 구분하기

웹 클라이언트와 인증된 다른 클라이언트에서 동일한 자산을 확인한 다음, 이를 서버 로그 또는 서버에 표시되는 경로와 비교하세요. 서버 측 작업이 여전히 이전 경로를 기록한다면 브라우저 캐시를 지워도 근본적인 기록은 수정되지 않습니다.

이후 Immich의 이전 경로 메타데이터 이슈에서는 이름을 변경한 후에도 처리가 이전 외부 라이브러리 경로를 계속 참조하는 현상이 나타났습니다. 이는 모바일 또는 웹 UI를 원인으로 보기 전에 작업 측 경로를 확인해야 한다는 강력한 근거입니다.

서버 경로가 올바른데 웹 화면 하나에서만 오래된 상태가 보인다면 해당 클라이언트의 캐시를 새로 고치거나 삭제한 후 원본 파일을 다시 확인하세요. 캐시된 썸네일과 오래된 클라이언트 상태 때문에 정상적으로 수정된 서버가 고장 난 것처럼 보일 수 있으며, 반대로 캐시된 미리 보기 때문에 잘못된 서버 경로가 정상인 것처럼 보일 수도 있습니다.

-15% OFF

가장 작은 경로 경계를 수정하고 통제된 재스캔 검증하기

한 번에 되돌릴 수 있는 수정 하나만 적용하세요. 관리형 미디어 설정과 마운트를 동기화하거나, 기존 외부 라이브러리 컨테이너 경로를 복원하거나, 가져오기 경로를 수정하거나, 클라이언트 캐시 하나를 삭제하는 방식입니다. 대규모 라이브러리가 다시 검색될 수 있는 작업을 하기 전에 데이터베이스를 백업하세요.

실행 가능한 가장 작은 범위로 재스캔을 수행하고 기존 기록의 연결이 유지되는지, 이전 경로 오류가 사라지는지, 이전 자산과 새 자산의 중복이 나타나지 않는지 확인하세요. 그런 다음 샘플 원본을 열어 앨범 및 사람 관계를 확인하고, 검색을 실행한 뒤 스택을 다시 시작하세요.

이전 경로와 새 경로의 기록이 동시에 활성 상태로 남아 있거나, 대규모 외부 라이브러리가 예기치 않게 다시 처리되거나, 원본을 읽을 수 있는데 관계 정보가 사라진다면 추가 조사를 진행하세요. 변경 전후의 정확한 마운트 구성, Immich 버전, 영향을 받은 자산 ID, 파일 시스템의 대소문자 처리 방식, 데이터베이스 백업 시각을 보존하세요.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.