Immich 캐시 및 임시 저장소 구성 방법

먼저 영구적인 라이브러리 상태를 생성된 파생 데이터, 재사용 가능한 모델 캐시, 완전히 일회성인 컨테이너 임시 데이터와 분리하여 Immich 캐시와 임시 저장소를 구성하세요.

썸네일과 인코딩된 동영상은 Immich가 다시 생성할 수 있으므로 캐시처럼 보일 수 있지만, 크기가 커지고 다시 만드는 데 많은 비용이 들 수 있는 영구 작업 자산입니다. 모델 다운로드는 수명 주기가 다르며, 로그와 쓰기 가능한 레이어의 임시 데이터가 부팅 디스크를 조용히 잠식해서도 안 됩니다. 역할별로 저장소를 할당한 다음 정리 및 재시작 동작을 테스트하세요.

이동하기 전에 각 저장소 역할을 분류하세요

최소한 다음 네 가지 범주로 인벤토리를 만드세요. 원본 및 필수 애플리케이션 상태, 생성된 썸네일 및 미리보기, 생성된 인코딩 동영상, 모델·로그·임시 런타임 데이터입니다. 각 범주에 대해 현재 경로, 크기, 증가 속도, 백업 정책, 재생성 비용, 해당 데이터를 기록하는 서비스를 적으세요.

생성된 썸네일 및 동영상 증가에 관한 사용자 보고서는 썸네일과 인코딩된 동영상의 사용량을 별도로 측정해야 하는 이유를 보여 줍니다. 미디어 구성과 처리 설정에 따라 생성되는 양이 달라지므로 개별 비율은 보편적이지 않습니다.

디렉터리를 삭제하면 공간이 확보된다는 이유만으로 “캐시”라고 부르지 마세요. 삭제 후 며칠 동안 재생성이 필요하거나, 현재 재생이 중단되거나, 복구 계획에서 보존해야 하는 상태가 사라진다면 애플리케이션이 기술적으로 다시 만들 수 있더라도 명시적인 영구 역할을 부여해야 합니다.

지연 시간과 내구성에 맞는 위치에 변경이 잦은 생성 데이터를 배치하세요

썸네일과 미리보기는 대화형 탐색에 사용되며 작은 읽기 작업이 많은 경우가 많고, 인코딩된 동영상은 훨씬 더 큰 순차 저장 공간을 사용할 수 있습니다. 파생 데이터 중심 작업을 개선할 수 있다면 빠른 SSD가 도움이 되지만, 측정된 대기 시간을 줄이는 대신 예기치 않게 가득 차는 또 다른 작은 볼륨을 만들어서는 안 됩니다.

썸네일 저장소 증가에 관한 ZimaSpace의 설명은 다른 환경에도 적용할 수 있는 저장소 교훈을 제공합니다. 원본이 다른 곳에 있어도 활성 애플리케이션 저장소는 가득 찰 수 있습니다. Immich의 구체적인 경로는 다르지만 실제 쓰기 가능한 역할을 모니터링해야 한다는 점은 동일합니다.

대용량 미디어는 HDD나 NAS 저장소에 그대로 두고 파생 데이터를 SSD로 옮긴다면, 양쪽의 여유 공간 하한을 모니터링하고 재시작 후 모든 마운트를 확인하세요. 빠른 파생 데이터 계층은 정상적인 증가량을 감당할 만큼 충분히 크고, 장애가 발생해도 신뢰할 수 있는 원본의 손실로 오인되지 않을 때만 유용합니다.

모델 캐시는 의도적으로 유지하되 재생성 가능한 데이터로 취급하세요

머신러닝 모델은 반복적인 추론을 위해 다운로드되거나 준비되며 상당한 저장 공간을 사용할 수 있습니다. 모델 캐시를 유지하면 특히 연결 속도가 느릴 때 불필요한 다운로드와 시작 작업을 줄일 수 있지만, 복구 우선순위에서 데이터베이스나 가족 사진 원본과 같은 것으로 혼동해서는 안 됩니다.

