사용자, 기록 또는 설정을 잃지 않고 Immich 데이터를 이동하는 방법

Immich를 단순히 폴더 복사 방식이 아니라 애플리케이션 상태 마이그레이션으로 이전하세요. 데이터베이스, 미디어 트리, 구성, 보안 정보, 그리고 이들을 연결하는 경로를 보존해야 합니다.

새 디스크에 모든 JPEG가 존재하더라도 계정, 앨범, 사람, 공유 항목, 즐겨찾기 또는 과거 관계가 사라지면 마이그레이션은 성공한 것처럼 보일 수 있습니다. 먼저 롤백 지점을 만들고, 일관된 원본 상태를 캡처한 뒤 식별자를 변경하지 않고 복사하세요. 격리된 대상에서 복원하고, 가정 내 사용 흐름이 일치하는 것을 확인한 후에만 전환해야 합니다.

함께 이동해야 하는 상태를 목록화하세요

PostgreSQL 데이터베이스, 업로드된 미디어, 보존하려는 생성 데이터, 외부 라이브러리 정의, Compose 또는 앱 구성, 환경 값, 보안 정보, 네트워크 이름, 현재 스토리지 매핑을 나열하세요. 각 항목 중 무엇이 기준 데이터인지, 복구 후 무엇을 다시 생성할 수 있는지도 표시하세요.

이동 중 Immich 사용자 보존에 관한 2026년 마이그레이션 논의는 핵심을 잘 보여 줍니다. 사용자 및 라이브러리 상태는 컨테이너 이미지가 아니라 데이터베이스와 마운트된 경로에 연결되어 있습니다. 커뮤니티 명령은 예시로만 보고, 실제 배포 버전에 맞게 조정하세요.

이전 전에 작은 검증 세트를 작성하세요. 사용자 2명, 여러 앨범, 즐겨찾기, 공유 항목, 사람 또는 검색 결과 1개, 오래된 자산과 최근 자산, 그리고 사용 중이라면 외부 라이브러리 경로 1개를 포함하면 됩니다. 이러한 알려진 기록이 있으면 전체 파일 크기만 비교하는 것보다 마이그레이션 후 검증을 훨씬 강력하게 수행할 수 있습니다.

복사 전에 일관된 복구 지점을 만드세요

새 업로드를 일시 중지하거나 유지보수 시간을 예약하여 상태를 캡처하는 동안 원본 변경을 멈추세요. 데이터베이스 기본 백업을 생성하고 원본 미디어와 구성을 보호하세요. 대상이 검증을 통과할 때까지 캡처 후 원본 인스턴스는 변경하지 않은 상태로 유지하세요.

사진 라이브러리 구성 요소를 함께 복원하는 방법에 관한 ZimaSpace 복구 가이드는 원본 파일, 카탈로그 상태, 경로를 정의하는 구성이 호환되는 복구 지점을 나타내야 하는 이유를 설명합니다. 마이그레이션에도 동일한 기준이 필요합니다.

변경 중인 라이브 프로덕션 데이터베이스 디렉터리를 일반 파일 복사 대상으로 사용하지 마세요. 다운타임을 줄여야 한다면 데이터베이스를 인식하는 덤프 방식과 캡처 순서를 이해하고 있는 스토리지 방식을 사용하세요. 마이그레이션의 복구 가능성은 복사한 파일 수가 아니라 실제로 복원할 수 있는 지점에 달려 있습니다.

경로와 권한을 유지한 채 미디어를 복사하세요

마이그레이션 중 폴더 구조를 재구성하지 말고 미디어 트리를 대상에 복사하세요. 소유자, 권한, 타임스탬프와 배포에 필요한 파일 시스템 기능을 보존하세요. 컨테이너에서 보이는 경로를 동일하게 유지해야 한다면 컨테이너 내부 매핑은 그대로 두고 호스트 측 바인드 소스만 변경하세요.

현재의 rsync 마이그레이션 작업 흐름은 아카이브 모드, 시험 실행, 재개 가능한 전송, 파괴적인 미러링 옵션의 위험을 강조합니다. 삭제하기 전에 시험 비교를 실행하고, 명령이 완료되었다고 애플리케이션 마이그레이션도 완료된 것으로 간주하지 말고 대상을 검증하세요.

파일 수와 크기를 비교한 다음 오래된 사진, 새 사진, 동영상, 대용량 파일에서 대표적인 체크섬 샘플을 검증하세요. 원본이 변경되어 복사 오류나 “사라진 파일”이 표시되면 업로드 수용을 중지하고 차등 복사 단계를 반복하세요. 깔끔해 보이는 대상을 만들기 위해 원본을 삭제해서는 안 됩니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

격리된 대상에서 데이터베이스와 구성을 복원하세요

검증 중 모바일 클라이언트가 대상에 업로드하지 못하도록 임시 호스트 이름이나 격리된 네트워크에서 대상을 시작하세요. 복사한 미디어를 예상되는 컨테이너 경로에 연결하고, 해당 버전에 필요한 환경, 보안 정보, 네트워크, 프록시 설정을 재현한 뒤 일치하는 데이터베이스를 복원하세요.

단계적으로 서버를 이전한 2026년의 별도 사례는 기존 서버를 폐기하기 전에 새 호스트를 테스트해야 하는 이유를 보여 줍니다. 이러한 보고서는 장애 유형을 파악하는 데 활용하되, 마이그레이션에서 실제로 상태가 보존되었는지는 미리 정한 검증 기록으로 판단하세요.

대상이 새로 설치된 인스턴스로 열리거나, 스토리지가 없다고 보고하거나, 파괴적인 초기화를 제안하면 중지하세요. 이러한 증상은 대개 데이터베이스나 마운트가 예상한 대상이 아니라는 뜻입니다. 먼저 경로 또는 복원 대상을 바로잡으세요. 비어 있는 것처럼 보이는 인스턴스에 새 파일을 업로드해 서로 경쟁하는 두 개의 기록을 만들지 마세요.

사용자, 기록, 새 쓰기가 통과한 후에만 전환하세요

각 기준 사용자로 로그인하여 앨범 소속, 즐겨찾기, 공유, 검색 또는 사람 상태, 대표 원본, 타임스탬프, 예상 라이브러리 수를 확인하세요. 그런 다음 새 테스트 사진 1장을 업로드하고 사진이 표시되고 처리되며 컨테이너 재시작 후에도 유지되는지 확인하세요.

격리된 테스트를 통과한 후에만 프로덕션 DNS 또는 프록시 대상을 변경하세요. 두 시스템이 동시에 쓰기를 받을 수 없도록 기존 인스턴스는 중지하되 복구 가능한 상태로 유지하세요. 새 호스트가 정상적인 백업을 완료하고 최소 한 번의 복원 테스트를 통과할 때까지 마이그레이션 전 데이터베이스 백업과 원본 미디어를 보존하세요.

수가 일치하지 않거나, 알려진 관계가 사라지거나, 새 업로드가 잘못된 디스크에 저장되거나, 재시작 후 대상이 실패하면 롤백하세요. 원본 및 대상 버전, 데이터베이스 백업 타임스탬프, 마운트 매핑, 복사 로그, 권한 차이, 그리고 처음 실패한 검증 항목을 포함해 문제를 전달하세요.