스택을 다시 생성한 후 Immich가 영구 데이터에 액세스하지 못하는 이유는 무엇인가요?

스택을 다시 만든 후 Immich가 비어 있거나 라이브러리를 읽지 못한다면, 기존 영구 데이터가 삭제되었다고 단정하기 전에 연결이 끊겼거나 읽을 수 없는 상태라고 가정하세요.

컨테이너를 다시 만들면 Compose 프로젝트 식별자, 바인드 마운트 소스, 이름 있는 볼륨 연결, 네트워크 공유 연결 시점 또는 데이터를 읽는 UID/GID가 변경될 수 있습니다. 새로 생성된 것처럼 보이는 인스턴스가 새 상태를 많이 기록하기 전에 중지하고, 호스트에서 기존 데이터베이스와 미디어 경로를 찾은 다음, 다시 만든 스택을 마지막으로 정상 작동한 매핑과 비교하세요. 목표는 먼저 기존 상태를 다시 연결하는 것입니다. 해당 상태가 실제로 누락되거나 손상되었다는 사실을 확인한 후에만 백업에서 복원하세요.

새 인스턴스를 중지하고 기존 데이터가 여전히 존재하는지 확인하세요

다시 만든 직후 설정 마법사가 표시되거나 타임라인이 비어 있거나 외부 라이브러리가 사라졌다면 영구성에 문제가 있다는 신호입니다. 새 파일을 업로드하거나 비어 있는 새 구성을 승인하기 전에 Immich를 중지하고 호스트 측 데이터베이스 및 미디어 위치를 확인하세요. 새로 기록된 데이터가 생기면 이후 경로 비교가 더 어려워질 수 있습니다.

기존 디렉터리에서 예상 파일 수, 수정 날짜, 데이터베이스 파일 또는 덤프, 원본 이미지 샘플을 확인하세요. 호스트에 데이터가 있다면 문제는 데이터 소실이 아니라 접근 또는 매핑 문제입니다. 소유권을 변경하거나 디렉터리를 이동하기 전에 해당 상태의 읽기 전용 스냅샷 또는 백업을 만드세요.

예상 경로에서 기존 데이터를 찾을 수 없다면 무엇이든 삭제하기 전에 스토리지 풀과 Docker 볼륨 목록을 검색하세요. 판단 기준은 두 가지 중 하나입니다. 기존 상태를 찾아 보호했거나, 기존 상태를 실제로 사용할 수 없어 복구 경로를 마운트 수정이 아닌 정상 백업으로 전환해야 합니다.

다시 만든 스택의 마운트를 이전 스택과 비교하세요

기억나는 Compose 텍스트만 확인하지 말고, 다시 만든 Immich 서버 및 데이터베이스 컨테이너에 실제로 적용된 마운트를 확인하세요. 상대 바인드 경로는 다른 프로젝트 디렉터리에서 해석될 수 있으며, Compose 프로젝트 이름이 변경되면 기존 이름 있는 볼륨은 그대로 남아 사용되지 않은 채 새 볼륨이 연결될 수 있습니다.

마운트가 실패했거나 변경되었거나 누락되면 호스트의 다른 위치에 예상 데이터가 여전히 존재하더라도 컨테이너 내부에서는 빈 디렉터리로 보일 수 있습니다. 모든 영구 Immich 경로에 대해 Docker 볼륨 마운트 확인을 사용하여 Source, Destination, 마운트 유형 및 이름 있는 볼륨 식별자를 비교하세요. 여기서 불일치가 발견되면 새로 생성된 것처럼 보이는 인스턴스가 직접 설명됩니다.

잘못된 마운트 매핑만 수정한 다음 볼륨을 삭제하지 않고 컨테이너를 생성하거나 시작하세요. 변경 후 예상 파일이 동일한 컨테이너 경로에 나타난다면 데이터를 그대로 두세요. 마운트 목록이 올바른데도 접근이 실패한다면 매핑을 유지하고 다른 볼륨을 만들기보다 호스트 스토리지의 사용 가능 여부와 권한을 확인하세요.

Immich가 시작되기 전에 외부 스토리지가 마운트되었는지 확인하세요

