스냅샷 모드에서만 VM 백업이 같은 비율로 멈춘다면, 고정된 디스크 불량 영역보다는 라이브 스냅샷 또는 게스트 프리즈 경로에 문제가 있을 가능성이 높습니다.
결정적인 비교 방법은 동일한 VM, 대상, 대략적인 데이터 세트를 사용해 스냅샷 모드와 중지 모드를 비교하는 것입니다. 중지 모드가 반복해서 기존 중단 지점을 통과한다면, 일반적인 고정 영역 진단의 가능성은 낮아지고 QEMU 게스트 에이전트의 프리즈/해제, 애플리케이션 정지, 스냅샷을 지원하는 스토리지, 라이브 쓰기 동작을 조사해야 합니다. 테스트하는 동안 정상적으로 작동하는 중지 모드 백업을 유지하여 문제 해결 과정에서 복구 가능한 마지막 사본이 사라지지 않도록 하세요.
중지 모드가 스냅샷 실패 지점을 통과하는지 확인
점검 시간에 실패하는 스냅샷 작업과 동일한 대상으로 중지 모드 백업을 한 번 실행하세요. 스냅샷 모드가 일반적으로 멈추는 비율, 디스크, 처리량, 소요 시간을 기록합니다.
Proxmox 백업 모드 비교 자료에서는 스냅샷 모드는 VM을 실행 상태로 유지한다고 설명하는 반면, 중지 모드는 게스트 런타임 변수를 많이 제거합니다.
중지 모드도 같은 지점에서 멈춘다면 일반적인 동일 비율 문서로 돌아가 소스 또는 대상 스토리지를 테스트하세요. 중지 모드가 완료된다면 이후 실험은 스냅샷 관련 경로에 집중해야 합니다.
QEMU 게스트 에이전트의 프리즈가 원인인지 확인
백업 로그에서 guest-fsfreeze-freeze, guest-fsfreeze-thaw, 시간 초과 또는 게스트 에이전트 통신 오류를 확인하세요. 해당 시각을 게스트의 저널 또는 Windows 이벤트 로그와 비교합니다.
Proxmox Windows 백업 안내에서는 에이전트가 활성화된 경우 게스트 에이전트가 fsfreeze를 수행한다고 설명합니다.
첫 번째 해결 방법으로 게스트 일관성 기능을 영구적으로 비활성화하지 마세요. 제어된 테스트를 통해 프리즈 호출 자체가 경계 지점인지 확인한 다음, 게스트 에이전트 또는 파일 시스템과의 상호 작용을 수정하세요.
정상적으로 프리즈되지 않는 파일 시스템 확인
게스트 내부에 마운트된 파일 시스템을 조사하세요. 루프 장치, 네트워크 파일 시스템, 바인드와 유사한 애플리케이션 마운트, 데이터베이스 스토리지, 특수한 제어판 구성도 포함해야 합니다. 스냅샷이 시작될 때 어떤 파일 시스템이 사용 중인지 기록합니다.
CloudLinux는 fsfreeze가 복잡한 게스트에서 멈출 수 있다고 설명하며, 원인이 백업 대상 자체가 아닐 수 있음을 보여줍니다.
문제가 있는 게스트 마운트를 제거하거나 수정한 후 스냅샷 모드가 해당 비율을 통과한다면, 일관성 보호 기능을 다시 활성화하고 관련 의존성을 문서화하세요. 강제 재설정을 반복하면 백업 문제가 게스트 파일 시스템 손상으로 이어질 수 있으므로 피해야 합니다.
프리즈 시간 초과와 전송 중단 구분
백업이 실제 데이터 전송이 시작되기 전에 멈추는지, 프리즈 요청 직후 멈추는지, 아니면 블록 복사 중에 멈추는지 확인하세요. 0에 가까운 고정 비율은 가상 디스크 중간에서 멈추는 경우와 전혀 다른 실패 단계를 나타낼 수 있습니다.
한 호스팅 지식 베이스 사례에서는 스냅샷 시퀀스가 시작된 후 프리즈로 인해 백업이 무기한 중단될 수 있다고 설명합니다.
전송이 전혀 시작되지 않는다면 게스트 정지 처리에 집중하세요. 전송이 오랫동안 정상적으로 진행된 후 멈춘다면 라이브 쓰기 부하, 스냅샷 계층 동작, 스토리지 지연 시간을 대신 비교하세요.
전체 백업 외부에서 게스트 프리즈 재현
플랫폼과 유지 관리 정책이 허용하는 경우, 게스트 에이전트의 프리즈 및 해제 동작을 독립적으로 테스트하거나 수동 스냅샷 이벤트 중 게스트를 면밀히 관찰하세요. 콘솔을 열어 두고 해제 후 게스트가 쓰기 작업을 재개하는지 확인합니다.
QEMU 이슈에는 특정 게스트 파일 시스템 구성에서 QEMU fsfreeze가 VM을 잠글 수 있다고 기록되어 있습니다.
프리즈만으로 멈춤이 재현된다면 PBS 처리량을 조정하기 전에 해당 게스트 경로를 수정하세요. 프리즈와 해제가 정상이라면 스냅샷 스토리지 및 라이브 쓰기의 상호 작용을 점검하세요.
스냅샷 모드가 정상화될 때까지 중지 모드를 복구 경로로 유지
편의 기능을 디버깅하는 동안 신뢰할 수 있는 백업을 희생하지 마세요. 스냅샷 모드가 여러 차례 완료되고 복원 테스트로 결과가 확인될 때까지, 허용 가능한 유지 관리 시간에 중지 모드 백업을 예약하세요.
Server Fault 사례에서는 라이브 스냅샷 동작을 별도로 처리해야 할 때 중지 모드를 대체 경로로 사용한다는 실제 환경을 보여줍니다.
스냅샷 모드가 기존 중단 지점을 반복해서 통과하고 백업 전후와 백업 중에도 게스트가 응답 상태를 유지하면 문제가 해결된 것입니다. 관련 ZimaSpace 문서인 동일 비율에서 발생하는 일반적인 백업 중단은 중지 모드도 멈추는 경우에 올바른 상위 분기입니다.
자주 묻는 질문
중지 모드를 스냅샷 모드의 영구적인 대체 수단으로 사용해도 되나요?
다운타임을 허용할 수 있다면 신뢰할 수 있는 대체 수단이 될 수 있습니다. 하지만 게스트를 안전하게 정지할 수 있고 라이브 백업이 일관되게 완료된다면 일반적으로 스냅샷 모드가 더 적합합니다.
백업이 작동하도록 QEMU 게스트 에이전트를 비활성화해야 하나요?
적절한 경우에 한해 제어된 진단 테스트로만 사용하세요. 게스트 에이전트는 종료 및 일관성 유지에도 유용한 기능을 제공하므로, 근본적인 프리즈 문제를 숨기기보다 원인을 확인해야 합니다.
문제가 fsfreeze라면 백업이 왜 같은 비율에서 멈추나요?
진행률은 디스크 위치뿐 아니라 반복 가능한 백업 단계에 대응할 수 있습니다. 따라서 같은 단계에서 도달하는 프리즈 또는 스냅샷 전환이 동일한 표시 비율을 만들 수 있습니다.
지원 및 팁
더 읽어보기

Plex가 다른 Docker 컨테이너와 GPU를 공유할 수 있나요?
Plex와 다른 컨테이너가 동일한 GPU에 함께 액세스할 수 있는 경우가 많지만, 드라이버 지원, 디바이스 매핑, 비디오 엔진 부하, 메모리, 복구 동작을 테스트해야 합니다.

Plex 오류가 클라이언트에서 발생한 것인지 서버에서 발생한 것인지 확인하는 방법
다른 클라이언트에서 동일한 항목을 재현하고, 세션 경로를 비교한 다음, 범위 분석을 통해 장애가 실제로 발생한 위치를 확인한 후에만 서버 증거를 수집하세요.

Plex 캐시 및 트랜스코딩 임시 저장소 구성 방법
영구 Plex 상태는 보호하면서 트랜스코딩 임시 파일은 적합한 로컬 저장소에 배치한 다음, 정리 상태와 여유 공간 및 재시작 동작을 확인하세요.

