Home Assistant 앱 데이터, 캐시 및 백업을 분리하는 방법

에바 왕기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

먼저 장애가 발생해도 보존해야 하는 것, 자동으로 재생성할 수 있는 것, 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 및 서버 설정

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.