Home Assistant 캐시를 구성하려면 먼저 어떤 데이터가 폐기 가능한지 식별하세요. 전체 영구 구성 경로를 임시 저장소로 옮겨서는 안 됩니다.
“캐시”는 브라우저 프런트엔드 자산, TTS 출력, 통합별 임시 파일, 컨테이너의 /tmp, 운영 체제 페이지 캐시 또는 데이터베이스 작업 공간을 의미할 수 있습니다. 이러한 계층은 소유 주체와 복구 방식이 서로 다릅니다. 사용자, 레지스트리, 구성, Recorder 상태 및 기타 권위 있는 파일은 내구성 있는 저장소에 보관하세요. 손실과 메모리 사용량을 재시작을 통해 테스트하고 문서화한 폐기 가능 경로에만 tmpfs 또는 RAM 기반 저장소를 사용하세요.
경로를 옮기기 전에 캐시를 분류하세요
소유 주체, 경로, 예상 최대 크기, 재생성 방법, 데이터가 사라졌을 때의 결과를 먼저 명확히 정의하세요. 브라우저 캐시는 클라이언트에 있고, Home Assistant 영구 애플리케이션 상태는 구성된 데이터 경로 아래에 있으며, 통합 캐시는 통합마다 다릅니다. 임시 컨테이너 파일은 재시작 시 사라질 수 있습니다. 이러한 문제를 하나의 전역 “캐시 디렉터리” 설정으로 해결해서는 안 됩니다.
Home Assistant TTS 사례는 특정 캐시 경로 아래에서 생성된 오디오를 의도적으로 RAM 기반 위치로 리디렉션한 좁은 예를 보여 줍니다. 폐기 가능한 TTS 캐시를 이동하는 것에서 중요한 경계는 사용자가 재생성 가능한 디렉터리 하나를 대상으로 했다는 점이지, 전체 구성 트리를 대상으로 한 것이 아니라는 점입니다.
파일이 사라져도 식별 정보, 기록, 설정, 대시보드 또는 통합 등록 정보가 손실되지 않는다는 것을 입증할 수 없다면 해당 파일을 영구 데이터로 분류하세요. 가장 안전한 기본값은 내구성 있는 저장소입니다. 최적화는 복구 책임이 확인된 후에 진행해야 합니다.
영구 Home Assistant 상태와 Recorder를 내구성 있는 저장소에 보관하세요
구성 마운트에 생성된 파일이 일부 들어 있다고 해서 캐시가 되는 것은 아닙니다. 이 경로에는 인증 정보, 엔터티 및 장치 레지스트리, 자동화 상태, 구성, 사용자 지정 구성 요소와 기본 Recorder 데이터베이스가 포함될 수 있습니다. 전체 경로를 tmpfs에 두면 재부팅이 데이터 손실로 이어지고, 원래 권위 있는 데이터로 사용하도록 설계되지 않은 메모리 내용을 백업의 기준으로 삼게 됩니다.
ZimaSpace의 Home Assistant 영구 데이터 역할 설명은 올바른 첫 번째 필터입니다. 저장소 계층을 지정하기 전에 권위 있는 상태, 재생성 가능한 캐시, 임시 작업 데이터를 분리하세요.
앱 상태에는 SSD 또는 신뢰할 수 있는 다른 내구성 파일 시스템을 사용하고, 데이터베이스 증가, 업그레이드 및 유지 관리에 필요한 충분한 여유 공간을 확보하세요. 폐기 가능한 작은 캐시를 RAM으로 옮겨도 영구 볼륨의 용량 부족이나 장애 문제를 해결할 수는 없습니다.
메모리 제한이 있는 명시적인 폐기 가능 경로에만 tmpfs를 사용하세요
tmpfs는 쓰기를 줄이고 매우 낮은 지연 시간을 제공할 수 있지만 호스트 RAM을 사용하며 컨테이너나 호스트가 중지되면 데이터가 사라집니다. 따라서 재시작 후에도 필요한 데이터가 아니라, 크기가 제한된 임시 작업 데이터에 적합합니다. 또한 임시 작업이 Home Assistant Core와 인접 서비스에 필요한 메모리를 소모하지 않도록 마운트 크기를 설정해야 합니다.
최신 Docker Compose 가이드는 tmpfs 사용량이 메모리 용량에 포함된다고 설명하며, 컨테이너 예산에 비해 크기가 지나치게 크거나 제한되지 않으면 공간 부족 또는 OOM 조건으로 실패할 수 있다고 안내합니다.
크기 상한을 설정하고 최대 사용량을 모니터링한 뒤 컨테이너를 의도적으로 재시작하세요. 해당 경로가 자동으로 다시 채워지는 동시에 사용자, 설정, 기록 및 통합은 변경되지 않아야 합니다. 애플리케이션이 디렉터리를 재생성하지 못하거나 디렉터리 부재를 손상으로 처리한다면 해당 경로를 내구성 있는 저장소로 되돌리세요.
프런트엔드 캐시는 서버 저장소가 아니라 클라이언트 문제로 다루세요
서버가 정상이어도 한 브라우저에서 오래된 Home Assistant 페이지가 계속 표시될 수 있습니다. 프런트엔드 리소스가 브라우저나 앱에 캐시되기 때문입니다. 서버 측 임시 파일을 삭제해도 이러한 클라이언트 상태는 해결되지 않습니다. 반대로 브라우저 캐시를 삭제해도 Recorder 디스크 I/O가 줄거나 Home Assistant 데이터베이스 크기가 작아지지는 않습니다.
Home Assistant 사용자는 프런트엔드 캐시를 브라우저 캐시로 명확히 구분합니다. 따라서 캐시 문제를 해결할 때는 먼저 증상이 한 클라이언트에만 있는지, 전체 서버에 걸쳐 나타나는지 확인해야 합니다.
검증 기준으로 새 브라우저나 비공개 프로필을 사용하세요. 새 클라이언트가 정상이라면 수정은 프런트엔드 경로에만 적용하세요. 모든 클라이언트에서 동일한 데이터 누락이나 서버 측 오류가 나타난다면 로컬 캐시를 계속 삭제하지 말고 Home Assistant 로그, 저장소, 통합 또는 데이터베이스 문제를 다시 점검하세요.
재시작, 부하 및 여유 공간 테스트로 임시 저장소를 검증하세요
캐시 또는 tmpfs 경로를 변경한 후 정상 및 최대 크기, 호스트 사용 가능 메모리, 컨테이너 메모리 압박, 영구 볼륨의 여유 공간과 재시작 동작을 측정하세요. 그런 다음 캐시를 생성하는 작업인 TTS, 미디어, 사용자 지정 통합 처리 또는 기타 알려진 생성 작업을 실행하고 정리가 예상대로 이루어지는지 확인하세요.
일상적인 데이터베이스 용량이 충분하더라도 임시 작업 공간이 필요한 작업을 위해 내구성 있는 저장소에 여유 공간을 남겨 두세요. RAM 캐시 덕분에 일반적인 쓰기량이 줄어든 것처럼 보여도 영구 볼륨을 가득 채우지 마세요. 업그레이드, 데이터베이스 유지 관리, 백업 및 로그 급증에는 매우 다른 임시 공간 요구 사항이 있을 수 있습니다.
모든 폐기 가능한 경로가 사라진 후 재생성되고, 컨테이너와 호스트를 재시작해도 영구 상태가 유지되며, tmpfs 최대 사용량이 메모리 예산 내에 머물고, Home Assistant에 충분한 내구성 저장소 여유 공간이 남아 있으면 테스트를 통과한 것입니다. 테스트 후 필요한 설정이나 기록이 사라진다면 해당 경로를 잘못 분류한 것이므로 추가 조정에 앞서 영구 저장소로 되돌려야 합니다.
지원 및 팁
더 읽어보기

Home Assistant가 다른 컨테이너와 GPU 또는 가속기를 공유할 수 있나요?
GPU 공유는 워크로드에 따라 달라집니다. 컨테이너는 대개 렌더 노드를 공유할 수 있지만, 전체 디바이스를 VM에 패스스루하면 일반적으로 경계가 달라집니다.

Home Assistant 오류가 클라이언트에서 발생했는지 서버에서 발생했는지 확인하는 방법
단일 클라이언트에서만 발생하는 오류는 클라이언트 상태를, 여러 클라이언트에서 발생하는 오류는 서버나 공유 프록시, 네트워크 또는 통합 경로를 가리킵니다.

Home Assistant 백업에서 일관되지 않은 데이터베이스 상태가 캡처되지 않도록 하는 방법
운영 중인 시스템에는 Home Assistant를 인식하는 백업을 사용하세요. 원시 파일을 복사하는 경우에는 데이터베이스를 일시 정지하고 복원을 확인한 후에야 해당 아카이브를 신뢰하세요.

