전체 애플리케이션 상태를 보존하고, 교체 인스턴스가 전체 검증을 통과할 때까지 기존 인스턴스를 그대로 유지하면서 Home Assistant 데이터를 이전하세요.
사용자와 설정은 눈에 보이는 YAML 파일만으로 구성되지 않으며, 대시보드를 복사한다고 기록이 다시 생성되는 것도 아닙니다. 마이그레이션에서는 Home Assistant 구성 디렉터리 전체 또는 지원되는 백업, 기록이 필요한 경우 Recorder 데이터베이스, 숨겨진 저장소, 비밀 정보, 사용자 지정 구성 요소, 그리고 이들과 관련된 런타임별 장치 및 네트워크 매핑을 보존해야 합니다. 가장 안전한 순서는 인벤토리 작성, 일관된 복사, 격리된 시작, 검증, 소스 폐기입니다.
이전 전에 영구 상태와 외부 종속성의 인벤토리를 작성하세요
컨테이너 설치에서는 익숙한 파일 몇 개를 선택하기보다 마운트된 Home Assistant 구성 디렉터리 전체를 핵심 복구 단위로 취급하세요. .storage 아래의 숨겨진 상태, 인증 데이터, 통합 레지스트리, 대시보드, 자동화, 기본 Recorder 데이터베이스가 모두 해당 경로 아래에 있을 수 있습니다. 외부 MariaDB, MQTT, Zigbee 게이트웨이, 비밀 저장소 또는 NAS 마운트는 별도로 목록에 기록해야 합니다.
Home Assistant 컨테이너 마이그레이션 안내에서는 파일별로 상태를 재구성하는 것보다 구성 디렉터리 전체를 이전하는 방법이 더 안전한 이유를 설명하며, 원시 파일 시스템 복사 전에 기존 컨테이너를 중지해야 한다고 강조합니다.
소스 경로, 대상 경로, 소유자 UID/GID, 데이터베이스 위치, USB 또는 직렬 장치, 네트워크 모드, 공개 포트, 외부 서비스, 현재 Home Assistant 버전을 포함한 매니페스트를 작성하세요. 문서화되지 않은 종속성이 하나라도 있다면 기존 인스턴스를 삭제하지 마세요. 새 호스트가 작성된 정보만으로 해당 종속성을 재현할 수 있을 때까지 마이그레이션은 준비되지 않은 것입니다.
데이터를 복사하기 전에 일관된 롤백 지점을 만드세요
설치 환경에서 지원한다면 내장 백업 또는 애플리케이션 인식 방식의 다른 방법을 사용하세요. 원시 컨테이너 복사를 수행하는 경우, 활성 구성 데이터베이스와 관련 파일을 복사하기 전에 Home Assistant를 중지하세요. 일반적인 실행 중 복사는 서로 다른 시점의 애플리케이션 파일을 담을 수 있으며, 이는 통제된 마이그레이션과 정반대입니다.
Home Assistant의 백업 개편으로 설치 방식 전반에서 복원 지원이 확대되었으므로, 런타임을 변경할 때 지원되는 백업은 강력한 이식성 경계가 됩니다. 설치 환경 간 백업 복원에서 얻을 수 있는 실질적인 교훈은 새 런타임이 바뀌더라도 애플리케이션 상태가 연속성을 유지하는 경계로 남는다는 점입니다.
사본은 두 개 보관하세요. 하나는 이전 직전의 손대지 않은 복구 지점으로, 다른 하나는 마이그레이션에 사용할 작업 사본으로 유지합니다. 새 Home Assistant 인스턴스가 유일한 정상 소스 사본을 대상으로 시작하도록 하지 마세요. 대상 환경에서 마이그레이션을 수행하거나 새 레지스트리 상태를 기록할 경우에도 기존 버전과 기존 호스트로 돌아갈 수 있는 깨끗한 경로가 있어야 합니다.
런타임별 하드웨어 및 네트워크 매핑을 별도로 재구성하세요
애플리케이션 데이터만으로는 호스트 장치 경로가 자동으로 재생성되지 않습니다. Zigbee 또는 Z-Wave USB 코디네이터가 다른 장치 이름으로 나타날 수 있고, Bluetooth 접근 권한이 달라질 수 있으며, 호스트 네트워킹 변경으로 검색 기능이 영향을 받을 수 있습니다. 외부 데이터베이스나 MQTT 브로커가 다른 주소를 통해 확인될 수도 있습니다. 데이터를 잃었다고 판단하기 전에 이러한 인터페이스를 명시적으로 다시 구성하세요.
독립적인 컨테이너에서 HAOS로의 마이그레이션 안내에서는 Home Assistant Core 상태를 복원해도 MQTT, Zigbee2MQTT 또는 Node-RED 같은 보조 서비스가 자동으로 재생성되지 않는다는 점을 보여 줍니다. 해당 안내의 보조 서비스 재매핑 마이그레이션 순서에서는 Recorder 기록의 연속성, USB 코디네이터 접근, 그리고 롤백 경로로 사용할 수 있도록 중지했지만 온전하게 보존된 기존 스택도 검증합니다.
제어된 LAN 경로에서 대상을 시작하고, 두 인스턴스를 동일한 무선 장치, 웹훅, 클라우드 계정 또는 자동화와 함께 실행하지 마세요. 의도적으로 격리한 경우는 예외입니다. 활성화된 Home Assistant 인스턴스 두 개가 중복 작업을 수행하거나 동일한 코디네이터를 두고 경쟁할 수 있어, 올바른 데이터 마이그레이션이 실패한 것처럼 보일 수 있습니다.
전환 전에 사용자, 기록, 설정 및 장치 제어를 검증하세요
기존 일반 사용자 계정으로 로그인하고, 관리자 계정을 확인하며, 이전 시점보다 오래된 기록 그래프를 열어 보세요. 통합을 점검하고, 대표적인 자동화를 실행하며, 중요한 각 프로토콜에서 장치 하나씩을 확인하세요. 그런 다음 Home Assistant를 다시 시작하고 대상 호스트를 재부팅하여 복구된 상태가 정상적인 수명 주기 이벤트 이후에도 유지되는지 확인하세요.
관련 ZimaSpace 설명인 Home Assistant 영구 데이터 역할에서는 유용한 복구 경계를 제시합니다. 즉, 이전 과정에서 지속적인 ID, 구성 및 기록을 캐시나 임시 파일과 다르게 취급해야 한다는 것입니다.
로컬 테스트가 통과한 후에만 DNS, 프록시 또는 원격 액세스를 전환하세요. 최소 한 번의 정상 사용 주기 동안 기존 호스트의 전원은 꺼 두되 복구 가능한 상태로 유지하세요. 사용자, 기록, 설정, 자동화, 무선 장치, 외부 서비스, 백업 생성 및 재부팅이 모두 예상대로 작동할 때에만 기존 환경을 폐기하세요. 대시보드가 처음 성공적으로 로드되었다는 것만으로는 롤백 경로를 삭제할 충분한 근거가 되지 않습니다.
지원 및 팁
더 읽어보기

동시 컨테이너 환경에서 Home Assistant 데이터베이스 연결을 최적화하는 방법
측정된 활성 연결 수와 지연 시간을 바탕으로 외부 Recorder 데이터베이스를 튜닝하세요. 최대 연결 수를 늘리거나 다른 호스트의 풀 설정을 그대로 복사해서는 안 됩니다.

Home Assistant에서 중복 작업 또는 가져오기를 방지하는 방법
추적 정보와 고유한 작업 키를 사용해 자동화와 가져오기를 안전하게 재시도하고, 작업이나 레코드가 중복 생성되지 않도록 하세요.

데이터베이스 볼륨이 가득 찬 후 Home Assistant 복구 방법
먼저 증거를 삭제하지 않고 가득 찬 Recorder 볼륨을 복구한 다음, 증가량을 줄이고 재시작 후에도 기록과 자동화가 유지되는지 입증하세요.