Immich 데이터가 HDD 풀, NAS 공유, 병합 계층 또는 기타 외부 마운트에 있다면 Docker가 스택을 시작하기 전에 해당 스토리지가 실제로 호스트에 마운트되어 있는지 확인하세요. /mnt/photos 같은 경로는 실제 장치가 없어도 일반 로컬 디렉터리로 계속 존재할 수 있습니다.

영구 Docker 데이터는 의도한 볼륨 또는 바인드 마운트가 올바르게 다시 연결된 경우에만 컨테이너 교체 후에도 유지됩니다. 기본 Docker 볼륨 영구성 모델만으로는 호스트 디스크나 네트워크 공유가 없어도 자동으로 나타나게 만들 수 없으므로, Immich 내부에서 같은 경로를 테스트하기 전에 호스트에서 스토리지 장치와 알려진 파일을 확인하세요.

실제 스토리지가 없는 동안 빈 마운트 지점에 대체 파일이 기록된 것을 발견했다면, 해당 장치를 그 위에 마운트하기 전에 Immich를 중지하세요. 그 파일들을 별도로 정리하고, 스토리지 마운트에 대한 시작 종속성 또는 상태 확인을 추가한 다음에만 스택을 다시 시작하세요. 호스트 스토리지가 안정적이고 컨테이너 경로를 여전히 읽을 수 없다면 권한 확인 단계로 진행하세요.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

전체를 다시 작성하지 않고 UID, GID 및 디렉터리 권한을 확인하세요

스택을 다시 만들면 이전과 다른 숫자 식별자, 사용자 네임스페이스 또는 보안 컨텍스트로 서비스가 실행될 수 있습니다. 이 경우 마운트 누락과는 다른 양상이 나타납니다. 경로가 존재하고 호스트에서 파일도 보이지만 Immich 로그에 권한 오류가 표시되거나 예상 파일을 생성하지 못합니다.

영향을 받은 호스트 디렉터리의 숫자 소유권과 권한 비트를 다시 만든 컨테이너 내부의 사용자 ID와 비교하세요. 먼저 무해한 읽기를 테스트한 다음, 동일한 마운트 아래 일회용 위치에서 되돌릴 수 있는 쓰기 작업을 테스트하세요. 어떤 서비스에 쓰기 권한이 필요한지, 기존 파일 중 어떤 파일을 변경하지 않고 유지해야 하는지 알기 전에는 전체 사진 보관소에 재귀적으로 소유권을 변경하지 마세요.

실패를 설명하는 가장 작은 디렉터리 또는 ID 불일치만 수정하고 한 번 재시작한 다음 로그를 다시 확인하세요. 마운트와 권한이 일치하는데도 접근이 실패한다면 파일 시스템 변경을 중단하고, 재생성 과정에서 변경된 데이터베이스 연결, 환경 변수 치환 또는 보안 계층을 확인하세요.

기존 상태를 다시 연결하고 재생성을 한 번 더 검증하세요

기존 데이터베이스와 미디어 경로를 연결하여 읽을 수 있게 했다면 Immich를 시작하고 기존 사용자, 앨범, 사람 및 대표 자산이 나타나는지 확인하세요. 홈페이지가 로드된다는 이유만으로 복구가 완료되었다고 판단하지 마세요. 애플리케이션이 새로 초기화된 데이터베이스를 옆에 만든 것이 아니라 기존 상태를 읽고 있는지 확인해야 합니다.

중요한 기준은 컨테이너는 언제든 폐기할 수 있지만 애플리케이션 상태는 컨테이너 수명 주기 외부의 안정적인 스토리지에 남아 있어야 한다는 점입니다. 수정된 마운트 이름과 호스트 경로를 문서화하고, 영구 파일 서버 스토리지 역할을 사용하여 다음 스택 재생성에서도 동일한 데이터에 연결되도록 하세요.

마지막으로 통제된 조건에서 스택을 한 번 더 다시 만들고 처음 수행했던 점검을 반복하세요. 재생성 후와 호스트 재부팅 후에도 동일한 데이터베이스와 미디어가 다시 나타날 때만 수정이 입증됩니다. 기존 상태가 다시 사라지거나 데이터베이스가 접근 오류가 아닌 손상을 보고한다면 보호된 복사본으로 되돌리고, 마운트 실험을 계속하는 대신 데이터베이스/백업 복구로 전환하세요.