Immich는 마운트, 권한, 지연 시간, 장애 발생 시 동작을 적절히 설계하고 테스트하면 미디어 저장소나 외부 라이브러리에 네트워크 공유를 안정적으로 사용할 수 있습니다. 하지만 PostgreSQL 데이터 디렉터리는 일반적인 SMB 또는 NFS 공유가 아니라 지원되는 저지연 스토리지에 유지해야 합니다.
데이터라는 단어에는 서로 다른 워크로드가 포함됩니다. 원본은 크기가 큰 영구 파일이고, 썸네일은 더 많은 소규모 작업을 생성하며, 외부 라이브러리는 읽기 전용일 수 있고, PostgreSQL에는 데이터베이스 파일 시스템 의미 체계가 필요합니다. 경로별로 저장 위치를 결정하고, 컨테이너가 시작되기 전에 공유를 마운트하며, 비어 있는 로컬 디렉터리가 NAS를 대신하는 상황을 방지하고, 호스트 재시작과 통제된 공유 중단을 모두 통해 동작을 검증해야 합니다.
이동하기 전에 Immich의 각 경로를 분류하세요
업로드 라이브러리, 썸네일 또는 인코딩된 미디어, 외부 라이브러리, 데이터베이스 디렉터리, 모델 캐시, 백업을 각각 별도로 나열하세요. 각 경로에 누가 쓰기 작업을 수행하는지와 손실 시 영향을 표시하세요. 미디어 공유는 적합할 수 있지만, 모든 볼륨을 서로 바꿔 사용할 수 있다고 취급하면 설계 검증을 통과할 수 없습니다.
실용적인 NFS 안내에서는 공유 스토리지에서 Immich 외부 라이브러리를 매핑하는 방법을 보여 줍니다. 해당 외부 라이브러리 마운트 방식은 경로와 권한을 계획하는 데 유용하지만, 데이터베이스에 NFS를 사용해야 한다는 근거는 아닙니다.
PostgreSQL은 데이터베이스에 권장되는 스토리지에 유지하고, 기본 덤프와 백업으로 보호하세요. 로컬 활성 스토리지가 제한적이라면 용량을 많이 사용하는 미디어 경로만 측정 후 이동하고, 애플리케이션 상태 전체를 이전하는 대신 그 경계를 문서화하세요.
원격 마운트 순서를 결정적으로 만드세요
명시적인 자격 증명 또는 내보내기 규칙, 안정적인 주소, 의도한 읽기-쓰기 모드를 사용해 호스트에서 공유를 마운트하세요. Immich를 시작하기 전에 예상되는 파일 시스템 식별 정보와 알려진 마커 파일을 확인하세요. 이미 마운트된 호스트 경로를 컨테이너에 바인드하세요.
서비스 관리자를 구성해 Immich가 원격 마운트를 기다리도록 하고, 비어 있는 대체 디렉터리에서 시작하지 않게 하세요. 마커가 컨테이너 내부에 표시되고 테스트 파일에 예상한 소유자가 설정된 경우에만 부팅 테스트를 통과한 것으로 봅니다. 비어 있는 디렉터리나 root 소유 파일이 보이면 즉시 중단해야 합니다.
공유를 사용할 수 있을 때 한 번, 유지 관리 시간에 의도적으로 사용할 수 없게 한 상태에서 한 번 재부팅하세요. 첫 번째 테스트는 Immich가 시작되기 전에 마커가 표시될 때만 통과합니다. 두 번째 테스트는 Immich가 중지되거나 눈에 띄게 실패하고, 아무 내용도 없는 로컬 마운트 지점에 쓰지 않을 때만 통과합니다.
컨테이너 식별 정보와 공유 권한을 검증하세요
서버, 클라이언트, 컨테이너에서 숫자로 된 사용자 및 그룹 식별 정보를 일치시킨 다음, 삭제해도 되는 전용 폴더에서 생성, 이름 변경, 읽기, 삭제를 테스트하세요. 가족 라이브러리가 노출되는 전역 쓰기 권한으로 불일치를 해결하지 마세요.
호스트에서만 수행하지 말고 Immich 서버 컨테이너 내부에서도 삭제 가능한 파일 테스트를 반복하세요. NAS에서 의도한 숫자 소유자를 확인하고, 컨테이너를 다시 생성한 후에도 Immich가 파일을 다시 열 수 있는지 확인하세요. 호스트에서만 통과했다고 컨테이너 경로가 검증된 것은 아닙니다.
식별 정보 또는 생성 및 이름 변경 동작이 다르면 중지하고 범위를 좁힌 내보내기, 마운트 또는 컨테이너 매핑을 수정하세요. 실제 라이브러리를 스캔하기 전에 다시 테스트하세요. 광범위한 권한 변경은 불일치를 숨기는 동시에 모든 가족 사진을 관련 없는 서비스에 노출할 수 있습니다.
지연 시간을 측정하고 공유 중단을 테스트하세요
대표적인 업로드, 썸네일 생성, 타임라인 탐색, 원본 다운로드, 외부 라이브러리 스캔을 실행하면서 서버 지연 시간과 작업 진행 상황을 측정하세요. 상호 작용이 허용 가능한 수준이고 대기열이 지속적으로 증가하지 않아야 통과입니다. 원시 링크 속도만으로는 메타데이터 성능을 입증할 수 없습니다.
한 배포 환경에서 불안정한 NFS로 인해 데이터베이스와 파일이 일치하지 않는 문제가 보고된 Immich 이슈가 있습니다. 이 제한적인 NFS 장애 사례는 연결이 끊긴 상태에서 쓰기 작업을 수행하는 것을 복구 위험으로 취급해야 한다는 점을 보여 주지만, NFS가 항상 Immich를 손상시킨다고 가정해야 한다는 뜻은 아닙니다.
백업이 완료된 유지 관리 시간에 중요하지 않은 테스트를 실행하면서 미디어 공유를 중단하세요. Immich는 눈에 띄게 실패해야 하며, 아무 내용도 없는 로컬 마운트 지점에 쓰면 안 됩니다. 공유를 복구한 뒤 테스트 자산과 데이터베이스 레코드가 재시작 루프 없이 일치하는지 확인하세요.
재시작 테스트 후 진행 여부를 결정하세요
컨테이너와 호스트를 각각 재시작하세요. 올바른 공유가 먼저 마운트되는지, 기존 및 새 원본이 열리는지, 외부 스캔으로 자산이 중복되지 않는지, 새 업로드 하나가 또 한 번의 재시작 후에도 유지되는지 확인하세요. ZimaSpace의 DAS와 NAS 비교는 지연 시간과 장애 도메인 간의 절충점을 설명합니다.
이 테스트를 통과하고 부재, 지연 시간, 공간, inode 압박을 모니터링해 알림을 보낼 수 있다면 공유를 사용하세요. 네트워크 또는 NAS가 필요한 가용성을 충족하지 못하거나 장애 시 마운트가 열린 상태로 동작하는 것을 방지할 수 없다면 로컬 또는 직접 연결 스토리지를 선택하세요.
Immich가 빈 상태로 시작하거나, root 소유 파일을 생성하거나, 중단 후 파일 없음 오류를 발생시키면 이전 로컬 경로로 되돌리세요. 프로토콜, 마운트 옵션, 식별 정보, 경로 매핑, 지연 시간, 부팅 순서를 포함해 문제를 에스컬레이션하세요. 원본과 데이터베이스 상태가 어느 쪽을 기준으로 삼아야 하는지 확인하기 전에는 파괴적인 재스캔을 수행하지 마세요.
지원 및 팁
더 읽어보기

여러 컨테이너에서 동시 실행할 때 Immich 데이터베이스 연결을 최적화하는 방법
먼저 max_connections를 늘리지 마세요. Immich 세션을 측정하고, 모든 컨테이너의 요구량을 합산하며, 관리용 여유 공간을 확보한 뒤, 실제로 확인된 병목만 조정하세요.

Immich에서 중복 작업 또는 가져오기를 방지하는 방법
반복 작업과 중복 자산을 분리하세요. 하나의 표준 수집 경로를 사용하고, 재시도와 경로 변경을 제어한 다음, 소규모 코호트에서 재진입을 테스트하세요.

데이터베이스 볼륨이 가득 찬 후 Immich를 복구하는 방법
공간을 확보하기 위해 PostgreSQL WAL을 절대 삭제하지 마세요. Immich 쓰기를 중지하고, 데이터베이스 상태를 보존한 뒤, 안전하게 용량을 추가하고 PostgreSQL을 복구한 다음 재발을 방지하세요.

