디스크 하나, 호스트, 마운트, 자격 증명 또는 문서화되지 않은 경로 하나로 실행 상태와 사용 가능한 모든 복구 사본이 함께 사라질 수 있다면 Home Assistant 스토리지 구성이 복구 위험 요소가 되고 있습니다.
장애가 발생하기 전부터 경고가 나타나는 경우가 많습니다. 백업이 VM과 같은 위치에 있거나, 네트워크 공유가 다른 경로로 다시 연결되거나, 데이터베이스는 외부에 있지만 문서화된 복구 순서가 없거나, 아카이브가 자기 자신을 재귀적으로 포함하는 경우입니다. 모든 영구 데이터 역할과 장애 도메인을 매핑한 다음, 무엇이든 이동하거나 삭제하기 전에 읽기 전용 복구 검토를 수행하세요.
데이터 역할과 실제 장애 도메인 매핑
시스템 디스크, 구성, 활성 데이터베이스, 애드온 상태, 미디어, 로그, 로컬 스냅샷, 독립 백업, 암호화 키, 복구 문서를 목록으로 작성하세요. 각 역할에 필요한 물리 디스크, 스토리지 풀, 호스트, 네트워크 경로, 자격 증명, 관리자도 기록하세요.
하나의 풀에 있는 두 디렉터리는 경로는 서로 다르지만 동일한 스토리지 장애 도메인에 속합니다. VM 스냅샷과 해당 호스트 스토리지는 함께 장애가 발생할 수 있습니다. NAS 백업도 운영 환경을 복구하는 데 필요한 동일한 스위치, 비밀번호 저장소 또는 관리자 계정에 의존할 수 있습니다.
중요한 역할의 소유자가 불분명하거나 모든 복구 사본이 운영 디스크, 풀, 호스트 또는 자격 증명을 공유한다면 레이아웃 검토에서 실패로 처리하세요. 여유 공간이 부족해질 때까지 기다렸다가 해당 종속성을 수정하지 마세요.
용량 및 마운트 경고 패턴 확인
데이터베이스, 백업, 로그, 미디어, 임시 파일별로 7일간의 증가량을 측정하세요. 작업 시작 시 백업 대상이 마운트되어 있는지, 마운트가 없을 때 쓰기가 로컬 대체 디렉터리로 이루어지는지, 아카이브 경로에 이전 아카이브가 포함될 수 있는지 확인하세요.
재귀적 백업 경로는 복구 가능한 기록을 추가하지 않고도 빠른 용량 증가를 일으킬 수 있습니다. 재귀를 용량을 구매해야 할 이유가 아니라 구성 오류로 취급하세요.
증가량이 일정하고 원인이 명확하다면 보존 정책 및 복구 시간 목표와 비교하세요. 증가량이 단계적으로 상승하거나, 마운트가 사라지거나, 경로가 중복된다면 새 백업 작업을 중지하고 대상을 수정하기 전에 정상임을 확인한 사본 하나를 보존하세요.
통제된 손실 시나리오로 독립성 테스트
각 주요 장애 도메인에 대해 해당 도메인을 사용할 수 없을 때 백업 파일, 복호화 키, 초기화된 대상, 지침을 계속 이용할 수 있는지 확인하세요. 정상으로 표시된 작업 상태만 확인하지 말고, 독립 사본을 읽고 격리된 복구를 수행하여 검증하세요.
운영 드라이브 외부에 백업을 저장하는 것은 운영 환경의 손실 이후에도 해당 백업의 자격 증명과 복구 지침이 남아 있을 때만 별도의 장애 도메인을 만듭니다.
실패한 운영 경로 없이 접근할 수 있는 복구 사본이 있어야 통과입니다. 그렇지 않으면 마이그레이션 자체가 위험을 높이므로, 레이아웃을 변경하기 전에 백업과 키를 이동하거나 복제해야 합니다.
위험 하나를 수정하고 복구를 리허설
영향이 가장 큰 공유 장애 도메인을 먼저 분리하고, 마운트 및 데이터베이스 복구 순서를 문서화하며, 재귀를 제거하고, 측정된 증가량을 기준으로 보존 정책을 설정하고, 각 백업 전에 대상의 존재 여부를 모니터링하세요. 새 사본이 검증될 때까지 이전 레이아웃을 유지하세요.
활성 상태를 원격 마운트에 배치하기 전에 네트워크 스토리지 안정성 경계를 확인하세요.
운영 환경에 명확히 지정된 기본 위치가 있고, 모든 중요 역할에 보호 방법이 있으며, 독립 복구가 복구 목표를 충족하면 중지하세요. 스토리지 I/O 오류, 반복적인 마운트 해제, 손상된 아카이브 또는 설명되지 않은 소유권 변경이 발생하면 추가 마이그레이션 전에 문제를 에스컬레이션하세요.
수정 후 레이아웃 모니터링
변경 후 여유 공간, 데이터 유형별 증가량, 마운트 상태, 백업 경과 시간, 아카이브 크기, 복구 테스트 날짜를 추적하세요. 알림은 전체 디스크 비율만 보고하지 말고 영향을 받은 역할과 대상을 식별해야 합니다.
처음 두 번의 백업 주기를 문서화된 레이아웃과 비교하고, 로컬 대체 디렉터리나 재귀 경로가 다시 나타나지 않았는지 확인하세요. 보존 정책이 의도한 오래된 사본만 삭제하고 독립 복구 사본은 계속 이용 가능한지 검증하세요.
데이터베이스, 스토리지 풀, 마운트 프로토콜, 암호화 키 또는 백업 대상이 변경되면 복구 검토를 다시 시작하세요. 토폴로지 변경 전에 통과한 레이아웃은 새 시스템이 아니라 이전 시스템에 대한 근거입니다.
지원 및 팁
더 읽어보기

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

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

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

