현재 Home Assistant 설치 환경에서는 기본 제공 백업 시스템을 우선 사용하고, Home Assistant가 온라인 상태일 때 백업이 실행되도록 하세요. 일반 파일 시스템 복사본을 만들거나 활성 데이터베이스와 조율되지 않는 다른 방법을 사용할 때만 서비스를 중지하거나 일시 정지하면 됩니다.
따라서 실제로 판단해야 할 기준은 단순히 “실행 중인가, 중지되었는가”가 아니라 “지원되는 애플리케이션 백업인가, 일반 파일 복사인가”입니다. rsync, SMB 복사, VM 스냅샷 또는 아카이브 명령이 성공적으로 완료되었다고 해서 데이터베이스와 Home Assistant의 나머지 상태가 동일한 복구 시점에 일관되게 저장되었다는 뜻은 아닙니다.
먼저 기본 제공 백업 경로 사용
이제 Home Assistant의 Backup 통합은 설치 유형 전반에서 백업을 생성하고 복원합니다. Core 및 Container에서는 backup.create 작업을 사용하면 시스템이 온라인 상태인 동안 Home Assistant 구성과 데이터베이스가 포함됩니다.
일상적인 복구 지점에는 이 지원되는 경로를 기본으로 사용해야 합니다. 암호화 키나 비상 키트를 Home Assistant 호스트 외부에 보관하고, 최소 하나의 백업은 호스트 외부로 이동하세요. 업그레이드나 마이그레이션에 백업을 사용하기 전에 해당 백업을 복원할 수 있는지 확인해야 합니다.
기본 제공 백업으로 처리할 수 없는 이유가 있을 때만 수동 파일 시스템 복사로 전환하고, 그때는 데이터베이스 일관성이 어떻게 보장되는지 명확히 하세요.
일반 /config 복사본을 만들 때만 Home Assistant 중지
서비스를 중지하는 것은 일반 구성 디렉터리 복사본의 내부 일관성을 확보하는 가장 간단한 방법입니다. 먼저 대상 위치, 권한, 여유 공간을 준비한 다음 Home Assistant를 중지하고 디렉터리 전체를 복사한 뒤 작업을 확인하고 서비스를 다시 시작하세요.
실용적인 컨테이너 마이그레이션 작업은 정확히 이 경계를 따릅니다. SQLite 기반 영구 구성을 복사하기 전에 컨테이너를 중지하세요. 이는 원시 파일 시스템 전송에는 적합하지만, 모든 기본 제공 백업 작업을 위해 Home Assistant를 중지해야 한다는 의미는 아닙니다.
중지한 뒤 경로 오류를 발견해 중단 시간을 늘리지 마세요. 미리 대상 위치를 검증하고, 중지된 시간에는 최종적으로 신뢰할 수 있는 복사 작업만 수행하세요.
데이터베이스를 인식하는 방식이라면 실행 중인 데이터베이스도 안전하게 백업 가능
SQLite 자체는 원본 데이터베이스가 활성 상태인 동안 일관된 독립 복사본을 생성하는 온라인 백업 메커니즘을 지원합니다. 이는 일반 동기화 도구로 데이터베이스 파일과 WAL을 별도로 복사하는 것과는 전혀 다릅니다.
최근 홈랩 백업 작업 흐름에서는 SQLite의 페이지 인식형 .backup 명령이 단순한 실시간 rsync에서 발생할 수 있는 일관되지 않은 메인 파일과 WAL 조합을 방지하는 이유를 설명합니다.
사용자 지정 실시간 백업을 구축한다면 데이터베이스를 인식하는 복사본을 별도로 준비하고, 호환되는 방식으로 나머지 구성을 복사한 뒤, 전체 결과를 복원 테스트로 검증하세요. 데이터베이스 일관성만으로는 누락된 사용자 지정 파일, 비밀 정보 또는 런타임 정의까지 보존할 수 없습니다.
데이터베이스 인식형 실시간 백업과 일반 스냅샷을 분리
데이터베이스를 인식하는 실시간 백업 방법이나 Home Assistant 자체의 백업 인터페이스에는 “rsync를 위해 중지” 규칙을 적용하지 마세요. 일관성 보장은 도구 이름에 “스냅샷” 또는 “백업”이라는 단어가 포함되었는지가 아니라 백업 방식 자체에서 비롯됩니다.
Container 설치에서는 Home Assistant 외부에 런타임 정의도 보존해야 합니다. 여기에는 Compose 파일, 호스트 구성 경로, 장치 매핑, 네트워크 모드, 외부 서비스 종속성이 포함됩니다. 백업 아카이브는 Home Assistant 상태를 복원할 수 있지만, 문서화되지 않은 컨테이너 배치를 그 자체로 재현해 주지는 않습니다.
ZimaSpace의 NAS와 별도로 Home Assistant만의 복구 계획을 마련한 사례는 범위의 경계를 잘 보여 줍니다. 데이터 보호에는 애플리케이션 상태뿐 아니라 애플리케이션을 실행하는 데 필요한 환경도 포함되어야 합니다.
복원 결과로 백업을 평가
최근 백업을 격리된 대상에 복원하고 사용자, 통합, 대시보드, 자동화, 헬퍼, 장치 레지스트리, 필요한 경우 기록 데이터, 그리고 대표적인 로컬 제어 경로 하나를 확인하세요. 복원된 대상을 한 번 재시작한 뒤에야 백업이 검증되었다고 판단해야 합니다.
매일 밤 백업이 완료되더라도 작동하는 시스템으로 복원할 수 없다면, 테스트를 거친 복구 결과를 제공하는 짧은 유지보수 중단보다 운영상 더 나쁜 백업 방식입니다. 필요한 중단 시간을 충족하면서 반복적으로 복원 가능한 상태를 만들어 주는 가장 단순한 방법을 우선 선택하세요.
FAQ
Home Assistant의 기본 제공 백업 기능을 사용하기 전에 Home Assistant를 중지해야 하나요?
아니요. 기본 제공 백업 작업 흐름을 설계된 방식대로 사용하세요. 중지 권고는 Home Assistant의 활성 데이터베이스와 상태를 조율하지 않는 일반 파일 수준 복사본에만 적용됩니다.
파일 시스템 스냅샷이나 VM 스냅샷은 자동으로 안전한 실시간 백업인가요?
자동으로 안전한 것은 아닙니다. 스냅샷의 유용성은 캡처된 일관성과 이후에 수행하는 복원 테스트에 달려 있습니다. 스냅샷을 생성하는 동안 애플리케이션과 데이터베이스가 계속 기록 중이었다면, 해당 스냅샷 방식이 복구 계획에 필요한 일관성 보장을 제공하는지 확인하세요.
지원 및 팁
더 읽어보기

유휴 시간에 Home Assistant 서버가 뜨겁거나 시끄럽게 작동하는 이유는 무엇인가요?
냉각이나 CPU 제한을 변경하기 전에 Recorder, 백업, 통합 구성 요소 및 함께 실행되는 작업을 통해 Home Assistant의 팬 작동 또는 온도 급증 원인을 분석하세요.

Home Assistant를 수리하기보다 다시 구축해야 할 때는 언제인가요?
먼저 실패한 Home Assistant 계층 중 가장 작은 부분을 복구하고, 다음으로 검증된 정상 상태를 복원하며, 지속적인 구성을 신뢰할 수 없을 때만 다시 구축하세요.

Home Assistant가 백그라운드 작업을 위해 확보해야 하는 여유 저장 공간은 얼마나 될까요?
Home Assistant의 여유 공간은 일률적인 비율이 아니라 Recorder 데이터베이스, 백업 증가량, 유지 관리 시 최대 사용량, 복구 작업을 기준으로 산정하세요.

