새 대시보드가 로드되고 사진이 표시된다는 이유만으로 기존 Immich 서버를 폐기하지 마세요. 복원된 시스템에서 사용자, 앨범, 인물, 검색, 일부 원본 샘플, 새 업로드, 백그라운드 작업, 재시작 및 새 백업이 정상임을 확인하고, 기존 호스트를 롤백 대상으로 계속 사용할 수 있을 때만 폐기하세요.
검증하는 동안에는 기존 서버의 전원을 끄되 변경하지 마세요. 두 인스턴스가 서로 다른 상태에 업로드를 수락하는 일이 없어야 합니다. 먼저 복원된 호스트에 통제된 테스트 주소를 할당하고, 기존 시스템의 기준 상태를 기록한 다음, 타임라인이 완성되어 보인다는 시각적 인상에 의존하지 말고 동일한 가정 내 작업 흐름을 비교하세요.
복원 기준을 설정하는 동안 기존 서버를 그대로 유지하세요
전환 전에 사용자 수, 자산 수, 대표 앨범 몇 개, 이름이 지정된 인물, 즐겨찾기, 공유 항목, 외부 라이브러리 경로, 사용자와 날짜가 서로 다른 원본 샘플 몇 개를 기록하세요. 기존 Immich 및 PostgreSQL 버전과 복원에 사용한 백업 아티팩트도 기록하세요. 폴더 또는 스토리지 무결성 검사는 유용한 통과 기준이지만, 관계 수준의 검증을 대신할 수는 없습니다.
검색 가능한 사진 라이브러리 복원에 대한 ZimaSpace의 복구 모델은 원본, 카탈로그/데이터베이스 상태, 경로를 정의하는 구성을 하나의 복구 단위로 취급합니다. 이는 올바른 기준입니다. 이미지 파일만으로는 앨범 소속, 소유권, 인물 및 검색 관계가 보존되었음을 입증할 수 없기 때문입니다.
아직 기존 디스크를 삭제하거나, 기존 IP를 영구적으로 재사용하거나, 마지막으로 정상임이 확인된 백업을 삭제하지 마세요. 검증 목표는 되돌릴 수 있어야 합니다. 중요한 관계 하나라도 누락되면 문제가 백업, 복원 방법, 경로 매핑 또는 새로운 런타임 중 어디에서 발생했는지 확인할 수 있도록 기존 상태가 필요합니다.
사진 표시가 아니라 관계를 확인하세요
예상되는 사용자 중 두 명 이상으로 로그인하여 각 계정에 올바른 자산과 공유 항목이 표시되는지 확인하세요. 파일만으로는 재구성하기 어려운 기존 앨범, 이름이 지정된 인물, 즐겨찾기, 추억 또는 기타 가정별 관계를 열어 보세요. 기록해 둔 기존 서버의 기준 상태와 일부 항목을 비교하세요.
앨범 누락 문제를 다룬 Immich PostgreSQL 복원 관련 마이그레이션 논의는 이것이 중요한 이유를 보여 줍니다. 사진은 남아 있어도 앨범 상태가 없을 수 있고, 이후 데이터베이스를 다시 덤프하면 결과가 달라질 수 있습니다. 이를 성공적인 로그인이나 표시되는 타임라인만으로는 완전한 복원 테스트가 될 수 없다는 사례로 받아들이세요.
메타데이터와 활성화된 시각 또는 인물 기능을 사용하여 알려진 자산 몇 개를 검색하세요. 원본은 있지만 관계나 검색 결과가 누락된 경우, 해당 상태가 복원되어야 했는지 아니면 의도적으로 다시 생성되는 중인지 확인하세요. 이 구분이 해결될 때까지 기존 서버를 폐기하지 마세요.
읽기, 쓰기, 종속성 및 재시작 경로를 실행하세요
복원된 스토리지에서 기존 사진과 동영상을 직접 열어 본 다음, 모바일 또는 웹 클라이언트에서 테스트용 새 자산을 업로드하세요. 원본이 의도한 경로에 기록되고, 올바른 사용자에게 표시되며, 백그라운드 작업이 진행되는지 확인하세요. 외부 라이브러리와 원격 액세스는 로컬 읽기/쓰기 경로가 안정된 후에만 테스트하세요.
복원 테스트는 바이트를 복사한 뒤 애플리케이션을 검증해야 합니다. 최신 재해 복구 테스트 가이드는 완료된 백업 또는 복원 작업에서 멈추지 말고 데이터베이스, 권한, 네트워크 연결 및 서비스를 포함한 애플리케이션 수준의 검증을 수행할 것을 권장합니다. Immich 스택을 두 번 재시작하고 새 호스트를 한 번 재부팅하세요. 각 주기 후 동일한 마운트, 사용자, 샘플 자산, 데이터베이스, 프록시 또는 로컬 엔드포인트와 작업 동작이 복구되는지 확인하세요. 첫 호스트 재부팅 전까지만 작동하는 서비스는 마이그레이션을 통과한 것이 아닙니다.
롤백 기간을 종료하기 전에 새 백업을 생성하세요
데이터베이스와 일관성이 보장되는 새 백업을 생성하고, 복구 설계에 필요한 미디어 및 구성 범위를 보호하세요. 최소한 소규모 검증 대상을 복원하거나, 전환 전에 사용한 것과 동일한 절차로 백업을 검사하세요. 자체적으로 복구 가능한 백업을 생성할 수 없는 복원 서버를 유일한 운영 복사본으로 만들어서는 안 됩니다.
새 호스트에서 일반적인 휴대폰 업로드, 탐색, 검색, 백그라운드 처리, 예약 백업 및 최소 한 번의 야간 주기를 포함하는 정의된 관찰 기간을 운영하세요. 상태가 분리되지 않도록 기존 호스트는 꺼 둔 상태로 유지하되, 새 시스템이 설명할 수 없는 차이 없이 이러한 이벤트를 견딜 때까지 기존 호스트를 변경하지 말고 보존하세요.
운영 전환을 결정하려면 중요한 관계가 일치하고, 원본을 읽을 수 있으며, 새 쓰기가 성공하고, 재시작이 안정적이며, 새로 생성된 백업이 검증되어야 합니다.
사용자가 사라지거나, 수치가 크게 달라지거나, 경로 오류가 다시 발생하거나, 데이터베이스에서 일관성 문제가 보고되면 새 인스턴스를 종료하고 조사 전에 양쪽 상태를 모두 보존하세요. 그 후에야 기존 서버를 초기화하거나 다른 용도로 전환해야 합니다.
지원 및 팁
더 읽어보기

여러 컨테이너에서 동시 실행할 때 Immich 데이터베이스 연결을 최적화하는 방법
먼저 max_connections를 늘리지 마세요. Immich 세션을 측정하고, 모든 컨테이너의 요구량을 합산하며, 관리용 여유 공간을 확보한 뒤, 실제로 확인된 병목만 조정하세요.

Immich에서 중복 작업 또는 가져오기를 방지하는 방법
반복 작업과 중복 자산을 분리하세요. 하나의 표준 수집 경로를 사용하고, 재시도와 경로 변경을 제어한 다음, 소규모 코호트에서 재진입을 테스트하세요.

데이터베이스 볼륨이 가득 찬 후 Immich를 복구하는 방법
공간을 확보하기 위해 PostgreSQL WAL을 절대 삭제하지 마세요. Immich 쓰기를 중지하고, 데이터베이스 상태를 보존한 뒤, 안전하게 용량을 추가하고 PostgreSQL을 복구한 다음 재발을 방지하세요.

