동일한 영구 /config 데이터를 다시 마운트한다면 Home Assistant Docker 또는 Compose 스택을 재생성해도 구성이 삭제되지 않아야 합니다. 재생성 후 온보딩 화면이 나타나거나 통합이 누락된 것처럼 보인다면, 첫 번째로 의심할 것은 Home Assistant가 가정의 상태를 삭제했다는 사실이 아니라 새 컨테이너가 다른 스토리지 뷰를 보고 있다는 점입니다.
이전 백업을 복원하기 전에 실제 마운트, 호스트 경로, 이름이 지정된 볼륨, 숨김 파일, 권한을 확인하세요. 비어 있거나 잘못된 디렉터리는 구성 손실처럼 보일 수 있지만, 원본 데이터는 호스트의 다른 위치에 그대로 남아 있을 수 있습니다.
/config에 실제로 마운트된 항목 확인
실행 중인 컨테이너를 검사하고 /config에 매핑된 마운트 소스를 확인하세요. 익숙해 보이는 폴더 이름에 의존하지 말고 이전 Compose 파일 또는 배포 기록과 비교하세요.
Docker 바인드 마운트는 대상 디렉터리에 대한 컨테이너의 뷰를 대체하며, 현재 바인드 마운트 문서에서도 비어 있지 않은 컨테이너 경로에 호스트 디렉터리를 마운트하면 기존 파일이 가려진다고 설명합니다. 따라서 비어 있거나 잘못된 소스 경로가 지정되면 Home Assistant는 비어 있는 /config를 보게 됩니다.
마운트가 올바른 것으로 확인될 때까지 온보딩을 진행하거나 새 통합을 만들지 마세요. 잘못된 디렉터리에 새 데이터가 기록되면 나중에 복구가 더 복잡해집니다.
바인드 마운트와 이름이 지정된 볼륨 구분
Compose 스택은 명시적인 호스트 경로 또는 Docker가 관리하는 이름이 지정된 볼륨을 사용할 수 있습니다. 프로젝트 이름, 볼륨 이름 또는 경로를 변경해 프로젝트를 재생성하면 새롭고 비어 있는 영구 저장소가 만들어지는 동안 이전 볼륨은 계속 남아 있을 수 있습니다.
현재 Docker 볼륨 가이드에서는 이름이 지정된 볼륨은 개별 컨테이너와 독립적으로 데이터를 저장하며 컨테이너를 교체한 후에도 다시 연결할 수 있다고 설명합니다. 따라서 컨테이너를 제거하는 것과 영구 저장소를 제거하거나 교체하는 것은 서로 다릅니다.
이전 볼륨과 새 볼륨을 나열하고 Docker를 통해 마운트 지점을 검사한 다음 생성 시간과 내용을 비교하세요. 어떤 볼륨에 신뢰할 수 있는 Home Assistant 상태가 들어 있는지 확인하기 전에는 정리 명령을 실행하지 마세요.
숨김 파일 때문에 복사본이 완전해 보일 수 있음
Home Assistant는 .storage와 같은 숨김 경로에 중요한 UI 관리 상태를 저장합니다. *와 같은 글로브를 사용한 셸 복사나 숨김 파일을 표시하지 않는 파일 관리자는 YAML 파일만 옮기고 중요한 레지스트리 및 통합 상태는 조용히 남겨 둘 수 있습니다.
2025년에 Docker에서 Compose로 마이그레이션한 사례에서도 정확히 같은 문제가 재현되었습니다. 복사 작업에서 숨겨진 Home Assistant 상태를 누락하거나 잘못 처리했으며, 전체 구성 트리와 메타데이터를 올바르게 복사한 후에야 마이그레이션이 안정화되었습니다.
숨김 파일을 포함한 디렉터리 목록을 비교하고, 데이터 자체가 손상되었다고 결론 내리기 전에 소유권, 타임스탬프, 예상되는 숨김 디렉터리의 존재 여부를 확인하세요.
데이터를 다시 복사하기 전에 권한 확인
재생성된 컨테이너에 해당 디렉터리를 읽거나 쓸 권한이 없으면 올바른 디렉터리도 사용할 수 없는 것처럼 보일 수 있습니다. 데이터를 새 파일 시스템으로 옮겼거나, Docker 모드를 변경했거나, 다른 호스트에서 복원했거나, UID/GID 매핑을 변경한 경우에 흔히 발생합니다.
2026년에 확인된 Docker Engine 문제 해결 가이드에서는 이러한 오류의 원인을 실제 호스트 경로, 컨테이너 UID/GID, 상위 디렉터리 액세스, 마운트 모드, 보안 경계로 좁힙니다. 파일이 보이더라도 읽기 전용 설정이나 소유권 불일치로 인해 Home Assistant가 상태를 업데이트하지 못할 수 있습니다.
구성 트리 전체에 모든 사용자의 쓰기 권한을 부여하지 말고, 정확한 소유권 또는 마운트 문제만 해결하세요.
영구 경로를 확인한 후에만 스택 재생성
검증된 Compose 정의, 이미지 태그, 네트워크 모드, 디바이스 설정, /config 소스를 그대로 사용하세요. Home Assistant를 시작한 뒤 예상한 사용자, 대시보드, 통합, 자동화, 헬퍼가 돌아오는지 확인한 다음에야 마이그레이션이나 새 구성 변경을 허용하세요.
ZimaSpace의 단일 컨테이너 복구 절차도 동일한 원칙을 적용합니다. 스택의 관련 없는 부분을 복원하거나 교체하기 전에 실제 마운트를 검사하고 정상적인 종속성을 다시 연결하세요.
신뢰할 수 있는 데이터가 실제로 사라졌다면 백업 복원으로 넘어가세요. 데이터가 존재하지만 새 컨테이너가 이를 보거나 수정하지 못한다면 문제는 Home Assistant 구성 자체가 아니라 스토리지 매핑 또는 권한 경계에 있습니다.
지원 및 팁
더 읽어보기

Home Assistant 데이터베이스에 유지 관리 또는 교체가 필요한 징후
대규모 Home Assistant 데이터베이스에는 일반적으로 보존 기간 관리 또는 정리 작업이 필요하지만, 반복되는 손상이나 무결성 오류는 교체를 고려해야 한다는 더 강력한 신호입니다.

Home Assistant는 느려지기 전에 동시에 몇 명의 사용자를 처리할 수 있나요?
Home Assistant에는 고정된 유용한 사용자 한도가 없습니다. 실제 대시보드와 엔터티 업데이트로 활성 클라이언트를 벤치마크한 다음, 반복적으로 지연 시간이 나타나기 전에 중단하세요.

Home Assistant는 업그레이드를 중단하지 않고 외부 데이터베이스를 사용할 수 있나요?
외부 Recorder 데이터베이스는 업그레이드 후에도 유지될 수 있지만, 자체적인 가용성, 스키마 마이그레이션, 백업, 복원 및 버전 관리 책임이 추가됩니다.

