컨테이너로 복구 가능한 Home Assistant 배포 환경 구축하기

복구 가능한 Home Assistant 컨테이너 배포에서는 컨테이너 이미지를 언제든 폐기할 수 있는 것으로 보고, 상태, 구성, 비밀 정보, 장치 매핑, 네트워크 동작, 복원 절차를 실제 시스템으로 취급합니다.

목표는 단순히 Docker가 Home Assistant를 다시 시작하게 만드는 것이 아닙니다. 업데이트 실패, 디스크 손실 또는 호스트 교체 후 깨끗한 호스트에서 서비스를 재구축하고, 정해진 시간 안에 기존 사용자, 통합 구성 요소, 자동화, 라디오, 데이터베이스 상태 및 네트워크 ID를 동일하게 복구하는 것이 목표입니다.

영구 상태를 컨테이너 이미지 외부에 보관하기

전체 Home Assistant 구성 디렉터리를 영구 호스트 스토리지에 마운트하고, 숨김 디렉터리를 포함해 그 안의 모든 항목을 백업하세요. 커뮤니티 마이그레이션 사례에서는 표시되는 YAML 파일만 복사하고 UI에서 관리되는 엔터티, 통합 구성 요소 및 기타 상태가 저장된 .storage를 누락해 반복적으로 실패합니다. 한 컨테이너 마이그레이션 실패 사례는 셸 글로빙으로 인해 이러한 점 파일이 조용히 누락될 수 있음을 보여 줍니다.

Compose 파일, 환경 변수 템플릿, 시간대, 네트워크 모드, 장치 매핑, 바인드 마운트 경로 및 필요한 그룹 권한을 버전 관리되는 인프라 문서에 보관하세요. 재현 가능한 빌드와 별도의 복구 사본이 없는 한, 고유한 가정용 상태를 사용자 지정 이미지에 포함하지 마세요.

ZimaSpace의 완전한 Home Assistant 서버 토폴로지는 더 넓은 패턴을 제시합니다. 제어 경로를 작게 유지하고, 영구 상태를 대용량 스토리지와 분리하며, 서비스 의존성을 추가하기 전에 활성 장애 영역 외부에 복구 수단을 마련하세요.

단순히 자주가 아니라 일관된 상태로 백업하기

백업 파일이 일관된 특정 시점의 상태를 나타낼 때만 백업이 유용합니다. 간단한 로컬 SQLite 배포에서는 유지보수 시간에 영구 구성 볼륨을 중지하고 복사하는 방식이 이해하기 쉽습니다. 외부 데이터베이스를 사용하는 경우에는 데이터베이스 일관성을 보장하는 방식으로 데이터베이스를 백업하고, 어떤 Home Assistant 구성 백업과 함께 복원해야 하는지 기록하세요.

최근의 Docker 볼륨 백업 워크플로는 아카이브 명령이 성공했다고 해서 복구 가능한 것은 아니므로 사본을 실제로 복원해야 한다고 강조합니다. 장애가 발생한 SSD, 파일 시스템 또는 실수로 실행한 prune이 서비스와 백업을 모두 삭제하지 못하도록 최소 한 세대의 백업을 Docker 호스트 외부에 보관하세요.

백업 생성 시점, 애플리케이션 버전, 데이터베이스 버전, 크기, 체크섬, 암호화 키 위치 및 깨끗한 호스트에서의 복원 단계를 기록하세요. 복원 메타데이터가 없는 보존 정책은 복구 시스템이 아니라 아카이브 더미를 만들 뿐입니다.

Compose에서 의존성과 준비 상태를 모델링하기

Home Assistant가 MQTT, 외부 데이터베이스, 프록시 또는 다른 로컬 서비스에 의존할 때 컨테이너 시작 순서는 서비스 준비 상태와 같지 않습니다. 프로세스가 실행 중이어도 소켓, 스키마 또는 상태 확인 엔드포인트를 아직 사용할 수 없을 수 있습니다. Compose 준비 상태 가이드는 상태 확인과 의존성 조건이 시작 경합을 줄이는 방법을 보여 줍니다.

