ZimaOS Immich 사진 누락: 안전한 제거 가이드

이 출처가 입증하지 못하는 가장 중요한 사실은 ZimaOS가 독립적으로 NAS를 검사하여 일반 사진 라이브러리를 삭제했다는 것입니다. 사용자는 Immich 파일이 제거 및 재설치 작업 이후 사라졌다고 보고했으며 “구성 삭제” 옵션을 의심했지만, 정확한 삭제 사건은 IceWhale에 의해 재현되거나 진단되지 않았습니다.

이후 게시된 구성에서는 ZimaOS Store의 Immich 패키지가 아니라 사용자 지정 Docker Compose 배포를 사용한 것으로 확인되었습니다. 데이터베이스, 머신러닝 캐시, 라이브러리는 /mnt/bigdrive/data/immich/... 아래에 바인드 마운트되어 있었습니다. Zima-Giorgio는 해당 앱이 ZimaOS Store에서 설치된 것이 아님을 명확히 확인했습니다. 따라서 Store의 일반적인 제거 동작이 데이터 손실을 일으켰다고 주장하는 것은 안전하지 않습니다. 여기서 얻을 수 있는 확실한 교훈은, 완전히 이해하지 못한 정리 경로 외부에 대체할 수 없는 사진 자산과 데이터베이스 백업을 보관해야 한다는 것입니다.

사용자는 제거 및 재설치 후 대체할 수 없는 사진이 사라졌다고 보고했습니다

출처의 사용자는 Immich를 제거하는 과정에서 구성을 삭제하는 옵션을 선택했을 수 있다고 생각했습니다. 또한 충돌 루프가 발생했고, 장애 중 로그에 제대로 접근하지 못했으며, 결국 이미지를 복구하지 못해 ZimaOS를 떠났다고 설명했습니다.

이는 심각한 데이터 손실 보고이지만, 포럼에서는 어떤 작업이 실제로 어떤 파일을 삭제했는지 보여 주는 재현 가능한 절차가 제시되지 않았습니다.

첫 번째 설명은 커뮤니티의 추측이었습니다

커뮤니티의 한 답변에서는 원본 파일이 제거 정리 과정에서 구성 또는 사용자 데이터로 간주되는 앱 폴더 아래에 있었을 수 있다고 추정했습니다. 특히 사용자가 하나의 AppData 트리 안에 구성, 데이터베이스, 원본 미디어를 함께 저장하는 경우 이는 경고할 만한 합리적인 위험 요소입니다.

그러나 이것이 이번 특정 사건의 원인이라는 사실은 확인되지 않았습니다.

게시된 Compose 구성은 일반적인 Store AppData 예시와 다른 위치에 데이터를 매핑했습니다

이후 사용자는 다음과 같은 호스트 경로가 포함된 Compose 정의를 게시했습니다.

/mnt/bigdrive/data/immich/postgres
/mnt/bigdrive/data/immich/cache
/mnt/bigdrive/data/immich/library

Immich 서버는 라이브러리 폴더를 /data에 매핑했습니다. 이는 앞서 제시된 “모든 원본이 /DATA/AppData/immich 아래에 있었다”는 단순한 추정과 일치하지 않으므로 중요한 증거입니다.

IceWhale은 해당 앱이 ZimaOS Store의 Immich 패키지가 아니었음을 확인했습니다

Zima-Giorgio는 구성을 확인한 후 앱의 출처를 물었습니다. 사용자는 Immich Docker Compose 파일에서 설치했다고 답했습니다. 이후 Giorgio는 ZimaOS Store에서 앱을 설치할 것을 권장했습니다.

이 권고만으로 파일을 삭제한 원인을 알 수는 없지만, 앱 관리 방식의 경계는 분명히 드러납니다.

현재 ZimaOS에서는 컨테이너와 매핑된 데이터를 서로 다른 것으로 취급합니다

현재 IceWhale 문서에서는 컨테이너 자체는 일시적인 반면, 중요한 애플리케이션 데이터는 매핑된 호스트 폴더에 저장된다고 설명합니다. 또한 해당 호스트 폴더를 백업하고 AppData를 적절한 저장소에 보관할 것을 명시적으로 권장합니다.

상태를 저장하는 앱을 제거하기 전에 현재 ZimaOS 앱 데이터 모델을 확인하세요.

Immich에는 자산과 데이터베이스를 모두 보호해야 합니다

디스크에 저장된 사진과 동영상은 Immich 복구의 절반에 불과합니다. 앨범, 사용자, 메타데이터, 파일 기록 및 애플리케이션 상태는 PostgreSQL에 저장됩니다. 안전한 계획이라면 자산 트리와 호환 가능한 데이터베이스 백업을 모두 보호해야 합니다.

앱 제거 확인란을 백업 전략으로 의존하지 마세요.

사진 관리자를 제거하기 전에

호스트 측의 모든 볼륨 매핑을 기록합니다.
실제 사진 및 동영상 자산 경로를 확인합니다.
독립적인 데이터베이스 백업을 만들고 복원 테스트를 합니다.
대체할 수 없는 자산을 다른 장치 또는 저장소에 복사합니다.
“사용자 데이터/구성 삭제” 옵션이 정확히 무엇을 대상으로 하는지 이해합니다.
그런 다음에만 앱을 제거하거나 다시 생성합니다.

파일이 갑자기 사라지면 추가 쓰기를 최소화하세요

상태를 파악할 때까지 애플리케이션을 중지하고, 영향을 받은 파일 시스템에 컨테이너를 설치하거나 다시 생성하거나 새 데이터를 복사하지 마세요. 먼저 검증된 백업에서 복원하세요. 백업이 없고 파일이 실제로 사라졌다면 미디어를 보존하고, 해당 파일 시스템에 반복적으로 쓰기 작업을 수행하기보다는 파일 시스템에 맞는 복구 전문가의 도움을 받으세요.

출처의 커뮤니티에서는 복구 도구를 언급했지만, 이는 IceWhale의 절차가 아니며 모든 RAID 또는 파일 시스템에서 안전하다고 보장할 수 없습니다.