소스 데이터가 명백히 손실된 것은 아니었습니다. ZimaOS를 초기화한 후에도 RAID6는 그대로 존재했고 다음과 같은 디렉터리도 남아 있었습니다. upload, pgdata, thumbs, profile그리고 encoded-video 여전히 존재했습니다. 문제는 재설치된 Immich 스택이 이전 사진 카탈로그를 복원할 수 있는 방식으로 기존 데이터베이스/라이브러리 상태에 연결되지 않았다는 것입니다.
가장 안전한 소스의 조언은 다음과 같습니다. 기존 upload 및 pgdata 폴더를 아직 삭제하거나 이동하지 마세요. Immich는 디스크에 있는 이미지 파일을 확인하는 것만으로 전체 카탈로그를 다시 구축하지 않습니다. 데이터베이스에는 파일 경로, 사용자, 앨범, 메타데이터 및 애플리케이션 상태가 들어 있습니다. 현재 Immich v3 문서에서도 이러한 관계를 명확히 설명하며 자산 파일과 데이터베이스를 모두 백업할 것을 권장합니다.
먼저 실제 RAID 마운트 경로 확인
소스에서는 다음 명령을 사용했습니다.
ls -la /media
find /media -maxdepth 4 -type d \( -iname "immich" -o -iname "pgdata" -o -iname "upload" \)그리고 다음을 확인했습니다.
/media/photos/immich
/media/photos/immich/pgdata
/media/photos/immich/upload이를 통해 기존 Immich 폴더가 RAID에 여전히 존재한다는 사실이 확인되었습니다.
/media/ZimaOS-HD → /DATA는 Immich가 OS 드라이브를 사용하고 있다는 증거가 아니었습니다
사용자는 다음 때문에 불안해했습니다.
/media/ZimaOS-HD -> /DATA하지만 커뮤니티에서는 이것이 ZimaOS의 마운트/심볼릭 링크 관계라고 정확히 설명했습니다. 이것이 존재한다는 사실만으로는 Immich 컨테이너가 실제로 어떤 호스트 경로를 사용하는지 알 수 없습니다.
Docker의 실제 마운트 확인
스레드에서는 다음을 확인할 것을 권장했습니다.
docker inspect immich-server --format '{{json .Mounts}}'
docker inspect immich-postgres --format '{{json .Mounts}}'이는 스크린샷이나 오래된 기억이 현재 실행 중인 컨테이너 설정을 반영한다고 가정하는 것보다 더 신뢰할 수 있습니다.
기존 pgdata는 기존 사진 파일만큼 중요합니다
재설치 과정에서 기존 데이터베이스가 아닌 새 데이터베이스가 초기화되었다면, 파일은 여전히 존재하지만 Immich에는 비어 있는 것처럼 보일 수 있습니다.
현재 Immich는 UPLOAD_LOCATION 및 DB_DATA_LOCATION을 사용합니다
현재 Immich v3 Compose는 호스트 자산 위치와 Postgres 위치를 다음을 사용해 분리합니다 UPLOAD_LOCATION 그리고 DB_DATA_LOCATION. 업스트림에서는 데이터베이스 경로에 네트워크 공유를 지원하지 않는다고 명시합니다.
기존 데이터를 복원하기 전에 현재 Immich 스토리지 모델을 사용하세요.
버전이 다른 환경에서 실행 중인 기존 pgdata 디렉터리를 다시 연결하는 것보다 데이터베이스 백업이 안전합니다
소스 환경은 Immich v2.7.2였습니다. 현재 Immich는 v3입니다. 버전 간에 복구할 때는 기존 Postgres 데이터 디렉터리를 최신 데이터베이스 이미지에 단순히 연결할 수 있다고 가정하기보다, 업스트림의 데이터베이스 백업 및 복원 절차를 사용하는 편이 안전합니다.
현재 Immich 백업 및 복원 절차를 참조하세요.
Immich의 내부 자산 폴더를 수동으로 재배치하지 마세요
현재 Immich 문서에서는 다음과 같은 폴더가 library, upload, thumbs, profile그리고 encoded-video 애플리케이션이 관리합니다. Immich의 파일을 직접 이동하거나 삭제하면 누락되거나 추적되지 않는 자산이 생길 수 있습니다.
소스 작성자는 복구 성공을 확인하지 않았습니다
커뮤니티 구성원들은 단일 상위 마운트를 포함한 여러 매핑 방식을 제안했지만, jerlo는 결국 해당 이슈를 보류하고 다른 시스템에서 처음부터 다시 시작했습니다. 따라서 포럼에서는 특정 경로 매핑 하나를 최종 해결책으로 확정하지 않습니다.
현재 Immich는 모든 하위 폴더를 수동으로 매핑하기보다 관리형 업로드 루트를 선호합니다
원본 스크린샷에서는 수동으로 매핑했습니다 upload, thumbs, profile, library, encoded-video및 백업을 하나씩 수동으로 매핑하는 방식입니다. 현재 업스트림 Compose는 대신 호스트 구성을 다음 항목을 중심으로 구성합니다. UPLOAD_LOCATION이 루트 아래의 내부 하위 디렉터리는 Immich가 관리하도록 하세요.
최신 Immich 릴리스에서 다시 구축할 때는 패키지에서 특별히 요구하지 않는 한 과거의 하위 매핑 구성을 재현하지 말고 현재의 Compose/스토리지 레이아웃을 사용하세요.
Postgres 데이터 경로는 지원되는 로컬 스토리지에 유지하세요
현재 Immich 문서에는 네트워크 공유가 지원되지 않는다고 명시되어 있습니다. DB_DATA_LOCATION. 로컬로 연결된 RAID/스토리지 파일 시스템은 적절할 수 있지만 SMB/NFS로 마운트된 데이터베이스 디렉터리는 지원되는 데이터베이스 경로가 아닙니다.
완전한 Immich 복구에는 자산과 데이터베이스가 모두 필요합니다
현재 Immich 백업 문서에 따르면 데이터베이스 백업에는 메타데이터와 사용자 정보가 포함되지만 사진/동영상 자산은 포함되지 않습니다. 자산 트리는 호환되는 데이터베이스 백업과 함께 별도로 백업하고 복원해야 합니다.
이는 “업로드 파일은 아직 남아 있다”는 사실이 원본 사례에서 안심할 만했지만 충분하지는 않았던 이유를 설명합니다.
이전 라이브 pgdata 디렉터리를 다른 Postgres/Image 버전에 함부로 연결하지 마세요
Postgres 원시 데이터 디렉터리는 버전에 따라 다릅니다. 이전 환경과 새 패키지에서 서로 다른 Postgres 또는 Immich 버전을 사용한다면, 지원되는 데이터베이스 덤프/복원 방식이나 문서화된 마이그레이션 경로를 우선 사용하세요. 이전 환경의 전체 백업을 바이트 단위로 생성하세요 pgdata 실험하기 전에.
Immich 복구 FAQ
ZimaOS 재설정으로 원본 RAID6 사진 폴더가 삭제되었나요?
아니요. 사용자는 RAID와 기존 디렉터리/파일이 그대로 유지되었다고 말했습니다.
기존 사진 파일만 매핑하면 Immich 라이브러리가 복원되나요?
반드시 그렇지는 않습니다. Immich에는 해당 데이터베이스/카탈로그 상태도 필요합니다.
실험하기 전에 무엇을 보호해야 하나요?
전체 자산 저장소와 데이터베이스 또는 검증된 데이터베이스 백업
