Home Assistant 영구 데이터 역할이란 무엇이며, 왜 중요한가요?

Home Assistant 영속 데이터는 하나의 구분 없는 “구성”으로 취급하기보다 역할별로 나누면 운영이 더 쉬워집니다. 일부 상태는 스마트 홈의 정체성과 동작을 정의하고, 일부는 과거 관측 데이터를 저장하며, 일부는 자격 증명을 포함하고, 일부는 Home Assistant를 중심으로 런타임을 재구축할 때만 필요합니다.

이러한 역할이 중요한 이유는 복구 가치가 서로 다르기 때문입니다. 한 달치 기록을 잃는 것과 엔터티 레지스트리를 잃는 것은 같지 않으며, Docker 이미지를 다시 만드는 것과 장치 매핑, 보안 정보 또는 가정의 자동화를 구성하는 설정을 다시 만드는 것도 같지 않습니다.

구성 및 레지스트리 상태가 설치 환경을 정의합니다

영속 구성 트리에는 YAML, UI로 관리되는 저장소, 통합 구성, 대시보드, 헬퍼, 장치 및 엔터티 레지스트리, 사용자 지정 구성 요소와 기타 파일이 포함됩니다. 이러한 요소가 하나의 Home Assistant 인스턴스를 새로 설치한 환경과 다르게 만듭니다.

컨테이너 영속성은 쓰기 가능한 컨테이너 계층 외부에 상태를 저장하는 데 달려 있습니다. Docker의 현재 스토리지 지침은 볼륨과 바인드 마운트가 컨테이너 수명 주기와 독립적으로 애플리케이션 데이터를 유지한다고 설명합니다. 이미지는 다시 만들 수 있지만, 가정별 상태가 저절로 다시 나타난다고 가정해서는 안 됩니다.

이 역할에는 보수적인 백업, 통제된 마이그레이션, 그리고 검증된 복원 경로가 필요합니다. 캐시나 폐기 가능한 컨테이너 계층과 동일한 정리 정책을 적용해서는 안 됩니다.

Recorder 기록은 중요한 데이터지만 구성과는 다릅니다

Recorder는 기록, 로그북, 대시보드 및 분석에 사용되는 과거 상태, 이벤트, 통계를 저장합니다. 이 데이터는 특히 에너지 사용량, 환경 추세 또는 문제 해결에 중요할 수 있지만, Home Assistant는 원시 기록을 무제한으로 보관하지 않아도 현재 상태를 표현할 수 있습니다.

기록을 정체성과 분리하면 복구 결정이 달라집니다. Recorder 데이터베이스가 손상되었거나 지나치게 커진 경우, 정상적인 자동화와 통합 구성을 버리지 않고 기록만 복구하거나 복원하거나 새로 만들 수 있습니다.

과거 데이터에는 고유한 수명 주기가 필요합니다. 샘플링 빈도, 보존 기간, 롤업, 인덱스 및 백업 세대에 따라 저장 공간 증가는 자동화 규칙 수와 별개로 결정됩니다. 설치 환경을 정의하는 구성 및 레지스트리 상태와 이러한 보존 결정을 분리해 관리하세요.

보안 정보와 복구 키에는 서로 다른 장애 대응 조건이 있습니다

자격 증명, 토큰, 인증서, 암호화 키 및 백업 비상 복구 자료는 바이트 단위로는 작을 수 있지만 복구 가치는 높습니다. 복호화할 수 없는 백업이나 유효한 자격 증명이 없는 복원된 통합은 시스템을 부분적으로 사용할 수 없는 상태로 만들 수 있습니다.

Home Assistant 백업 전략은 서로 다른 미디어와 오프사이트 위치에 암호화된 복구 사본을 보관할 것을 명시적으로 권장합니다. 하지만 호스트를 잃은 뒤에도 백업 복원에 필요한 키를 사용할 수 있어야만 이 보호가 효과를 발휘합니다.

구성을 버전 관리한다는 이유만으로 모든 보안 정보를 공개 Git 저장소에 넣지 마세요. 보안 정보는 보호된 메커니즘을 통해 저장하고, 복구 시 어디에서 가져오는지 문서화하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

런타임 정의는 상태를 둘러싼 환경을 다시 만듭니다

교체한 호스트가 원래 배포 환경에서 요구하던 USB 무선 장치 매핑, 네트워크 모드, 포트, 호스트 경로, 데이터베이스 서비스, MQTT 브로커, 환경 변수, 시간대 또는 권한을 재현하지 못하면 복원된 구성 트리도 제대로 작동하지 않을 수 있습니다.

Home Assistant Container 지침은 업데이트와 영속 상태를 분리하며, 알려진 Docker 매개변수를 사용해 런타임을 다시 만든다고 가정합니다. 현재의 Container 워크플로는 백업과 이미지 교체를 별개의 작업으로 유지하며, 이는 복구 계획에서도 유지해야 할 동일한 분리 원칙입니다.

외부 서비스에 대한 문서와 함께 Compose 파일 또는 이에 준하는 배포 정의를 보관하세요. 런타임 구성은 Home Assistant 데이터베이스가 아니지만, 작동하는 서비스를 재현하는 데 필요한 일부입니다.

백업은 또 하나의 실시간 데이터 역할이 아니라 복구 사본입니다

백업은 복구하려는 장애를 견딜 수 있어야 합니다. 모든 백업이 활성 구성과 Recorder 데이터베이스가 있는 동일한 시스템 SSD에 저장되어 있다면, 하나의 스토리지 장애로 세 역할을 한꺼번에 잃을 수 있습니다.

복구 사본은 Home Assistant 호스트의 손실도 견딜 수 있어야 합니다. 3-2-1 백업 모델은 서로 다른 미디어에 여러 사본을 보관하고 최소 한 사본을 오프사이트에 유지합니다. 암호화된 Home Assistant 백업의 경우에도 비상 복구 키트 또는 해당 키를 장애가 발생한 시스템 외부에 보관해야 합니다.

• 구성 및 레지스트리: 정체성과 자동화 동작을 정의하므로 복원하거나 신중하게 복구합니다.
• Recorder 및 통계: 기록 계층만 손상된 경우 독립적으로 복구, 복원 또는 재구축합니다.
• 보안 정보 및 키: 장애가 발생한 호스트 외부의 보호된 저장소에서 복구합니다.
• 런타임 정의: 마운트, 장치, 네트워크 및 서비스 종속성을 다시 구성합니다.
• 백업: 실시간 장애 범위 외부에 복구 사본을 보관합니다.

ZimaSpace의 Home Assistant 배포 예시는 이러한 분리를 이해하는 데 유용한 참고 자료입니다. 서버 플랫폼은 바뀔 수 있지만 애플리케이션 상태와 복구 책임은 논리적으로 서로 구분된 채 유지될 수 있습니다.

영속 데이터의 역할을 구분하면 장애가 발생한 가장 작은 계층만 복구할 수 있습니다. 데이터베이스 문제 때문에 새로 설치할 필요는 없으며, 컨테이너 업데이트가 구성 손실로 이어질 필요도 없습니다.