업그레이드 중 Home Assistant 구성 손실을 방지하는 방법

기본 제공 백업 시스템을 주요 복구 경로로 사용하고 런타임은 교체 가능한 것으로 취급하여 Home Assistant 구성 손실을 방지하세요. Home Assistant 버전, 컨테이너 이미지 또는 호스트는 변경될 수 있지만, 원래 장비를 사용할 수 없게 되었을 때 백업, 암호화 키, 런타임 정의 및 모든 외부 종속 항목을 계속 사용할 수 있어야 합니다.

최신 Home Assistant 백업은 Container를 포함한 다양한 설치 유형에서 작동합니다. 필요하다면 구성 트리의 별도 수동 복사본을 유지하되, 지원되는 백업 및 복원 절차를 무시한 채 파일을 직접 복사하는 방식만으로 전체 업그레이드 계획을 세우지는 마세요.

직접 복사한 YAML 폴더가 아니라 기본 제공 백업으로 시작하세요

“구성”을 configuration.yaml로만 한정하지 마세요. Home Assistant의 지원되는 백업 시스템은 구성 및 데이터베이스 내용을 포함하여 복구에 필요한 애플리케이션 상태를 저장하며, 최신 백업 절차는 자동화, 보존 정책 및 호스트 외부 위치도 지원합니다.

2025년에 도입된 백업 개편에는 자동 암호화 백업, 보존 정책 제어 및 오프사이트 백업 위치가 추가되었습니다. 따라서 불완전한 수동 복사본에 의존하기보다 업그레이드 전에 기본 제공 백업을 첫 번째 복구 자산으로 확인할 수 있습니다.

그래도 구성 루트, 데이터베이스 선택, 시크릿 참조, 사용자 지정 구성 요소, SSL 자료 및 통합에 필요한 외부 파일이나 서비스를 기록해 두세요. 백업으로 Home Assistant 상태를 복원할 수는 있지만, 주변의 모든 USB 장치, 네트워크 경로, 데이터베이스 호스트 또는 컨테이너 매개변수가 자동으로 문서화되는 것은 아닙니다.

Container 영구 저장소와 런타임 설정을 명확하게 유지하세요

Docker에서는 /config를 소유하는 바인드 마운트 또는 볼륨을 확인하고, 네트워크 모드, 장치 매핑, 시간대, 권한 및 외부 서비스를 다시 생성할 수 있는 Compose 또는 실행 정의를 보존하세요. 컨테이너 파일 시스템 자체는 폐기 가능한 상태로 유지해야 합니다.

Home Assistant Docker 백업 관련 논의에서는 실패 원인이 명확히 드러납니다. 사용자가 전체 구성 디렉터리가 아니라 파일 하나만 매핑하면, 중요한 상태가 컨테이너 내부에 갇힌 채 런타임을 교체할 때 사라질 수 있습니다.

업그레이드 전에 호스트 마운트를 확인하고 런타임 정의를 백업과 함께 보관하세요. 라디오, 포트, 네트워크 및 저장소를 노출하는 방법을 이미 알고 있다면 애플리케이션 상태와 복구 지침을 함께 사용하여 훨씬 빠르게 복구할 수 있습니다.

암호화된 백업을 최소 하나는 호스트 외부로 옮기세요

같은 SSD에 있는 백업은 일부 구성 실수에는 대비할 수 있지만, 호스트 손실, 파일 시스템 손상, 도난 또는 저장 장치 고장에는 대비하지 못합니다. Home Assistant 호스트가 고장 나도 접근할 수 있는 NAS, 다른 컴퓨터 또는 원격 백업 위치에 복구용 사본을 하나 이상 보관하세요.

백업 암호화 키 또는 비상 복구 키트도 Home Assistant 외부에 보관하세요. Home Assistant 2026.4에서는 새 암호화 백업이 감사를 거친 SecureTar v3 형식과 더 강력한 최신 암호화로 변경되었습니다. 이는 백업 보안을 강화하지만 키 보관을 복구 가능성의 명시적인 요소로 만듭니다.

같은 파일을 덮어쓰지 말고 백업 버전을 관리하세요. 업그레이드 후 며칠이 지나서야 문제가 드러날 수 있으며, 최신 복구 지점에는 이미 벗어나고 싶은 마이그레이션 상태나 손상된 상태가 포함되어 있을 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

백업만으로는 런타임 정의를 대체할 수 없습니다

구성만으로는 USB 라디오, 호스트 네트워킹, 시간대, 장치 패스스루, 데이터베이스 서비스, MQTT 또는 리버스 프록시 관계를 복원하지 못할 수 있습니다. 런타임을 다시 생성하는 데 필요한 Compose 파일, 이미지 버전 정책, 환경 변수, 호스트 경로, 장치 매핑 및 서비스 종속 항목을 보존하세요.

Compose 파일을 버전 관리한다는 이유만으로 평문 시크릿을 공개 저장소에 넣지 마세요. 시크릿 값은 보호된 위치에 보관하고, 복구 절차에서 해당 값을 어디서 가져오는지만 문서화하세요.

ZimaSpace의 ZimaBoard용 Home Assistant 배포 가이드는 홈 서버 플랫폼과 향후 배포 변경에도 유지해야 하는 애플리케이션 상태를 분리하는 데 유용한 참고 자료입니다.

업그레이드가 긴급 상황이 되기 전에 복원 테스트를 실행하세요

아카이브가 존재한다고 해서 백업이 검증된 것은 아닙니다. 격리된 대상 또는 임시 컨테이너에 복원하고, 가능한 경우 대표적인 장치와 경로를 다시 연결한 다음 사용자, 대시보드, 통합, 자동화, 도우미 및 예상 상태가 함께 복원되는지 확인하세요.

운영 시스템이 아직 정상적으로 작동할 때 테스트를 통해 누락된 비밀번호, 오래된 호스트 경로, 문서화되지 않은 장치 매핑 및 지나치게 큰 데이터베이스를 발견하세요. 테스트가 성공한 뒤 복원 절차를 기록하세요. 기억에 의존하는 것은 복구 계획이 아닙니다.

업그레이드 직전에 새 복구 지점을 만들고 현재 Home Assistant 버전과 컨테이너 이미지를 기록하며, 통합에 영향을 미치는 릴리스 변경 사항을 확인하세요. 업그레이드된 인스턴스가 정상 사용 기간과 재시작을 모두 견딜 때까지 이전 런타임을 유지하세요.

네 가지 업그레이드 안전 점검을 사용하세요

네 가지를 모두 확보했을 때만 업그레이드하세요. 수동 구성 트리 복사본을 추가 보호 계층으로 유지할 수는 있지만, 주요 복구 계획은 문서화된 런타임과 함께 복호화하고 복원할 수 있는 지원되는 백업이어야 합니다.