먼저 장애가 발생해도 보존해야 하는 것, 자동으로 재생성할 수 있는 것, Home Assistant 호스트 외부에 있어야 하는 것을 구분하여 Home Assistant 앱 데이터, 캐시, 백업을 분리하세요. 영구 구성과 데이터베이스 상태에는 안정적인 스토리지와 백업이 필요합니다. 폐기 가능한 캐시나 임시 파일에는 동일한 보존 규칙을 적용해서는 안 되며, 백업은 복구 대상 디스크에 의존해서도 안 됩니다.
가장 안전한 레이아웃은 폴더 이름이 아니라 역할을 기준으로 구성하는 것입니다. 디렉터리가 빠르게 커진다는 이유만으로 “캐시 스토리지”로 옮기지 마세요. 해당 데이터를 폐기 가능한 것으로 처리하기 전에 Home Assistant 또는 보조 서비스가 기록, 식별 정보, 페어링, 자격 증명 또는 복구를 위해 그 데이터를 필요로 하는지 확인하세요.
데이터를 원본 데이터, 재생성 가능 데이터, 복구 사본으로 분류하기
원본 데이터에는 Home Assistant 구성, 시크릿, 통합 구성 상태, 자동화 정의, 그리고 보존하려는 데이터베이스나 기타 상태가 포함됩니다. 재생성 가능 데이터에는 서비스가 가정의 구성 정보를 잃지 않고 다시 만들 수 있는 다운로드된 이미지, 임시 파일, 패키지 캐시, 트랜스코딩 파일, 인덱스가 포함됩니다. 복구 사본은 장애 후 원본 상태를 다시 구축하기 위한 백업과 내보내기 파일입니다.
이 분류는 서비스별로 수행해야 합니다. Home Assistant, MQTT, 데이터베이스, 리버스 프록시, Zigbee2MQTT는 각각 서로 다른 영구 상태를 가질 수 있습니다. 관리 인터페이스가 스택 정의를 기억하더라도 실제 워크로드 데이터까지 포함하는 것은 아닐 수 있습니다. 컨테이너 관리 백업에 워크로드 상태가 빠질 수 있는 이유는 “Docker를 백업했다”는 말이 생각보다 훨씬 적은 것을 의미할 수 있는 이유를 보여 줍니다.
안정적인 스토리지에 Home Assistant 구성과 활성 데이터베이스 보관하기
컨테이너 배포 환경에서는 Home Assistant 구성 경로가 컨테이너 이미지와 독립적으로 유지되어야 합니다. Recorder 데이터베이스가 해당 구성 트리 안에 있다면 이는 캐시가 아니라 활성 애플리케이션 상태입니다. 이 상태는 일반적인 데이터베이스 작업과 복구 작업을 수행할 수 있도록 충분한 여유 공간이 있는 안정적인 SSD 또는 기타 지연 시간이 낮은 스토리지에 저장하세요.
특히 많은 엔터티가 자주 변경되면 Recorder 활동으로 인해 작은 쓰기가 지속적으로 발생할 수 있습니다. Home Assistant 커뮤니티의 장기 토론인 Recorder 보존 기간이 데이터베이스 증가에 미치는 영향은 전체 구성 트리를 임시 스토리지로 옮겨 데이터베이스 변동을 숨기는 대신 불필요한 기록을 줄이는 데 초점을 맞추고 있어 유용합니다.
확인된 폐기 가능 캐시와 임시 작업만 옮기기
캐시와 임시 스토리지는 별도의 고속 임시 작업 장치, 용량을 제한한 메모리 기반 파일 시스템 또는 정리 규칙이 적용된 전용 디렉터리에 둘 수 있습니다. 단, 손실되어도 문제가 없을 때만 가능합니다. 테스트 사본을 삭제한 후 관련 서비스를 다시 시작하고 필요한 데이터를 재구성하는지 확인하세요. 서비스에서 페어링, 기록, 사용자, 자격 증명 또는 구성을 잃는다면 해당 데이터는 폐기 가능한 데이터가 아닙니다.
변경이 많은 데이터를 분리하면 쓰기를 줄이고 백업 크기를 작게 만들 수 있지만, 필수 파일을 마운트 아래에 숨기거나 숨겨진 RAM 의존성을 만들어서는 안 됩니다. ZimaSpace의 Home Assistant 캐시와 임시 스토리지 분리는 마운트를 변경하기 전에 재생성 가능한 데이터를 식별하는 데 초점을 맞춘 방법을 제공합니다.
서로 다른 장애 영역에 백업 저장하기
실시간 구성과 같은 위치에 저장된 백업은 잘못된 편집으로부터는 보호하지만 SSD 고장, 호스트 도난, 파일 시스템 손상 또는 스토리지 컨트롤러 고장으로부터는 보호하지 못합니다. 견뎌내고 싶은 장애에 따라 Home Assistant 백업을 NAS, 다른 서버, 이동식 스토리지 또는 오프사이트 대상에 복사하세요. Home Assistant 자체가 중단되어도 복구 키나 자격 증명에 접근할 수 있는 위치에 보관하세요.
백업은 내부적으로 일관된 상태여야 합니다. 볼륨 아카이브가 유용하지만, 상태를 저장하는 서비스에는 조정된 덤프, 스냅샷 또는 서비스 중지 후 복사본이 필요할 수 있습니다. 독립적인 영구 볼륨 백업 및 복원 방식은 이식성 문제를 설명하며, 백업을 사용할 수 있음을 입증하는 복원 테스트는 실제로 유용한 상태를 복구할 수 있을 때까지 백업 작업이 검증된 것이 아니라는 점을 강조합니다.
삭제, 재부팅, 복원 훈련으로 레이아웃 테스트하기
경로를 분리한 후에는 각 역할에 맞게 테스트하세요. 폐기 가능한 캐시를 비우고 다시 생성되는지 확인합니다. Home Assistant 컨테이너를 재생성하고 영구 구성이 유지되는지 확인합니다. 호스트를 재부팅하고 종속 서비스가 시작되기 전에 마운트가 나타나는지 확인합니다. 최근 백업을 임시 대상으로 복원하고 사용자, 자동화, 통합, 대표적인 기록 또는 보조 서비스 상태를 확인합니다.
그런 다음 소유권과 권한을 문서화하세요. 디스크에서 경로가 완벽하게 분리되어 있어도 새 컨테이너의 UID/GID가 해당 경로를 읽지 못하면 마이그레이션 후 문제가 발생할 수 있습니다. 마운트 지점, 파일 시스템 소유권, 백업 포함 여부, 보존 기간, 각 디렉터리를 삭제할 수 있는 서비스를 기록하세요.
| 데이터 역할 | 일반적인 스토리지 | 복구 규칙 |
|---|---|---|
| Home Assistant 구성/데이터베이스 | 안정적인 SSD/앱 데이터 풀 | 영구 보관 및 백업 |
| 폐기 가능한 캐시/임시 파일 | 임시 작업용 SSD 또는 용량이 제한된 임시 스토리지 | 안전하게 재생성되어야 함 |
| 백업 | 별도 호스트/미디어/오프사이트 대상 | 복원 테스트 완료 |
| 대용량 아카이브 | 용량 중심 스토리지 | 가치에 따라 보호 |
캐시를 삭제해도 Home Assistant가 손상되지 않고, 컨테이너를 재생성해도 앱 상태가 지워지지 않으며, 기본 앱 데이터 장치를 잃어도 유일한 복구 사본까지 사라지지 않는다면 분리가 성공한 것입니다. 스토리지 역할은 장애가 발생하기 전에 장애 시 동작을 명확하게 보여 줘야 합니다.
NAS 및 서버 설정
더 읽어보기

원격 사용자와 로컬 사용자에 맞게 홈 어시스턴트 설정을 조정하는 방법
로컬 Home Assistant 제어를 원격 엣지와 독립적으로 유지한 다음, 예측 가능한 DNS, ID 및 네트워크 전환 동작을 통해 안전한 원격 액세스를 추가하세요.

단일 컨테이너에서 복원력 있는 서비스 스택으로 Home Assistant를 이전하는 방법
먼저 작동 상태를 보존한 다음, 데이터·종속성·상태·리소스·복구를 분리하여 하나의 서비스 장애가 Home Assistant 전체를 중단시키지 않도록 하세요.

새로운 Home Assistant 기능이 홈 서버 아키텍처를 바꾸는 방식
새로운 Home Assistant 기능은 서비스, 네트워크, 데이터, 복구 역할을 변화시킵니다. 핵심 제어를 보호한 다음, 측정된 필요에 따라 각 기능을 통합하거나 격리하세요.