각 의존성에 고유한 상태 신호와 장애 동작을 지정하세요. Home Assistant는 시작 중인 데이터베이스에 재시도해야 하지만, 반복적으로 비정상 상태인 데이터베이스는 끝없는 재시작 뒤에 숨기지 말고 장애로 표시해야 합니다. 프로세스 종료에서 복구하려면 재시작 정책을 사용하고, 서비스가 실제로 준비되었는지는 상태 확인과 모니터링으로 판단하세요.

가능하면 선택적 서비스를 핵심 시작 체인에서 제외하세요. 고장 난 대시보드 렌더러, 미디어 도구 또는 메트릭 익스포터 때문에 자동화 컨트롤러가 오프라인 상태로 유지되어서는 안 됩니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

변경 경계를 고정하고 롤백 쌍을 보존하기

업데이트 전에 현재 Home Assistant 이미지 태그, Compose 정의, 데이터베이스 버전, 구성 백업 및 시작 과정에 참여하는 보조 서비스의 버전을 기록하세요. 한 번에 한 계층만 변경하세요. 구성 또는 데이터베이스 마이그레이션으로 영구 상태가 변경된 후에는 컨테이너 이미지만 롤백하는 것이 안전하지 않을 수 있습니다.

주요 호스트 또는 데이터베이스 마이그레이션 전에 스테이징 복원이나 복제된 복구 디렉터리를 사용해 대상 버전을 테스트하세요. 이전에 정상 작동한 이미지와 업데이트 직전에 생성한 상태 스냅샷을 한 쌍으로 보존하세요. 새 버전에서 자동화, 기록, 라디오, 대시보드, 알림 및 재시작 테스트가 통과한 후에만 해당 쌍을 삭제하세요.

보다 최근의 Home Assistant Docker Compose 설계 문서는 네트워킹, 영구 스토리지 및 백업을 명시적인 배포 결정으로 다룹니다. 이것이 롤백에 적합한 모델입니다. 폐기 가능한 컨테이너 파일 시스템이 아니라, 교체 컨테이너에 필요한 상태와 배포 정의를 보존하세요.

배포를 복구 가능하다고 부르기 전에 깨끗한 호스트에서 재구축하기

예비 장비, 가상 머신 또는 격리된 테스트 디렉터리를 선택하고 실행 중인 컨테이너 파일 시스템의 파일을 참조하지 않은 채 복구를 수행하세요. 컨테이너 런타임을 설치하고, Compose 정의를 배치하고, 영구 상태를 복원하고, 비밀 정보를 재생성하고, 안정적인 장치 경로로 라디오를 연결하고, 필요한 의존성을 시작한 다음 Home Assistant를 실행하세요.

잘못된 백업이라고 판단하기 전에 파일 소유권과 권한을 확인하세요. 마이그레이션 후 권한 차이로 인해 데이터가 존재하더라도 새 온보딩 화면이 표시될 수 있습니다. 한 Docker 마이그레이션 복구 사례는 권한과 숨겨진 상태가 서로 독립적으로 복원된 설치가 나타나지 않게 할 수 있음을 보여 줍니다.

1. 기존 관리자 계정으로 로그인합니다.
2. 통합 구성 요소, 엔터티, 자동화, 대시보드 및 기록을 확인합니다.
3. Zigbee, Z-Wave, Thread, Bluetooth 또는 기타 라디오의 소유권을 확인합니다.
4. 인터넷 연결을 끊고 중요한 로컬 자동화를 실행합니다.
5. 호스트와 필요한 모든 의존성을 다시 시작합니다.
6. 빈 호스트에서 정상적으로 가정을 제어할 수 있을 때까지의 전체 복원 시간을 측정합니다.

컨테이너화된 모든 의존성에 복구 계약 사용하기

복구 가능한 배포에는 버전 관리되는 정의, 호스트 외부에 보관된 상태, 의존성 준비 상태, 롤백 쌍 및 시간을 측정한 깨끗한 호스트 복원이 있어야 합니다. 이러한 테스트를 통과하면 컨테이너는 대체할 수 없는 반려동물이 아니라 원래 의도한 대로 교체 가능한 런타임 단위가 됩니다.