Immich에서 중복 작업 또는 가져오기를 방지하는 방법

Immich 작업이나 가져오기가 중복되는 것을 방지하려면 먼저 서로 다른 두 가지 증상을 구분해야 합니다. 동일한 백그라운드 작업이 다시 실행되는 경우와 동일한 사진이 둘 이상의 에셋이 되는 경우입니다. 그런 다음 무엇이 두 번째 이벤트를 만들었는지 확인하세요. 클라이언트, 가져오기 도구, 라이브러리 스캔, 경로 변경 또는 재시도 중 무엇이 원인인지 파악하기 전에는 아무것도 삭제하지 마세요.

가장 안전한 설계는 각 에셋 그룹에 하나의 표준 수집 경로를 지정하는 것입니다. 과거 클라우드 아카이브, 외부 라이브러리, 현재 사용하는 휴대폰 백업은 모두 유효할 수 있지만, 동일한 파일에 대한 소유권이 겹치면 중복 레코드나 재업로드 루프가 발생할 수 있으며, 가져온 후 정리하는 것만으로는 안정적으로 해결되지 않습니다.

반복 작업인지 중복 에셋인지 확인하기

반복 작업의 경우 대기열 이름, 에셋 ID, 시작 시간, 완료 또는 실패 상태, 그리고 새 작업에 앞서 발생한 이벤트를 기록하세요. 메타데이터 작업 후 생성된 정상적인 후속 작업과, 동일한 실패 작업이 계속 재시도되는 상황은 서로 다릅니다. 어떤 패턴인지 알기 전에는 모든 대기열을 비우지 마세요.

중복 에셋의 경우 소스 라이브러리, 원본 경로, 가능한 경우 체크섬 동작, 기기 백업 상태, 촬영 시간 및 파일 크기를 비교하세요. 클라우드 내보내기, 메타데이터 편집, 트랜스코딩 또는 경로 기반 외부 라이브러리 처리 후에는 동일하게 보이는 사진이 서로 다른 파일로 존재할 수 있습니다. 반대로 바이트 단위로 동일한 파일이 서로 다른 Immich 라이브러리 소스에 존재할 수도 있습니다.

일반 업로드에서 반복적인 체크섬 오류나 고유 제약 조건 오류가 발생하기 시작하면, 해당 증상을 가져오기 소스 문제로 간주하기 전에 데이터베이스를 보존하고 마이그레이션 및 스키마 상태를 확인하세요. 두 개의 정상적인 소스 유형에 걸친 중복 에셋과 데이터베이스 제약 조건 실패는 서로 다른 분기이므로 동일한 정리 절차를 적용해서는 안 됩니다.

휴대폰 백업 상태 및 모바일 예약에 관한 ZimaSpace 가이드는 유용합니다. 모바일 클라이언트는 무엇을 아직 백업해야 하는지 자체적으로 판단하기 때문입니다. 클라이언트 상태를 무시한 서버 측 정리는 다음 휴대폰 세션에서 파일이 다시 전송되는 원인이 될 수 있습니다.

기존 사진 그룹마다 하나의 표준 수집 경로 사용하기

지속적인 휴대폰 백업을 활성화하기 전에 오래된 사진을 Immich에 추가할 방식을 결정하세요. 예를 들어 과거 아카이브를 한 번 가져와 확인한 다음, 휴대폰에서는 새로 촬영한 사진만 추가하도록 합니다. 동일한 과거 파일을 외부 라이브러리로 마운트하는 동시에 일반 업로드 라이브러리를 통해 업로드한다고 해서 전역 중복 제거가 두 소스를 자동으로 조정한다고 가정하지 마세요.

Immich의 소스 간 중복 보고서에는 외부 라이브러리와 업로드 라이브러리에서 온 동일한 콘텐츠가 함께 존재하는 사례가 기록되어 있습니다. 이를 프로젝트 동작의 경계로 간주하세요. 소스의 소유권이 중요하므로, 나중에 중복 제거 도구가 원하는 사본을 추론하기를 기대하기보다 사전에 중복을 방지하는 편이 더 안정적입니다.

휴대폰이 해당 파일을 여전히 백업 대상에 포함하고 있는 동안 Immich가 내부적으로 업로드한 파일을 몰래 외부 라이브러리로 이동하지 마세요. 저장소 구조를 반드시 변경해야 한다면 백업을 만들고 소규모 테스트 그룹을 사용해 문서화된 경로로 마이그레이션한 다음, 이전 사본을 삭제하기 전에 모바일 앱과 서버의 상태가 일치하는지 확인하세요.

가져오기를 확대하기 전에 재시도와 클라이언트 상태 제어하기

대규모 수동 가져오기에는 스테이징 매니페스트를 사용하세요. 가능한 경우 소스 경로, 파일 수, 총 바이트 수, 안정적인 체크섬 또는 가져오기 결과를 기록합니다. 가져오기가 중단되면 첫 번째 작업의 상태가 불확실한 동안 동일한 소스에 대해 두 번째 독립 가져오기를 시작하지 말고, 같은 도구와 대상 경로를 통해 재개하세요.

최근 Immich의 반복 업로드 보고서에서는 서버에 이미 존재하는 에셋을 모바일 클라이언트가 계속 재시도했고, 서버에서 고유 제약 조건 오류가 발생했습니다. 이는 특정 버전에서 클라이언트 백업 상태가 루프의 원인일 수 있다는 증거로 취급하세요. 이를 모든 모바일 앱에 해당하는 일반적인 동작으로 확대 해석하지 마세요. 경로 변경은 별도의 위험 요소입니다. 대규모 가져오기 중에는 컨테이너에서 보이는 외부 라이브러리 경로를 안정적으로 유지하고, 저장소를 이동해야 한다면 먼저 소규모 그룹으로 테스트하세요. 경로 변경 후에만 두 번째 사본이 나타난다면 휴대폰 백업 상태를 초기화하지 말고 경로 식별자 분기를 따르세요.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

중단, 재시도 및 실제 신규 에셋 테스트하기

일반 사진, 동영상, 편집된 이미지, 그리고 대상 경로에 이미 존재하는 파일을 하나 이상 포함하는 대표적인 소규모 그룹을 만드세요. 한 번 가져온 후 에셋 수와 ID를 기록하고, 운영 환경에서 사용할 워크플로에 따라 두 번째 시도 또는 재스캔을 통제된 방식으로 중단하세요.

테스트가 성공하려면 동일한 소스 객체에 대해 설명할 수 없는 두 번째 에셋이 없어야 하고, 재시도가 영구적으로 증가하는 대기열 없이 안정되어야 하며, 실제로 새로 추가된 사진도 정상적으로 가져와져야 합니다. 또한 테스트 후 모바일 클라이언트를 다시 열어 백업 상태가 서버와 조용히 불일치하지 않도록 하세요.

업로드 소스와 외부 라이브러리 소스 사이에서만 중복이 다시 발생한다면 계속 병합하기보다 소유권 경계를 재설계하세요. 동일한 에셋 ID에 실패한 작업이 끝없이 할당된다면 해당 작업과 파일을 격리하세요. 소스 유형, 경로, 관련 해시, 버전, 클라이언트 백업 상태 및 재현에 필요한 가장 작은 테스트 그룹을 포함해 문제를 제보하세요.