Immich 상태는 라이브러리의 의도된 동작을 재현하는 데 필요한 미디어, 데이터베이스, 사용자 ID, 구성 및 파생 데이터가 결합된 것입니다.
원본 파일은 필수적이지만 애플리케이션의 전부는 아닙니다. 앨범, 사용자, 소유권, 얼굴, 검색 표현, 경로 매핑 및 비밀 정보가 파일이 어떻게 표시되고 누가 사용할 수 있는지를 결정합니다. 이 중 일부는 권위 있는 원본 데이터이고, 다른 일부는 비용을 들여 다시 구축할 수 있습니다.
원본 미디어와 데이터베이스 관계가 핵심을 이룹니다
원본 사진과 동영상은 대체할 수 없는 콘텐츠를 보존합니다. 데이터베이스는 Immich가 해당 콘텐츠를 이해하는 방식을 보존합니다. 여기에는 사용자, 소유권, 앨범, 에셋 식별자, 메타데이터 및 처리 관계가 포함됩니다. 단순히 흩어진 파일을 복구하는 것이 아니라 동일한 가정용 서비스를 복원하려는 경우, 어느 한쪽만으로는 불완전합니다.
ZimaSpace의 Immich 백업 가이드에서는 포괄적인 보호에 업로드된 미디어와 데이터베이스가 모두 포함된다고 설명합니다. 이 구분은 유용한 상태 정의를 제공합니다. 미디어는 어떤 바이트가 존재하는지 알려 주고, 데이터베이스 레코드는 애플리케이션이 해당 바이트를 어떻게 연결하고 표시하며 제어하는지 알려 줍니다.
데이터베이스와 모든 원본 미디어 위치를 영구적인 호스트 또는 스토리지 시스템 경로에 매핑하세요. 외부 라이브러리가 자체 정책에 따라 보호되는지 확인하세요. 내부 컨테이너 경로만 보고 영속성을 추정하지 마세요. 컨테이너가 삭제되고 다시 생성되어도 유지되는 실제 볼륨 또는 바인드 마운트를 확인해야 합니다.
구성과 비밀 정보가 서비스 경계를 재현합니다
Compose 정의, 환경 설정, 스토리지 매핑, 프록시 규칙 및 ID 공급자 구성에 따라 서비스가 데이터와 서로를 찾는 방식이 결정됩니다. 비밀번호, 서명 자료 및 API 자격 증명도 안전하게 보존되어야 합니다. 이러한 설정 없이 파일만 복구하면 잘못된 ID 또는 경로로 데이터베이스에 접근하게 될 수 있습니다.
Immich 스토리지 계획 분석에서는 데이터베이스와 썸네일 저장 위치를 대량의 원본 스토리지와 분리합니다. 여기서 얻을 수 있는 구조적 교훈은 하나의 논리적 서비스가 여러 물리적 위치에 걸쳐 있을 수 있다는 점입니다. 따라서 영속성 목록은 하나의 프로젝트 디렉터리가 아니라 모든 마운트와 종속성을 따라가야 합니다.
비밀 정보를 제거한 후 배포 정의를 버전 관리 시스템에 저장하세요. 비밀 정보는 복호화된 백업 또는 복구 절차가 문서화된 비밀 관리자에 보관하세요. 바인드 마운트의 소유자와 권한을 기록하세요. 복구 훈련 중에는 원격 액세스를 노출하거나 새 업로드를 허용하기 전에 서비스에서 데이터베이스에 접근할 수 있는지와 미디어를 읽을 수 있는지 확인하세요.
파생 데이터는 다시 만들 수 있지만 운영상 중요합니다
버전과 보존된 레코드에 따라 썸네일, 인코딩된 동영상 및 일부 머신러닝 출력은 신뢰할 수 있는 원본 입력에서 다시 생성할 수 있습니다. 이를 백업에서 제외하면 백업 크기를 줄일 수 있습니다. 그 대가는 복원된 서버가 대규모 가족 라이브러리를 다시 구축하는 동안 소요되는 시간, 연산 자원, 발열 및 응답성 저하입니다.
독립 백업 가이드에서는 반드시 필요한 업로드, 라이브러리 및 프로필 데이터와 Immich가 다시 생성할 수 있는 썸네일 및 인코딩된 동영상을 구분합니다. 그렇다고 파생 데이터가 중요하지 않은 것은 아닙니다. 이는 백업 크기와 완전히 준비된 탐색 및 재생 환경을 다시 확보하는 데 필요한 시간 사이에서 운영자가 선택할 수 있게 해 줍니다.
파생 데이터를 제외하기 전에 대표적인 재구축 속도를 측정하세요. 영향을 받는 에셋 구성에 따라 신중하게 환산하고, 스토리지 쓰기와 포그라운드 작업과의 리소스 경쟁도 포함하세요. 그 결과로 예상되는 지연이 복구 목표를 위반한다면, 일부 파생 데이터 경로를 보호하거나 재구축 기간에 사용할 예비 연산 용량을 확보하세요.
컨테이너 삭제 훈련으로 영속성을 입증하세요
운영 환경이 아닌 배포 환경의 폐기 가능한 복제본을 사용하세요. 샘플 원본, 테스트 앨범, 서로 다른 접근 권한을 가진 두 계정 및 알려진 검색 결과 하나의 체크섬을 기록하세요. 선언된 영구 스토리지는 유지한 채 복제본의 컨테이너만 삭제한 다음, 저장된 구성과 비밀 정보로 스택을 다시 생성하세요.
커뮤니티 영속성 보고서에서는 의도한 호스트 데이터베이스 디렉터리가 비어 있었기 때문에 재시작 후 Immich가 온보딩 화면으로 돌아간 사례를 설명합니다. 이는 설정된 경로가 실제 쓰기 작업이 해당 경로에 도달한다는 증거가 아니라는 점을 보여 주는 경고 사례입니다. 주장하는 실제 수명 주기 작업을 거친 후에도 관찰 가능한 상태가 유지되어야 합니다.
두 계정이 모두 복원되고, 앨범 멤버십이 일치하며, 원본 체크섬이 동일하고, 알려진 검색이 예상대로 작동하거나 문서화된 재구축 상태로 전환될 때만 훈련을 통과한 것으로 간주하세요. 설명할 수 없는 초기화가 발생하면 누락된 영속성이 있다는 뜻입니다. 동일한 가정을 바탕으로 구축된 백업 자동화에 의존하기 전에 상태 지도를 업데이트하세요.
기술 및 AI 허브
더 읽어보기

Immich는 로컬 및 원격 세션에서 인증을 어떻게 처리하나요?
Immich는 클라이언트 세션과 함께 서버 측 ID를 사용하므로, 프록시 헤더, 오리진, OIDC 리디렉션에 따라 로컬 환경과 원격 환경의 동작이 달라질 수 있습니다.

데이터가 늘어날수록 Immich 검색 또는 쿼리 결과가 느려지는 원인은 무엇인가요?
Immich의 성장은 인덱스를 키우고, 자주 사용되는 페이지를 내보내며, 필터를 복잡하게 만들고, 미디어 전달을 지연시킬 수 있으므로 튜닝하기 전에 이러한 단계를 분리하세요.

컨테이너를 다시 시작한 후 Immich가 다르게 작동하는 이유는 무엇인가요?
Immich를 다시 시작한 후 일시적인 캐시 손실은 예상되는 현상입니다. 지속적인 로그인, 데이터베이스 또는 미디어 변경이 발생한다면 종속성 또는 영속성 문제일 수 있습니다.

