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

먼저 장애 후에도 보존해야 하는 데이터, 자동으로 다시 만들 수 있는 데이터, Home Assistant 호스트 외부에 보관해야 하는 데이터를 정해 Home Assistant 앱 데이터, 캐시, 백업을 분리하세요. 영구 구성과 데이터베이스 상태에는 안정적인 저장소와 백업이 필요합니다. 폐기 가능한 캐시나 임시 파일에는 동일한 보존 규칙을 적용하지 마세요. 백업은 복구 대상인 디스크에 의존해서는 안 됩니다.

가장 안전한 저장소 구성은 폴더 이름이 아니라 역할을 기준으로 합니다. 빠르게 커진다는 이유만으로 디렉터리를 “캐시 저장소”로 옮기지 마세요. 데이터를 폐기 가능하다고 취급하기 전에 Home Assistant나 연동 서비스가 기록, 사용자 식별 정보, 페어링, 자격 증명 또는 복구를 위해 해당 데이터에 의존하는지 확인하세요.

데이터를 기본 데이터, 재생성 가능한 데이터, 복구 사본으로 분류

기본 데이터에는 Home Assistant 구성, 시크릿, 통합 상태, 자동화 정의, 그리고 보존하려는 데이터베이스나 기타 상태 데이터가 포함됩니다. 재생성 가능한 데이터에는 다운로드한 이미지, 임시 파일, 패키지 캐시, 트랜스코딩 파일, 그리고 가정 내 구성을 잃지 않고 서비스가 다시 만들 수 있는 인덱스가 포함됩니다. 복구 사본은 장애 발생 후 기본 상태를 복원하기 위한 백업과 내보내기 파일입니다.

이 분류는 서비스별로 해야 합니다. Home Assistant, MQTT, 데이터베이스, 리버스 프록시, Zigbee2MQTT는 각각 서로 다른 영구 상태 데이터를 가질 수 있습니다. 관리 인터페이스에는 스택 정의가 저장되어 있을 수 있지만, 그 자체로 워크로드 데이터까지 포함하는 것은 아닙니다. 컨테이너 관리 백업에 워크로드 상태가 누락될 수 있는 이유를 보여주는 사례는 “Docker를 백업했다”는 말이 기대보다 훨씬 적은 내용을 뜻할 수 있음을 잘 보여줍니다.

Home Assistant 구성과 활성 데이터베이스는 안정적인 저장소에 보관

컨테이너 배포에서는 Home Assistant 구성 경로가 컨테이너 이미지와 별도로 유지되어야 합니다. 레코더 데이터베이스가 구성 트리에 있다면 이는 캐시가 아니라 애플리케이션의 활성 상태 데이터입니다. 정상적인 데이터베이스 작업과 복구 작업을 감당할 만큼 여유 공간이 있는 안정적인 SSD나 기타 지연 시간이 낮은 저장소에 이 데이터를 두세요.

레코더는 지속적으로 소량의 쓰기 작업을 생성할 수 있으며, 특히 많은 엔터티가 자주 변경될 때 그렇습니다. Home Assistant 커뮤니티에서 오랫동안 이어져 온 레코더 보존 정책이 데이터베이스 증가에 미치는 영향에 관한 논의는 불필요한 기록을 줄이는 데 초점을 둡니다. 전체 구성 트리를 임시 저장소로 옮겨 데이터베이스의 잦은 쓰기를 감추는 방식이 아닙니다.

폐기해도 되는 것으로 확인된 캐시와 임시 작업만 옮기기

캐시와 임시 저장소는 별도의 고속 임시 저장 장치, 용량이 제한된 메모리 기반 파일 시스템 또는 정리 규칙이 적용된 전용 디렉터리에 둘 수 있습니다. 단, 데이터가 사라져도 문제가 없을 때만 해당합니다. 테스트 사본을 삭제한 뒤 관련 서비스를 다시 시작하고 필요한 데이터를 다시 생성하는지 확인하세요. 서비스가 페어링, 기록, 사용자, 자격 증명 또는 구성을 잃는다면 그 데이터는 폐기해도 되는 데이터가 아닙니다.

변동이 잦은 데이터를 분리하면 쓰기를 줄이고 백업 크기를 작게 만들 수 있지만, 마운트 아래에 필요한 파일을 가리거나 RAM에 대한 숨겨진 의존성을 만들어서는 안 됩니다. ZimaSpace의 Home Assistant 캐시 및 임시 저장소 분리는 마운트를 변경하기 전에 다시 생성할 수 있는 데이터를 식별하는 데 필요한 경로를 집중적으로 다룹니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

백업을 다른 장애 도메인에 저장하기

실시간 설정과 같은 위치에 저장된 백업은 잘못된 편집으로부터는 보호하지만 SSD 고장, 호스트 도난, 파일 시스템 손상 또는 스토리지 컨트롤러 고장으로부터는 보호하지 못합니다. 감당하고자 하는 장애에 맞춰 Home Assistant 백업을 NAS, 다른 서버, 이동식 저장 장치 또는 오프사이트 대상으로 복사하세요. Home Assistant 자체가 다운되어도 복구 키나 자격 증명에 접근할 수 있도록 별도의 위치에 보관하세요.

백업의 내부 일관성도 확보해야 합니다. 볼륨 아카이브도 유용하지만, 상태 저장형 서비스는 조정된 덤프, 스냅샷 또는 서비스 중지 상태에서 복사해야 할 수 있습니다. 영구 볼륨 백업 및 복원 패턴에서는 이식성 문제를 설명하고, 백업의 사용 가능성을 입증하는 복원 테스트에서는 백업에서 유용한 상태를 복구할 수 있을 때까지 백업 작업이 검증된 것이 아니라고 강조합니다.

삭제, 재부팅, 복원 훈련으로 레이아웃 테스트하기

경로를 분리한 뒤에는 각 역할이 보장하는 내용에 따라 테스트하세요. 폐기 가능한 캐시를 비우고 다시 생성되는지 확인하세요. Home Assistant 컨테이너를 다시 만들고 영구 설정이 유지되는지 확인하세요. 호스트를 재부팅하고 종속 서비스가 시작되기 전에 마운트가 나타나는지 확인하세요. 최근 백업을 임시 대상으로 복원하고 사용자, 자동화, 통합, 대표적인 기록 또는 연동 서비스 상태를 확인하세요.

그런 다음 소유권과 권한을 문서화하세요. 디스크에서 경로를 완벽하게 분리했더라도 새 컨테이너의 UID/GID로 해당 경로를 읽을 수 없다면 마이그레이션 후 문제가 발생할 수 있습니다. 마운트 지점, 파일 시스템 소유권, 백업 포함 여부, 보존 기간, 각 디렉터리를 삭제할 수 있는 서비스를 기록하세요.

캐시를 삭제해도 Home Assistant가 손상되지 않고, 컨테이너를 다시 만들어도 앱 상태가 지워지지 않으며, 기본 앱 데이터 장치를 잃어도 유일한 복구 사본이 사라지지 않을 때 분리가 제대로 된 것입니다. 장애가 발생하기 전에 저장소 역할만 보고도 장애 시 동작 방식을 명확히 알 수 있어야 합니다.