어떤 Immich 데이터를 영구 보존해야 하며, 스토리지 역할이 중요한 이유는 무엇인가요?

Immich의 안정성은 신뢰할 수 있는 원본과 애플리케이션 상태를 영구적으로 보존하는 동시에, 다시 생성할 수 있는 파생 데이터와 임시 작업을 서로 다른 스토리지 역할로 취급하는 데 달려 있습니다.

모든 디렉터리를 하나의 볼륨에 배치해도 작동할 수 있지만, 그러면 어떤 데이터가 재구축 후에도 남아 있어야 하는지, 어떤 데이터가 다시 생성될 수 있는지, 어떤 데이터가 백업으로 독립적으로 유지되어야 하는지가 가려집니다. 이러한 구분은 디렉터리 이름 자체보다 복구 시간, 스토리지 배치, 정리 작업의 안전성을 더 크게 좌우합니다.

원본 미디어는 대체할 수 없는 콘텐츠 역할입니다

업로드된 사진과 동영상은 이 애플리케이션이 보존하기 위해 존재하는 가족의 추억입니다. 배포 방식과 스토리지 템플릿 선택에 따라 저장 경로는 달라질 수 있지만, 그 역할은 변하지 않습니다. 원본 미디어는 캐시가 아니라 원본 자산이며, 원본을 잃으면 썸네일이나 검색 인덱스를 다시 생성해도 복구할 수 없습니다.

미디어와 데이터베이스 배치를 구분하는 최신 셀프 호스팅 개요는 스토리지를 단순한 용량 수치가 아니라 안정성 설계로 바라보게 한다는 점에서 유용합니다. 하드웨어 제안은 예시로 참고하되, 대용량 원본과 활성 애플리케이션 상태를 구분하는 보다 일반적인 원칙은 유지하세요.

컨테이너를 쉽게 다시 만들 수 있다는 이유만으로 디렉터리를 분류하지 마세요. 컨테이너와 애플리케이션 이미지는 교체할 수 있지만, 컨테이너가 참조하는 마운트된 미디어는 그렇지 않을 수 있습니다. 정리나 마이그레이션을 시작하기 전에 정식 원본 위치를 확인하고 독립적인 사본이 존재하는지 검증하세요.

PostgreSQL은 권위 있는 관계 데이터 역할을 합니다

데이터베이스는 사용자, 자산, 경로, 앨범, 공유, 메타데이터, 설정, 검색 관련 상태에 대한 애플리케이션의 이해를 보존합니다. 따라서 사진으로 가득 찬 폴더만으로는 복원된 Immich 인스턴스와 같지 않습니다. 파일 시스템과 데이터베이스는 동일한 라이브러리의 서로 다른 부분을 설명하기 때문입니다.

서비스 아키텍처는 PostgreSQL을 미디어 스토리지 및 백그라운드 처리와 분리해 이러한 의존성을 명확하게 보여줍니다. 이 분리는 데이터베이스 지연 시간이 상호작용에 영향을 줄 수 있는 이유와 미디어만 백업해서는 모든 애플리케이션 관계를 보존할 수 없는 이유를 설명합니다.

장애 범위는 중요합니다. 데이터베이스 덤프만으로도 사진 백업이 되지 않습니다. 데이터베이스 덤프는 해당 미디어 파일이 예상되는 논리적 상태로 존재할 때에만 메타데이터와 관계를 복원할 수 있습니다. 양쪽 모두를 보호하고 함께 테스트하세요.

생성된 미디어는 저장 공간과 빠른 사용성을 맞바꿉니다

썸네일, 미리보기, 호환 가능한 동영상 인코딩은 전체 원본을 반복해서 처리하지 않고도 탐색과 재생을 실용적으로 만들기 위해 존재합니다. 상당한 공간을 차지할 수 있지만, 원본과 필요한 애플리케이션 상태가 유지된다면 많은 항목을 다시 생성할 수 있으므로 복구 가치는 다릅니다.

스토리지 역할을 분리한 사례는 운영자가 활성 데이터베이스 작업과 대용량 사진 저장소를 서로 다르게 배치하는 이유를 보여줍니다. 핵심은 모든 가정에 동일한 디스크가 필요하다는 것이 아니라, 생성되는 고변동 데이터가 원본과 다른 성능 및 백업 정책을 가질 수 있다는 점입니다.

다시 생성할 수 있다고 해서 비용이 들지 않는 것은 아닙니다. 대규모 가족 라이브러리의 파생 데이터를 재구축하려면 CPU, 스토리지 I/O, 대기열 처리 시간에 수 시간 또는 수 일이 걸릴 수 있습니다. 이를 백업에서 제외하는 것은 복구 시간에 관한 결정이지, 운영상 가치가 없다는 뜻은 아닙니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

대기열과 캐시는 내구성 있는 진실의 원천이 아닙니다

대기열 상태와 캐시는 실행 중인 시스템이 작업을 조정하고 처리 속도를 높이는 데 도움을 주지만, 대체할 수 없는 사실이 존재하는 유일한 장소가 되어서는 안 됩니다. 재시작 후 일시적인 대기열이 사라지더라도, 영구적인 데이터베이스 및 파일 시스템 상태만으로 애플리케이션이 다음에 해야 할 일을 결정할 수 있어야 합니다.

Immich 데이터 경로에 관한 ZimaSpace 글은 영구 상태와 시스템 내에서 요청을 전달하는 서비스를 구분하는 데 유용합니다. 대기열은 진행 중인 작업을 설명하는 것이지, 가족 아카이브 자체로 간주해서는 안 됩니다.

사용자 지정 통합 기능이 고유한 상태를 임시 경로, 백업되지 않은 컨테이너 계층 또는 문서화되지 않은 사이드카 위치에만 저장한다면 이 모델은 더 이상 안전하지 않습니다. 기본 영구 저장 범주가 전체 배포를 포괄한다고 가정하기 전에 사용자 지정 마운트와 재정의를 확인하세요.

스토리지를 이동하기 전에 복구 매트릭스를 작성하세요

각 역할을 나열하세요. 원본, 프로필, 데이터베이스, 생성된 썸네일, 인코딩된 동영상, 모델 캐시, 백업, 구성, 외부 라이브러리 등이 여기에 포함됩니다. 각 항목에 대해 호스트 경로, 권위 있는 데이터인지 여부, 다시 생성할 수 있는지 여부, 허용 가능한 최대 손실, 예상 복원 시간을 기록하세요.

ZimaSpace의 가족 사진 백업 가이드는 올바른 운영 경계를 제시합니다. 사용 가능한 가족 서비스에는 보호된 미디어와 장애 후 해당 미디어를 일관된 상태로 유지하는 데 필요한 애플리케이션 상태가 모두 필요합니다.

새 호스트에서 대표적인 원본, 계정 및 관계를 복원한 뒤, 의도적으로 제외한 파생 데이터를 다시 생성할 수 있을 때에만 영구 저장 설계를 승인하세요. 문서화되지 않은 볼륨을 기억해 내거나 컨테이너의 쓰기 가능 계층을 복구해야 한다면, 스토리지 역할은 아직 안전하게 정의되지 않은 것입니다.