저장 경로 변경 후 Home Assistant에 오래된 데이터가 표시됨

스토리지 경로를 변경한 후 Home Assistant의 데이터가 오래된 상태로 보인다면, 일반적으로 Home Assistant가 메모리에서 이전 상태를 다시 만든 것이 아니라 실행 중인 인스턴스가 예상과 다른 /config 또는 데이터베이스를 읽고 있다는 뜻입니다.

경로 변경을 중단하고 이전 데이터 위치와 새 데이터 위치를 모두 보존하세요. 실행 중인 컨테이너에서 마운트된 소스, 활성 데이터베이스와 인스턴스를 확인하고, 타임스탬프와 고유한 상태를 비교한 다음 하나의 매핑만 수정하세요. 기록이나 레지스트리를 덮어쓸 수 있다면 파일을 복사하거나 이름을 변경하기 전에 Home Assistant를 중지하세요.

실행 중인 컨테이너가 실제로 보는 경로 확인

Compose 파일만 보지 말고 실행 중인 컨테이너를 검사하세요. /config에 매핑된 호스트 소스가 무엇인지, 바인드 마운트인지 이름 있는 볼륨인지, 확인된 소스가 실제로 존재하며 예상한 구성 파일을 포함하는지 확인하세요. 선언 내용이 올바르게 보여도 컨테이너를 불완전하게 다시 만든 후에는 실행 중인 컨테이너의 매핑이 다를 수 있습니다.

확인된 마이그레이션 논의에서는 컨테이너를 이동하려면 사용 가능한 권한이 있는 올바른 바인드 마운트된 구성 폴더가 필요하다고 강조합니다. 따라서 먼저 실제 매핑을 확인해야 하지만, 모든 오래된 데이터 문제가 권한 오류라는 뜻은 아닙니다.

Home Assistant가 중지된 상태에서 의도한 호스트 경로에 무해한 표시 파일을 만든 다음, 임시 검사 컨테이너 내부의 /config에서도 같은 표시 파일이 보이는지 확인하세요. 보이지 않으면 매핑을 수정하세요. 보인다면 데이터베이스와 인스턴스 식별을 계속 확인하세요.

오래된 파일 복사본과 외부 데이터베이스 구분

이전 경로와 새 경로에서 수정 시간을 비교하고, 자동화 이름, 대시보드 변경 사항, 헬퍼 또는 최근 백업처럼 고유한 구성 정보 몇 가지를 비교하세요. 새 디렉터리가 단순히 오래된 복사본이라면 Home Assistant가 실행 중일 때 파일을 선택적으로 병합하지 마세요. 신뢰할 수 있는 데이터 세트를 선택하고, 중지된 일관된 상태에서 전체 단위로 복사하세요.

Recorder 데이터베이스 URL을 확인하세요. /config를 이동해도 외부 MariaDB 또는 PostgreSQL 데이터베이스는 이동하지 않으며, 복원된 구성은 여전히 이전 데이터베이스를 가리킬 수 있습니다. 현재 엔터티는 올바르게 보이지만 기록이 오래되었다면, 전체 구성 불일치보다 데이터베이스 문제일 가능성이 높습니다.

스택 재생성 후 영구 데이터에 관한 ZimaSpace 문서에서는 인접한 실패 모드를 설명합니다. 빈 마운트는 데이터 손실처럼 보일 수 있고, 오래된 마운트는 데이터가 과거 상태로 되돌아간 것처럼 보일 수 있습니다.

중복 인스턴스와 클라이언트 전용 캐시 배제

브라우저 URL, 서버 이름, IP 주소, 인스턴스 ID 및 인증서가 의도한 Home Assistant 호스트에 속하는지 확인하세요. 마이그레이션 중에는 오래된 DNS 레코드, 역방향 프록시 대상, 모바일 앱의 서버 항목 또는 전원이 켜진 이전 호스트 때문에 클라이언트마다 서로 다른 인스턴스로 연결될 수 있습니다.

비공개 브라우저 세션과 두 번째 클라이언트에서 동일한 엔터티와 기록 타임스탬프를 비교하세요. 한 클라이언트만 오래된 상태이고 서버 로그와 다른 클라이언트에는 최신 상태가 보인다면, 스토리지를 다시 변경하지 말고 해당 클라이언트의 연결 또는 캐시된 프런트엔드 데이터를 지우세요.

클라이언트가 이전 상태와 새 상태를 번갈아 표시한다면 이전 인스턴스를 중지하고 DNS, 프록시 또는 로드 밸런서 대상을 수정하세요. 식별 문제를 진단하는 동안 두 컨트롤러가 동일한 장치에 대해 자동화를 실행하도록 두지 마세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

하나의 매핑을 수정하고 롤백 복사본 보존

Home Assistant를 중지하고 두 후보 경로를 모두 스냅샷하거나 복사한 뒤 호스트, 날짜 및 알려진 상태를 표시하세요. 권위 있는 /config와 데이터베이스를 서로 일치하는 복구 세트로 선택하세요. 확인된 불일치의 원인이 된 컨테이너 매핑 또는 데이터베이스 URL만 수정하세요.

시작하기 전에 소유권과 쓰기 권한을 확인하세요. 컨테이너가 선택한 경로를 읽을 수는 있지만 쓸 수 없다면 처음에는 올바르게 보이더라도 새 상태를 저장하지 못할 수 있습니다. 서비스 ID와 예상 소유권을 확인하지 않은 채 광범위한 재귀 권한 변경을 사용하지 마세요.

Home Assistant를 한 번 시작하고 추가로 편집하기 전에 로그를 확인하세요. 예상한 엔터티, 대시보드, 기록 및 최근 변경 사항이 나타나면 영속성 테스트를 계속하세요. 그렇지 않다면 두 데이터 트리를 결합하지 말고 중지한 후 표시해 둔 복사본으로 롤백하세요.

재생성과 재시작 후에도 올바른 데이터가 유지되는지 확인

임시 헬퍼를 만들거나 테스트 자동화의 이름을 바꾸는 것처럼 되돌릴 수 있는 테스트 변경을 하나 수행하세요. Home Assistant를 재시작한 후 변경 사항이 유지되는지 확인하세요. 그런 다음 저장된 배포 구성에서 컨테이너를 다시 만들고 다시 확인하세요.

통과한 결과는 동일한 인스턴스 식별 정보, 예상한 기록, 최신 레지스트리, 올바른 마운트 소스, 정상적인 쓰기 작업 및 중복 컨트롤러가 없음을 보여 줍니다. 새 백업에 선택한 상태가 포함되는지 확인하고 두 마이그레이션 경로와 분리된 곳에 보관하세요.

클라이언트에 따라 데이터가 달라지거나, 기록이 실시간 상태와 다른 데이터베이스에서 제공되거나, 재부팅 후 올바른 경로가 읽기 전용이 된다면 추가 지원을 요청하세요. 마운트 검사 결과, 데이터베이스 URL, 타임스탬프, 로그 및 손대지 않은 롤백 복사본 두 개를 보존하여 다음 단계에서 남은 원인을 정확히 조사할 수 있도록 하세요.