원본, 카탈로그 데이터베이스, 경로 정의 구성을 하나의 복구 단위로 복원하세요.
Immich, Lightroom, PhotoPrism 또는 유사한 홈 NAS 라이브러리의 경우 이미지 파일만 복원하면 열 수는 있지만 사람, 앨범, 평가, 편집, 위치 및 검색 결과가 손실될 수 있습니다. 검색 가능한 복구는 미디어 파일을 이를 설명하는 데이터베이스 또는 카탈로그, 경로를 매핑하는 구성, 그리고 해당 상태를 읽는 데 필요한 비밀 정보나 애플리케이션 버전과 일치시켜야 합니다.
검색 가능성을 단순히 원본 파일 열기 이상의 개념으로 정의하기
사진 라이브러리는 애플리케이션이 각 원본을 데이터베이스 기록, 메타데이터, 앨범 소속, 사람 할당 및 경로와 연결할 수 있을 때 검색 가능합니다. JPEG 파일을 열 수 있다는 것은 파일 복구가 되었음을 의미할 뿐, 라이브러리 복구가 되었다는 뜻은 아닙니다.
Immich 복구 논의에서는 데이터베이스가 파일 위치와 라이브러리 메타데이터를 포함하는 반면 실제 사진은 업로드 폴더에 남아 있음을 보여줍니다. 한쪽만 복원하면 원본이 없는 썸네일이나 기록이 생성될 수 있습니다.
복원 전에 필요한 결과를 명확히 작성하세요: 원본이 열리고, 타임라인 날짜가 정확하며, 앨범이 나타나고, 사람 검색이 작동하며, 편집이나 평가가 복원되고, 사용자가 접근 권한을 유지하는 것. 이 결과가 복구 단위에 포함될 구성 요소를 정의합니다.
원본과 카탈로그를 동일한 시점 경계에서 복원하기
미디어 트리와 카탈로그는 동일한 복구 시점을 나타내야 합니다. 최신 데이터베이스는 오래된 미디어 복사본에 없는 파일을 참조할 수 있고, 오래된 카탈로그는 디스크에 존재하는 사진을 무시할 수 있습니다.
Lightroom 복구 사례에서는 두 단계 복원이 필요했습니다: 먼저 사진 폴더를 복원하고, 그 다음 사건 이전의 일치하는 카탈로그 백업을 복원하는 방식입니다. 편집, 평가, 사람, 앨범을 원본 외부에 저장하는 자체 호스팅 라이브러리에도 동일한 의존성이 적용됩니다.
미디어 백업, 데이터베이스 덤프, 구성 복사본 간 가장 가까운 공통 타임스탬프를 선택하세요. 공통 시점이 없으면 격리된 인스턴스에 복원한 후 격차를 조정하고 라이브러리를 사용자에게 공개하세요.
조각을 연결하는 경로, 식별자 및 구성 보존하기
복원된 경로, 마운트 이름, 볼륨 식별자 또는 라이브러리 루트가 저장된 참조와 다르면 카탈로그가 정상이어도 자산이 누락된 것으로 나타날 수 있습니다. 따라서 경로 일관성은 복구의 일부이며 복원 후 미용 작업이 아닙니다.
Lightroom 사용자는 복원된 파일이 동일한 이름과 폴더 구조를 유지해야 한다고 보고합니다. 컨테이너 앱의 경우 이에 상응하는 것은 바인드 마운트 경로, 환경 변수, 데이터베이스 URL 또는 저장소 루트일 수 있습니다.
데이터베이스 옆에 Compose 파일 또는 앱 구성, 환경 변수, 비밀 정보, 사용자 ID, 마운트 정의를 복원하세요. 애플리케이션이 기대하는 식별자를 확인하기 전까지는 대량 재연결이나 재스캔을 하지 마세요.
필수 상태와 재생성 가능한 검색 자산 분리하기
원본, 데이터베이스 기록, 사용자 데이터, 앨범 관계, 편집 및 구성은 일반적으로 필수입니다. 썸네일, 캐시된 모델, 일부 머신러닝 임베딩은 재생성 가능하지만, 이 작업이 완료될 때까지 라이브러리가 느리거나 부분적으로 검색 불가능할 수 있습니다.
최신 Immich 배포 가이드는 서버, 머신러닝, 백그라운드 작업 큐를 위한 별도 서비스를 설명하며, 내장된 데이터베이스 백업 스케줄링을 언급합니다. 이 구성 요소들은 검색과 사람 인식이 단순히 보이는 미디어 디렉터리 이상에 의존할 수 있음을 설명합니다.
재생성 가능한 자산과 재생성 소요 시간을 문서화하세요. 재생성에 수일의 CPU 시간이 필요하거나 원본 모델 상태를 재현할 수 없다면, 애플리케이션이 기술적으로 재생성할 수 있더라도 실용적인 복구 단위의 일부로 해당 자산을 보호하세요.
복원된 상태를 호환 가능한 애플리케이션 버전과 일치시키기
카탈로그나 데이터베이스는 이를 생성하거나 마이그레이션한 애플리케이션 버전을 필요로 할 수 있습니다. 오래된 서비스가 최신 상태를 처리하거나 그 반대의 경우 미디어 평가 전에 실패할 수 있습니다.
사진 라이브러리 사용자는 애플리케이션과 카탈로그 버전 불일치로 인한 복구 문제를 경험했습니다. 배포된 이미지 태그, 마이그레이션 노트, 데이터베이스 버전을 보존하여 테스트 환경에서 예상 업그레이드 경로를 재현할 수 있도록 하세요.
복원된 라이브러리를 오프라인 또는 임시 이름으로 시작하세요. 모바일 클라이언트나 백그라운드 작업이 복원된 상태를 변경하기 전에 데이터베이스 마이그레이션, 사용자 로그인, 경로 해석을 확인하세요.
전환 전에 검색, 앨범, 사람 기능 검증하기
대표적인 오래된 사진과 새 사진, 편집된 항목, 다중 사용자, 공유 앨범, 위치 메타데이터, 알려진 사람을 포함하는 격리된 복원 테스트를 사용하세요. 예상 결과가 이미 문서화된 기록을 검색하세요.
기존 ZimaSpace의 Immich 가족 사진 백업 계획은 인접한 계획 맥락을 제공하며, 이 복원 테스트는 이제 해당 구성 요소들이 함께 복원됨을 증명해야 합니다.
원본이 열리고, 개수가 일치하며, 앨범과 권한이 복원되고, 검색 결과가 타당하며, 새 업로드가 올바르게 인덱싱될 때만 전환하세요. 테스트 라이브러리가 재시작과 새 백업을 견딜 때까지 이전 인스턴스와 복구 파일은 변경하지 마세요.
지원 및 팁
더 읽어보기

Docker 볼륨을 복원하면 파일 내용은 복원되지만 확장 속성은 사라지는 이유는 무엇인가요?
xattr 인벤토리, tar 및 Rsync 옵션, 네임스페이스, 대상 지원, 권한, 레이블, 앱 메타데이터와 테스트를 다루는 볼륨 복원 진단.

Compose 파일을 변경한 후에도 실행 중인 컨테이너의 메모리 제한이 기존 값으로 유지되는 이유는 무엇인가?
실행 중인 cgroup, 재시작과 재생성, Compose 필드, 하드 및 소프트 제한, 상위 범위, 스왑, 런타임 힙을 다루는 메모리 제한 진단입니다.

리버스 프록시를 재시작하면 셀프 호스팅 앱 하나의 모든 세션이 무효화되는 이유는 무엇인가요?
재시작 범위, 쿠키 소유권, 비밀 키 순환, 캐시 기반 세션, 스티키 라우팅, 인증 게이트웨이 및 복구를 다루는 세션 손실 진단.

