Immich 백업에서 일관되지 않은 상태가 캡처되지 않도록 하는 방법

일관되지 않은 Immich 백업을 방지하려면 데이터베이스와 미디어를 하나의 복구 단위로 취급하고, 캡처 순서와 쓰기 활동을 의도적으로 제어해야 합니다.

복사하도록 지정된 모든 파일이 백업에 포함되어 있어도, 데이터베이스가 캡처되지 않은 자산을 참조하거나 미디어 복사본이 카탈로그와 다른 시점을 반영한다면 복원이 제대로 되지 않을 수 있습니다. 먼저 일관성 경계를 정의하고, 중지 방식 또는 조정된 라이브 방식을 선택한 다음, 격리된 환경에서 결과를 검증하세요.

백업 예약 전에 복구 단위를 정의하세요

서비스를 재현하는 데 필요한 PostgreSQL 데이터베이스, 업로드된 미디어, 프로필 데이터, 배포 구성, 환경 값, 시크릿, 사용자 지정 저장 경로를 나열하세요. 생성된 썸네일, 인코딩된 동영상, 모델 파일은 복구 정책에 따라 보호할지 재생성할지를 별도로 표시하세요.

ZimaSpace의 Immich 라이브 백업과 중지 후 백업 비교에서는 기본적인 일관성 선택을 설명합니다. 이 예방 중심 워크플로는 한 단계 더 나아갑니다. 어떤 방식을 선택하든 어느 데이터베이스가 어느 미디어 복사본에 해당하는지 추측하지 않고 복원할 수 있는, 문서화된 시점을 만들어야 합니다.

백업 범위 옆에 복원 순서를 작성하세요. 계획에 “사진 복원”이라고만 적혀 있고 해당 사진을 사용자와 앨범에 다시 연결할 데이터베이스 덤프, 구성, 자격 증명, 저장소 매핑이 명시되어 있지 않다면 첫 예약 실행을 시작하기 전부터 백업 정의가 불완전한 것입니다.

가장 단순한 경계로 충분하다면 중지 후 캡처를 사용하세요

짧은 유지 관리 시간을 감수할 수 있는 소규모 가정 환경이라면 업로드를 일시 중지하고 라이브러리 상태를 기록하는 애플리케이션 서비스를 중지하세요. 데이터베이스 백업을 생성하고 미디어와 구성을 캡처한 다음, 스냅샷 또는 복사본에 명확한 타임스탬프와 완료 결과가 기록된 후에만 서비스를 다시 시작하세요.

애플리케이션을 중지했다고 해서 잘못된 경로가 자동으로 올바르게 되는 것은 아닙니다. 데이터베이스 내보내기가 성공했는지, 의도한 미디어 루트가 포함되었는지, 백업 대상이 복구하려는 라이브 데이터와 독립적인지 확인하세요. 나중에 복원할 때 정확한 백업 세대를 식별할 수 있도록 시작 및 종료 시간을 기록하세요.

캡처 중 애플리케이션 쓰기가 발생하지 않고, 테스트 복원에서 예상한 사용자, 자산 수, 앨범, 표본 원본이 반환되면 이 방식은 통과합니다. 중단 시간이 정기적으로 가정에서 허용할 수 있는 범위를 초과한다면, 파일 복사 도중 업로드가 조용히 재개되도록 두지 말고 조정된 라이브 방식으로 전환하세요.

라이브 백업에서는 데이터베이스와 파일을 정해진 순서로 캡처하세요

Immich를 계속 사용할 수 있어야 한다면 활성 PostgreSQL 데이터 디렉터리를 일반 파일처럼 복사하지 말고, 데이터베이스 자체의 일관성 있는 덤프를 생성하세요. 그런 다음 문서화된 순서에 따라 미디어 트리를 캡처하거나 스냅샷하고, 백업 시간 창 중에 들어오는 업로드를 추적하세요.

실습 중심의 Immich 데이터베이스 백업 워크플로에서는 데이터베이스를 인식하는 접근 방식을 보여 줍니다. 배포 환경에 따라 명령어와 컨테이너 이름은 달라질 수 있으므로, 적용 가능한 핵심 원칙은 데이터베이스 파일을 라이브 상태에서 재귀적으로 복사하는 방식을 신뢰하지 말고 PostgreSQL에 일관된 백업을 요청하는 것입니다.

복원된 데이터베이스가 백업에 포함되지 않은 미디어를 가리키는 상황을 방지할 수 있는 순서를 우선하세요. 파일 시스템 복사본에 데이터베이스가 아직 알지 못하는 추가 파일이 포함되는 것은, 참조된 원본이 없는 데이터베이스 레코드가 생기는 것보다 더 안전하게 조정할 수 있습니다. 경계를 넘은 업로드는 모두 문서화하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

원자성을 가정하지 말고 데이터베이스 훅으로 파일 시스템 스냅샷을 조정하세요

파일 시스템 스냅샷은 볼륨을 빠르게 캡처할 수 있어 유용하지만, 서로 독립적으로 변경되는 두 시스템을 그 자체로 트랜잭션 수준에서 일관되게 만들어 주지는 않습니다. 데이터베이스와 미디어가 서로 다른 데이터 세트나 장치에 있다면 사전 스냅샷 훅과 사후 스냅샷 훅을 정의하고, 백업 로그에 실행 시점을 명확히 기록하세요.

백업 소프트웨어와 Btrfs 스냅샷 훅을 결합한 2026년 사례는 스냅샷 오케스트레이션에 명시적인 애플리케이션 또는 데이터베이스 경계가 필요한 이유를 보여 줍니다. 이 아이디어를 캡처 조정에 활용하되, 파일 시스템 구성이 다른 환경에 해당 명령어를 그대로 복사하지 마세요.

스냅샷 도구가 데이터베이스와 미디어의 시간 경계를 조정할 수 없다면 원자적 복구라고 주장하지 말고, 논리적 데이터베이스 덤프와 미디어 백업을 조합하는 방식으로 돌아가세요. 더 빠른 캡처가 일관된 애플리케이션 상태를 실제로 복원한다는 복원 훈련 결과가 있을 때만 복잡성을 정당화할 수 있습니다.

복원 테스트를 백업 일정의 일부로 만드세요

성공한 백업 작업은 캡처가 완료되었다는 증거일 뿐입니다. 주기적으로 최근 백업 세대를 선택해 격리된 호스트 이름으로 복원하고, 예상 저장소를 연결한 다음 사용자, 대표 원본, 앨범, 권한, 검색 동작, 복원된 인스턴스에서 새로 생성한 데이터베이스 백업을 확인하세요.

PostgreSQL 백업 및 복원 계획의 PostgreSQL 복구 개요에서는 덤프 생성을 최종 단계로 취급하지 않고 복원 검증과 복구 목표를 강조합니다. 동일한 원칙을 Immich 통합 복구 단위에도 적용하세요.

데이터베이스 복원은 성공했지만 파일이 누락되거나, 미디어는 열리지만 사용자 또는 관계가 없거나, 실패한 호스트에만 저장된 시크릿에 복구가 의존한다면 백업 정책을 실패로 처리하세요. 백업 빈도를 늘리기 전에 범위, 순서, 보존 기간 또는 독립성을 수정하세요. 일관성이 없는 복사본을 더 많이 만든다고 신뢰할 수 있는 복구 지점이 생기는 것은 아닙니다.