정상 백업에서 Immich 데이터베이스를 복구하는 방법

정상적으로 작동하는 Immich 데이터베이스 백업은 통제된 상태로 복원하고, 복구된 데이터베이스가 서버에서 실제로 확인할 수 있는 미디어를 계속 가리키는지 입증할 때만 유용합니다.

복구는 단일 가져오기 명령이 아니라 일련의 과정으로 다루세요. 먼저 장애가 발생한 인스턴스를 보존하고, Immich 버전과 백업 시점을 확인한 다음, 호환되는 깨끗한 데이터베이스 대상을 시작하세요. 애플리케이션이 빈 스키마에 먼저 쓰지 않도록 한 상태에서 복원한 뒤, 계정, 타임라인 데이터, 미디어 경로 및 새 쓰기 하나를 검증하세요. 어느 단계라도 불확실하면 마지막으로 복구 가능한 사본을 교체하기 전에 중단하세요.

복원하기 전에 장애 상태 동결하기

복구 작업을 시작하기 전에 영향을 받은 Immich 인스턴스의 새 업로드와 백그라운드 쓰기를 중지하세요. 현재 Compose 파일, 환경 변수, 마운트된 경로, 이미지 버전, 최근 로그 및 손상된 데이터베이스 상태를 저장 공간이 허용하는 한 보존하세요. 장애가 발생한 데이터베이스에는 원인을 설명하는 증거가 남아 있을 수 있으며, 이를 덮어쓰으면 해당 증거가 사라집니다.

신뢰할 백업이 정확히 무엇인지 확인하세요. 타임스탬프, 생성 방법, 파일 크기 및 테스트 복원을 수행한 적이 있는지를 기록하세요. 데이터베이스가 생성한 SQL 덤프는 실행 중인 PostgreSQL 데이터 디렉터리를 단순히 복사한 원시 사본과는 다른 복구 자산입니다. 둘을 서로 바꿔 사용할 수 있는 것으로 취급하지 마세요.

가능하면 별도의 디렉터리나 격리된 스택에 복구 대상을 생성하세요. 이 단계의 종료 조건은 간단합니다. 원래의 장애 상태가 보존되어 있고, 선택한 백업이 읽기 전용이며, 복원을 통해 다시 연결할 배포 버전과 저장 경로를 알고 있어야 합니다.

백업이 실제로 복원 가능한지 확인하기

재생하기 전에 백업을 검사하세요. 압축된 SQL 덤프는 문제없이 압축이 해제되어야 하며, 실패한 파이프라인이 만든 빈 아카이브가 아니라 식별 가능한 PostgreSQL 덤프 내용을 포함해야 합니다. 체크섬이나 저장소 검증 결과가 있다면 복구 도중 손상을 발견하지 않도록 지금 비교하세요.

PostgreSQL 덤프는 실행 중인 데이터베이스 디렉터리를 단순히 복사한 파일보다 안전한 복구 자산입니다. 데이터베이스를 인식하는 도구로 생성되며 깨끗한 대상에 재생할 수 있기 때문입니다. 데이터베이스 덤프 백업 방식은 데이터베이스를 미디어 사본과 분리하므로 복구 전에 양쪽을 각각 더 쉽게 검증할 수 있습니다.

또한 백업 시점에 해당하는 미디어와 구성이 여전히 존재하는지 확인하세요. 데이터베이스만 복원하면 사용자, 앨범, 메타데이터 및 파일 참조는 복구할 수 있지만, 참조된 라이브러리 경로가 없으면 모든 자산이 손상된 상태로 남을 수 있습니다. 덤프와 미디어/구성 세트가 알려진 하나의 복구 시점에 속할 때만 진행하세요.

먼저 호환되는 깨끗한 데이터베이스 대상 시작하기

복원 방법을 백업을 생성한 버전에 맞추세요. 현재 Immich 릴리스는 관리 > 유지 관리와 새로 설치할 때의 온보딩 흐름을 통해 데이터베이스 복원을 제공하지만, 이전 백업은 버전별 수동 지침이 필요할 수 있습니다. 복원 작업 흐름은 v2.5.0에서 변경되었습니다.

새 복구 대상에서는 데이터베이스 복원이 준비되기 전에 Immich가 빈 스키마에 일반 마이그레이션을 실행하도록 두지 마세요. 배포 방식이 PostgreSQL과 애플리케이션을 함께 시작한다면, 버전에 맞는 복원 제어 기능을 사용하여 가져오기 전에 서버가 서로 충돌하는 상태를 만들지 않도록 하세요.

데이터베이스가 자체적으로 정상 상태가 되지 않는다면 먼저 그 문제를 해결하세요. 재시작을 반복하거나 디스크 공간이 부족하거나 호환되지 않는 저장소 레이아웃을 사용하는 대상에 동일한 백업을 계속 재생하지 마세요. 깨끗하고 안정적인 대상은 부수적인 문제 해결 항목이 아니라 필수 조건입니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

덤프는 한 번 복원하고 첫 오류에서 중단하기

선택한 덤프를 준비된 데이터베이스에 복원하고 전체 출력을 저장하세요. 덤프 형식에 맞는 데이터베이스 도구와 플래그를 사용하여 오류가 발생하면 복원이 명확하게 실패하도록 하세요. 부분적으로 가져온 스키마가 여전히 시작되는 상황을 방치해서는 안 됩니다.

사용 가능한 마이그레이션 세트에는 자산, PostgreSQL 상태 및 이들을 다시 연결하는 구성이 필요합니다. 완전한 Immich 백업 세트에는 업로드된 자산, 지원되는 데이터베이스 백업 및 배포 구성이 포함되며, 복원 테스트를 통해 세트가 작동하는지 입증합니다. 대상이 하나의 복구 시점과 일치하도록 이러한 구성 요소를 함께 보관하세요.

가져오기가 성공하면 Immich 애플리케이션을 시작하고 첫 시작 과정을 주의 깊게 지켜보세요. 기존 계정을 받아들이지 않고 새 최초 관리자를 만들라고 인터페이스에 표시되면 중단하세요. 이는 복원된 데이터베이스를 Immich가 사용하고 있지 않다는 강력한 신호입니다. 그 빈 상태에 사진을 다시 업로드하기 시작하지 마세요.

데이터베이스 상태, 미디어 경로 및 새 쓰기 검증하기

기존 계정으로 로그인하고 과거와 최근 날짜에 걸쳐 타임라인을 일부 확인하세요. 실제로 존재했던 여러 원본 파일을 열고, 앨범이나 즐겨찾기를 살펴보며, 애플리케이션이 데이터베이스 행만 표시하는 것이 아니라 기본 파일을 실제로 확인할 수 있는지 검증하세요.

복원 시점에는 데이터베이스 상태, 애플리케이션 파일, 구성 및 업로드 파일이 서로 일치해야 합니다. 단순히 PostgreSQL이 시작되는지만 보지 말고 일관된 데이터베이스 컨테이너 백업을 승인 기준으로 삼으세요.

마지막으로 삭제해도 되는 사진 하나를 업로드하고 정상적인 처리가 완료될 때까지 기다리세요. 그런 다음 Immich 재시작과 호스트 재부팅 후에도 사진이 유지되는지 확인하고 애플리케이션을 통해 삭제하세요. 계정, 기존 자산 및 새 쓰기가 모두 정상적으로 작동한다면 버전을 업그레이드하기 전에 복구된 상태를 새로 백업하세요. 그렇지 않다면 피해를 더 키우지 말고 보존해 둔 장애 증거나 이전의 정상 백업으로 돌아가세요.