Immich 저장소 아키텍처에 관한 커뮤니티 논의는 운영자가 빠른 캐시형 데이터와 대용량 사진 저장소를 분리하는 이유를 보여 줍니다. 이러한 구성을 예시로만 활용하고, 무엇이든 이동하기 전에 자체 Compose 정의에서 현재 경로와 마운트를 확인하세요.

모델 캐시를 잃었을 때 일반적으로 허용되는 복구 방법은 필요한 소스에 서비스가 접근할 수 있고 충분한 디스크 공간이 있다면 캐시를 다시 만들거나 다시 다운로드하는 것입니다. 백업 도구가 실수로 재생성 가능한 대용량 캐시를 제한된 오프사이트 용량으로 보호하지 않도록 이 동작을 문서화하세요.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

쓰기 가능한 레이어, 로그, 임시 공간의 사용량을 제한하세요

컨테이너의 쓰기 가능한 레이어가 영구 파생 데이터, 임시 트랜스코딩 파일, 대용량 로그를 위한 문서화되지 않은 저장소가 되어서는 안 됩니다. Docker 디스크 사용량과 컨테이너 마운트를 점검하여 증가하는 모든 대용량 경로가 의도적으로 유지되거나 명확히 일회성으로 처리되는지 확인하세요. 설명되지 않는 쓰기 가능한 레이어의 급증은 기본적으로 정리 대상이 아니라 구성 문제의 징후입니다.

안전한 Docker 디스크 정리를 위한 2026 Docker HQ 워크플로는 정리 작업 전에 감사하고 데이터베이스가 들어 있을 수 있는 볼륨을 보호하는 것을 강조합니다. 여기에도 같은 주의를 적용하세요. 각 볼륨과 레이어의 소유 관계를 파악하기 전에는 운영 중인 Immich 호스트에서 일괄 정리 명령을 실행하지 마세요.

로그 순환을 설정하고, 임시 파일 경로는 순간적인 증가를 감당할 수 있는 저장소에 두며, 작은 파일이 많이 생성될 때는 바이트 사용량뿐 아니라 inode 사용량도 모니터링하세요. 임시 경로가 가득 찼다면 애플리케이션이 우연히 시작될 때까지 낯선 디렉터리를 삭제할 것이 아니라 해당 역할의 용량을 제한하거나 위치를 옮겨야 합니다.

재시작, 재구축, 여유 공간 테스트로 저장소 변경을 검증하세요

경로를 변경한 후 오래된 자산과 최근 자산을 열고, 여러 앨범을 탐색하며, 동영상을 재생하고, 썸네일 또는 머신러닝 작업을 하나 실행한 다음, 새 파일을 통제된 방식으로 업로드하세요. 쓰기가 의도한 장치에 이루어지고 데이터베이스가 읽을 수 있는 미디어를 계속 참조하는지 확인하세요.

컨테이너를 재시작한 다음 호스트도 재시작하세요. 정상적인 구성이라면 모든 역할이 자동으로 다시 마운트되고, 예상한 파생 데이터와 모델 캐시가 유지되며, 임시 데이터는 일회성으로 남고, 각 활성 계층에 충분한 여유 공간이 있다고 보고해야 합니다. 정상적인 작업을 수행하는 동안 저장소를 관찰하여 증가분이 계획한 위치에 나타나는지 확인하세요.

Immich가 중복 디렉터리를 만들거나, 자산이 없다고 보고하거나, 마운트 실패로 인해 컨테이너 레이어에 조용히 쓰는 경우 경로 변경을 되돌리세요. 마운트 매핑, 경로별 크기, 소유권, 파일 시스템 여유 공간, 컨테이너 디스크 사용량, 잘못된 위치에 처음 기록된 정확한 작업을 함께 제공하여 문제를 에스컬레이션하세요.