Immich 설치를 수리하는 대신 재구축해야 할 때는 언제인가요?

문제가 한정된 영역에 있고 영구 데이터가 확실히 온전하다면 Immich를 복구하세요. 반면 설정 드리프트가 광범위하지만 검증된 데이터베이스, 미디어 라이브러리, 배포 정의, 롤백 사본으로 서비스를 안전하게 재현할 수 있다면 런타임을 재구축하세요.

재구축은 모든 것을 삭제하는 것과 같지 않습니다. 컨테이너와 네트워크는 폐기할 수 있지만, 데이터베이스와 원본 파일은 라이브러리의 기록입니다. 먼저 무결성, 범위, 재현 가능성을 분류하세요. 유일한 데이터베이스나 사진의 유일한 사본이 손상되었을 수 있다면 이를 보존하고 중단하세요. 해당 증거를 바탕으로 진단할 수 있는 사고를 새로 시작하면 영구적인 손실로 이어질 수 있습니다.

문제가 국소적이고 되돌릴 수 있을 때 복구

하나의 마운트, 권한, 환경 값, 종속성, 작업 또는 고정된 이미지가 장애의 원인을 설명하고, 알려진 변경 전에는 시스템이 정상적으로 작동했다면 복구를 우선하세요. 로그를 수집하고 백업을 만든 뒤 해당 계층 하나만 변경하고 트리거를 다시 실행하세요.

복구 성공은 누락된 자산, 데이터베이스 오류 또는 새로운 시작 경고를 만들지 않고 실패한 기능을 되살리는 것입니다. 컨테이너를 다시 만든 뒤에도 같은 문제가 반복된다면 원인은 배포 정의나 영구 상태에 있을 수 있으므로, 컨테이너를 계속 교체하는 것은 더 이상 근거 있는 복구가 아닙니다.

데이터베이스 손상에 관한 논의는 데이터베이스가 의심되는 계층일 때 복구 선택이 얼마나 빠르게 고위험 작업이 되는지 보여줍니다. 검증되지 않은 파괴적 명령이 아니라 복구 전 보존 교훈을 따르세요.

드리프트를 통제할 수 없을 때 런타임 재구축

이미지 버전, 네트워크, 환경 값, 마운트 및 수동 컨테이너 변경을 더 이상 재현할 수 없지만 검증된 영구 구성 요소는 온전하다면 깨끗한 런타임 재구축을 선택하세요. 기존 인스턴스를 삭제하지 말고, 고정된 버전과 격리된 포트를 사용해 기존 인스턴스 옆에서 구축하세요.

호스트가 침해되었거나 지원되지 않는 설치에 알 수 없는 변경 사항이 누적된 경우에도 재구축이 적절합니다. 신뢰할 수 있는 배포 입력을 복원하면 새로운 감사 경계가 만들어지기 때문입니다. 노출된 자격 증명을 교체하고 백업을 깨끗한 대상에 연결하기 전에 검사하세요.

ZimaSpace의 셀프 호스팅 앱 배포 개요는 더 넓은 서비스 스택의 맥락을 제공합니다. 그러나 Immich에서는 데이터베이스와 미디어 간의 관계를 별도로 검증해야 합니다.

확실하지 않은 영구 데이터 위에 재구축하지 마세요

데이터베이스와 업로드 라이브러리가 서로 동기화되지 않았을 수 있거나, 유일한 백업을 테스트하지 않았거나, 권위 있는 사본이 무엇인지 불분명하다면 중단하세요. 데이터베이스 복구나 미디어 조정을 시도하기 전에 모든 후보를 스냅샷하거나 복제하고 타임스탬프를 기록하세요.

Unraid 복구 스레드는 백업 구성 요소와 버전이 일치하지 않을 때 Immich를 복원하는 작업이 얼마나 어려운지 보여줍니다. 해당 복원 경계 논의는 프로덕션 경로를 덮어쓰는 대신 격리된 환경에서 테스트할 것을 뒷받침합니다.

원본 파일은 온전하지만 데이터베이스를 복구할 수 없다면 새 라이브러리 가져오기를 고려하기 전에 두 가지 모두를 보존하고 그 결과를 문서화하세요. 이는 일상적인 복구가 아니라 데이터 재구성에 관한 결정이며, 앨범, 공유 상태, 얼굴 데이터, 즐겨찾기 또는 과거 메타데이터가 손실될 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

깨끗한 대상에서 영구 데이터 검증

복사한 영구 데이터를 깨끗한 대상에 복원하거나 연결한 다음 사용자, 타임라인 수, 샘플링한 원본, 앨범, 검색, 얼굴 데이터, 외부 라이브러리, 새 업로드, 작업 및 새 데이터베이스 백업을 테스트하세요. 결과를 보존한 원본 증거와 비교하세요.

여러 날짜, 사용자 및 미디어 유형에 걸쳐 데이터베이스 자산 수와 샘플링한 파일을 비교하세요. 프로덕션 주소를 할당하기 전에 외부 라이브러리 경로, 파생 작업 및 새 데이터베이스 덤프를 확인하세요. 로그인 화면만으로는 데이터 무결성이 입증되지 않습니다.

컨테이너와 호스트를 두 번 재시작하세요. 성공 조건은 안정적인 마운트, 반복 가능한 설정, 마이그레이션 루프 없음, 원래 워크로드입니다. 깨끗한 대상에서 동일한 데이터베이스 또는 파일 오류가 재현된다면 원인은 런타임 드리프트가 아니며, 전문 데이터 복구가 더 안전한 경로입니다.

롤백 경계와 함께 전환

격리된 검사를 통과한 후에만 프로덕션 주소를 이전하고, 합의된 관찰 기간 동안 기존 시스템은 전원을 끈 상태로 복구 가능하게 유지하세요. 두 인스턴스가 동시에 업로드를 수락하거나 동일한 자동화를 제공하지 않도록 하세요.

전환 후에는 평소의 가족 업로드, 탐색, 검색, 공유 및 백업 작업을 실행하세요. 성공 조건은 다음 재시작 후에도 수와 원본이 유지되는 것입니다. 불일치가 발생하면 어느 데이터셋도 덮어쓰지 않고 보존된 대상으로 트래픽을 되돌리세요.

깨끗한 대상에서 동일한 데이터베이스 또는 파일 오류가 재현되면 복구나 전문 복구로 돌아가세요. 원인은 런타임이 아니었습니다. 수나 원본이 다르면 전환을 롤백하세요. 버전, 체크섬, 백업 타임스탬프, 최초 오류, 복사된 상태와 새로 생성된 상태 사이의 정확한 경계를 포함해 에스컬레이션하세요.