Home Assistant 백업에서 일관되지 않은 데이터베이스 상태가 캡처되지 않도록 하는 방법

에바 왕기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

애플리케이션이 실행 중인 데이터베이스 상태를 조정하도록 하거나, 원시 파일 시스템 복사 전에 쓰기 작업을 중지하여 Home Assistant 백업의 불일치를 방지하세요.

위험한 상황은 단순히 “Home Assistant가 켜진 상태에서 백업하는 것” 자체가 아닙니다. 관련 데이터베이스 파일과 애플리케이션 파일을 트랜잭션 상태를 알지 못한 채 서로 다른 시점에 캡처하는 복사 방식이 문제입니다. 기본 제공 백업은 Home Assistant 구성 요소를 조정할 수 있지만, 일반적인 rsync나 스냅샷 도구는 그렇지 않을 수 있습니다. 어떤 메커니즘이 일관성을 담당하는지 정하고, 데이터베이스를 많이 사용하는 작업이 겹치지 않도록 하며, 이전의 정상 백업을 보존하고, 격리된 복원으로 모든 정책을 검증하세요.

실행 중인 SQLite 데이터베이스를 일반 정적 파일처럼 취급하지 마세요

일반 백업 프로세스가 구성 디렉터리를 복사하는 동안 Home Assistant Recorder가 데이터를 기록할 수 있습니다. SQLite에서는 커밋된 상태가 기본 데이터베이스와 저널 또는 WAL 파일에 걸쳐 있을 수 있으므로, 서로 맞지 않는 시점의 파일을 캡처하면 아카이브에 모든 파일 이름이 존재하더라도 불완전하거나 복구할 수 없는 복사본이 생성될 수 있습니다.

실행 중인 SQLite 백업 테스트에서 기본 데이터베이스 파일만 복사하면 WAL에 여전히 존재하는 커밋된 행이 조용히 누락될 수 있음이 확인되었습니다. 복사된 데이터베이스가 무결성 검사를 통과한 경우에도 마찬가지였습니다. 이러한 WAL 기반 복사 실패가 발생할 수 있으므로, 원시 파일 복사는 데이터베이스를 인식하는 스냅샷을 사용하거나 데이터베이스가 정상적으로 유휴 상태가 된 후에만 수행해야 합니다.

그렇다고 Home Assistant를 백업할 때 항상 종료해야 한다는 뜻은 아닙니다. 백업 메커니즘이 일관된 복구 지점을 생성하는 방법을 알고 있어야 한다는 의미입니다. 실행 중인 설치에는 기본 제공 Home Assistant 백업을 사용하고, 마이그레이션이나 오프라인 보관 또는 애플리케이션 인식 통합 기능이 없는 외부 도구를 사용할 때만 중지된 상태의 파일 시스템 복사를 사용하세요.

같은 시간대에 백업 또는 유지 관리 작업이 서로 경쟁하지 않도록 하세요

애플리케이션을 인식하는 백업이라도 다른 프로세스가 잠금을 보유하고 있거나 저장 경로가 특별한 유지 관리 작업으로 인해 과도한 부하를 받으면 데이터베이스 준비에 실패할 수 있습니다. 집이 조용하다는 이유만으로 두 번째 애드온 백업, 데이터베이스 유지 관리, NAS 스냅샷, Home Assistant 백업을 정확히 같은 시각에 시작하도록 예약하지 마세요.

실제 Home Assistant 백업 실패 사례에서는 데이터베이스 잠금 준비 오류가 보고되었으며, 한 사용자는 다른 백업 애드온과의 충돌을 원인으로 추적했습니다. 이는 예방을 위한 신호입니다. 겹치는 도구의 실행 시간을 분리하고, 애플리케이션 로그에서 백업 전 단계가 완료되었는지 확인해야 합니다.

유지 관리 시간대를 분리하고 예상 소요 시간을 기록하세요. 백업이 Recorder에서 반복적으로 대기한다면 먼저 잠금을 보유한 주체나 데이터베이스 상태 문제를 확인하세요. 무작정 시간 제한을 늘리거나 복사본을 더 많이 병렬 실행하지 마세요. 백업 작업이 많아지면 해결하려는 바로 그 경합이 심해질 수 있습니다.

원시 파일 시스템 복사에서는 Home Assistant를 유휴 상태로 만들고 전체 상태 집합을 보존하세요

정책상 구성 디렉터리를 직접 복사해야 한다면 복사 전에 Home Assistant를 정상적으로 종료하고, 프로세스가 더 이상 파일에 쓰지 않는지 확인한 다음, 기본 데이터베이스 파일만 골라 복사하지 말고 필요한 전체 상태를 복사하세요. 외부 데이터베이스 백업은 자체적인 일관성 확보 방식으로 관리하세요.

기존 ZimaSpace의 실행 중 백업과 중지 후 Home Assistant 백업 비교에서도 같은 경계를 설명합니다. 애플리케이션을 인식하는 실행 중 백업과 원시 파일 시스템 복사는 서로 다른 절차이므로 하나의 규칙으로 섞어서는 안 됩니다.

복사 후 서비스를 다시 시작하고 Recorder가 정상적으로 작동하는지 확인하세요. 백업 대상이 네트워크 저장소라면 네트워크 마운트가 제거되기 전에 파일 집합 복사가 완료되었는지도 확인하세요. 중지된 상태에서 복사하더라도 중간에 중단되면 소스가 조용했다는 좁은 의미에서만 일관성이 있을 뿐, 완전한 복구 지점은 아닙니다.

-15% OFF

격리된 복원이 성공한 후에만 백업을 신뢰하세요

임시 Home Assistant 인스턴스나 복구 대상을 만들고, 운영 환경의 변경 가능한 파일을 가져오지 않은 상태에서 후보 백업을 복원하세요. 기존 사용자, 기록 데이터, 대시보드, 통합 구성, 자동화 정의 및 최소 한 번의 재시작을 확인하세요. 복원에 걸린 시간과 인스턴스를 사용할 수 있게 하기 위해 필요한 수동 수정 사항을 기록하세요.

2026.7.2 버전 범위의 Home Assistant Core 회귀 문제에서는 백업 전 단계에서 Recorder가 WAL 체크포인트를 수행하지 못했고, 이후 백업 관리자가 데이터베이스 잠금을 기다리다 시간 초과되었습니다. 이러한 백업 전 실패 신호는 해당 경로에 대한 증거이자 실패한 복구 지점으로만 취급해야 합니다. 모든 잠금 시간 초과의 원인이 같다는 증거로 사용해서는 안 됩니다.

한 번에 하나의 백업 메커니즘만 일관성을 담당하고, 데이터베이스 준비 단계가 완료되며, 이전의 정상 복사본이 보존되고, 복원을 통해 사용자, 기록, 설정 및 정상적인 재시작 동작이 재현되면 정책을 통과한 것입니다. 복원 테스트에 실패하면 증거를 보존하고, 이전 복구 지점을 삭제하기 전에 지원되는 새 백업이나 통제된 중지 상태 복사본을 생성하세요.

지원 및 팁

더 읽어보기

Home Assistant 캐시 및 임시 저장소 구성 방법
Aug 31, 2026

Home Assistant 캐시 및 임시 저장소 구성 방법

Home Assistant의 영구 상태는 내구성 있는 저장소에 보관하고, 폐기해도 되는 경로에만 tmpfs를 사용하며 크기는 호스트와 컨테이너의 메모리 예산 내에서 설정하세요.

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.