구성 사례 · Clash 기술 블로그

Clash Verge Rev 자동 백업 안 됨: 재시작 후 해결

Clash Verge Rev 재시작 후 예약 백업이 안 되나요? 먼저 수동 백업을 내보내고 앱을 v2.5.9로 업데이트하세요. 설정한 간격이 완전히 지날 때까지 앱을 실행한 뒤 ZIP과 Scheduled 로그로 검증하세요. WebDAV나 변경으로 생성된 백업은 예약 실행 성공의 증거가 아닙니다.

  • Clash Verge Rev
  • 예약 백업
  • 로컬 백업
  • 재시작
  • v2.5.9
이 글의 목차

예약 백업을 켜고 이전 ZIP도 보관해 두었지만, Clash Verge Rev를 다시 열고 나서부터 설정한 간격마다 새 파일이 생기지 않을 수 있습니다. 프록시를 계속 쓸 수 있거나 스위치가 켜져 있다는 사실만으로 예약 백업이 실행 중이라고 볼 수는 없습니다. 먼저 앱의 타이머, 수동 백업, 실제 파일 쓰기 실패를 구분하세요.

백업을 켰는데 재시작 후 새 파일이 계속 없는 이유는?

공식 issue #8331의 사용자는 Windows 11과 Clash Verge Rev v2.5.8에서 백업 간격을 1시간으로 설정했습니다. 앱을 완전히 종료했다가 다시 시작한 뒤 설정을 바꾸지 않고 기기를 깨어 있는 상태로 1시간 넘게 유지했지만, 자동 백업 파일도 해당 Backup 로그도 없었습니다.

이 사용자는 설정을 변경한 뒤 전체 간격을 다시 기다리고 나서야 예약 백업을 확인했습니다. 이는 문제를 구분하는 데 도움이 되는 비교 사례일 뿐입니다. '시작할 때마다 아무 설정이나 바꾸기'를 지속적인 해결책으로 삼거나, 점검을 위해 언어·프록시·구독을 반복해서 바꿀 필요는 없습니다.

이 글은 해당 Windows 보고, 공통 백업 코드, 정식 수정 안내를 근거로 합니다. 모든 플랫폼이나 모든 구버전에서 직접 영향을 확인했다는 뜻은 아닙니다. v2.5.9에서 이 문제가 정식으로 수정됐습니다. 아직 전체 간격을 기다리지 않았거나 앱이 종료된 경우라면 먼저 정상적인 타이머 작동 조건부터 확인하세요.

세 가지 백업을 구분해서 판단하기

확인한 기록확인할 수 있는 것확인할 수 없는 것
로컬 수동 백업 성공현재 로컬 백업 파일을 만들 수 있음재시작 후 예약 타이머가 시작됐음
파일 이름에 -auto-merge 또는 -auto-script가 있음전역 덮어쓰기나 스크립트 변경으로 백업이 실행됐음-auto-scheduled 예약 백업이 정상임
WebDAV 업로드 성공이번 서버 업로드가 완료됐음로컬 예약 타이머가 실행됐거나 자동 업로드됐음
새 -auto-scheduled.zip과 Scheduled 성공 로그이번 예약 작업이 실제로 로컬 파일을 만들었음다음에 완전히 종료했다가 다시 시작해도 반드시 정상임

먼저 수동 백업하고 앱 폴더 밖에도 보관하기

다음 예약 백업을 기다리지 말고 현재 설정부터 보호하세요. '설정 → Verge 고급 설정 → 백업 설정'으로 들어가 '로컬 백업'에서 '백업'을 누르세요. 이어서 'View history'(기록 보기)를 열고 방금 생성된 ZIP을 '내보내기'로 앱 데이터 폴더 밖에 저장하세요.

내보낸 파일이 존재하고 열리는지 확인한 뒤 profiles.yaml, profiles/와 자신의 주요 설정 내용을 점검하세요. ZIP은 압축 보관 형식이며 암호화를 뜻하지 않습니다. 구독 토큰, 노드 비밀번호, 로컬 덮어쓰기가 들어 있을 수 있으므로 자신이 관리하는 보호된 저장소에 보관하세요.

수동 백업에서도 오류가 나면 첫 오류를 보관하고 기존 데이터를 별도로 복사한 뒤 실제 파일 쓰기 문제를 확인하세요. 곧바로 재시작 후 예약 실행 결함으로 단정하거나, 확인을 위해 앱 폴더를 비우고 이전 ZIP을 복원하거나 앱을 제거해서는 안 됩니다.

업데이트 전에 보관할 항목

  • 열 수 있으며 앱 폴더 밖으로 내보낸 현재 백업 한 부.
  • 클라이언트 버전, 백업 스위치 상태, 원래 백업 간격, 마지막으로 성공한 파일의 시각.
  • 직접 관리하는 외부 파일, 원래 구독 주소, 필요한 설정을 각각 안전하게 보관.
  • 문제 발생 당시 민감 정보를 가린 Backup 오류. 전체 ZIP이나 구독 인증 정보는 공개 issue에 올리지 않기.

v2.5.9 앱에 포함된 수정: Mihomo만 업데이트해서는 해결되지 않음

공식 PR #8386에 따르면 이전 구현은 저장된 백업 설정을 먼저 전송한 뒤 타이머 작업이 구독하도록 했습니다. 수신자가 없을 때 watch 채널의 send는 새 값을 보관하지 않습니다. 뒤늦게 시작한 작업은 기본값인 '비활성화'를 읽고 다음 설정 변경이 올 때까지 기다리게 됩니다.

수정에서는 시작 시와 설정 갱신 시 두 곳의 전송을 모두 send_replace로 바꿔, 나중에 시작한 작업도 저장된 값을 읽을 수 있게 했습니다. 이 수정은 병합됐고 2026년 11월 2일 출시된 정식 버전 v2.5.9에 포함됐습니다. issue가 닫혔거나 개발 브랜치가 바뀌었다는 사실만으로 정식 배포됐다고 판단한 것이 아닙니다.

이는 Clash Verge Rev 앱의 백업 스케줄링 문제입니다. Mihomo 코어 업데이트, 구독 다시 받기, 코어 재시작만으로 앱 업데이트를 대신할 수는 없습니다. 이미 이 수정이 포함됐다는 근거가 있는 후속 정식 버전을 사용 중이라면 이 글을 위해 v2.5.9로 되돌릴 필요는 없습니다.

예약 백업은 앱 안의 타이머 작업이 로컬 파일을 만드는 방식입니다. 운영체제에서 별도로 상주하는 백업 서비스나 매일 특정 시각에 실행하는 일정 작업이 아닙니다. 앱을 완전히 종료한 동안에도 파일이 계속 생성되거나, 다시 열면 놓친 백업을 모두 보충할 것이라고 기대해서는 안 됩니다.

공식 릴리스 페이지에서 기존 설정을 유지하며 업데이트하기

이 글에서 확인한 정식 수정 버전은 Clash Verge Rev v2.5.9입니다. 본문의 참고 자료에 있는 공식 v2.5.9 Release에서 자신의 운영체제와 칩 아키텍처에 맞는 파일을 선택하세요. 이번 유지보수에서는 이 사이트가 호스팅하는 설치 파일을 갱신하지 않았으므로, 기존 v2.5.8 미러 파일을 수정 버전으로 사용해서는 안 됩니다.

기존 설치 방식에 맞춰 앱 업데이트하기

  1. 외부 사본을 보관한 뒤 공식 업데이트 준비하기

    앞 절에서 내보낸 ZIP, 현재 데이터, 외부 파일을 보관하세요. 프로젝트가 지원하는 정식 업데이트 방법을 사용하고 기존 설치 위치를 유지하세요. 포터블 폴더, 개발 버전, 출처를 알 수 없는 패키지를 섞지 마세요.

  2. 연결을 끊어도 되는 때에 정상 종료하고 설치하기

    작업을 저장하고 클라이언트가 지원하는 방법으로 시스템 프록시나 TUN을 중지한 뒤, 트레이에서 앱을 완전히 종료하세요. 이후 해당 플랫폼의 정상 설치 절차로 업데이트합니다. 창만 닫거나 내부 코어를 수동 교체하거나 앱 데이터를 지우지 마세요.

  3. 다시 열고 앱 버전과 기존 설정 확인하기

    설정에서 전체 앱 버전을 확인해 v2.5.9 또는 같은 수정이 포함됐다는 근거가 있는 후속 정식 버전이 실행 중인지 확인하세요. Profile, 덮어쓰기, 기존 프록시 모드를 점검하고 필요한 연결을 복구하세요. 설치 창이 사라졌다는 사실만으로 완료됐다고 판단해서는 안 됩니다.

공식 설치 파일을 받지 못하거나 설치 오류가 나면 기존의 작동하는 환경과 오류를 보존하고 해당 다운로드·설치 문제부터 해결하세요. 서명 검사나 보안 보호를 끄지 마세요. 사이트의 이전 패키지를 다운로드할 수 있다는 사실도 이번 업데이트가 성공했다는 증거가 되지 않습니다.

재시작 후 전체 간격을 기다리고 ZIP과 로그 확인하기

'백업 설정 → Automatic backup'(자동 백업)에서 'Enable scheduled backup'(예약 백업 활성화)과 'Backup frequency'(백업 간격)를 확인하세요. v2.5.9 고정 버전 코드의 기본 간격은 24시간이며 1–168시간을 허용합니다. 확인용으로 잠시 1시간을 선택해도 되지만 원래 값을 기록하세요. 저장한 뒤 앱을 완전히 종료했다가 한 번 다시 여세요.

이번에 앱을 다시 연 시점부터 시간을 재세요. 앱을 실행한 채 기기를 깨어 있는 상태로 유지하고, 도중에 설정을 바꾸거나 재시작하지 마세요. 전역 덮어쓰기나 스크립트를 편집해 다른 백업을 실행하지도 마세요. 설정한 간격이 완전히 지나도록 기다리세요. 시작 직후 파일이 없다는 이유만으로 실패라고 판단할 수는 없습니다.

앱 재시작이나 설정 알림이 발생하면 전체 간격을 처음부터 다시 기다립니다. 설정을 자주 저장하면 확인할 시점이 계속 늦어질 수 있습니다. 이는 백업 스위치를 켜 두고 오랫동안 설정을 바꾸지 않았는데도 실행되지 않는 상황과 구분해야 합니다.

간격이 지난 뒤 '로컬 백업 → View history'(기록 보기)에서 새 파일을 확인하고 로그의 Auto backup created (Scheduled)도 대조하세요. 예약 백업 파일 이름에는 -auto-scheduled.zip이 들어갑니다. -auto-merge, -auto-script 또는 수동 파일만 보인다면 이번 검증이 끝난 것이 아닙니다.

재시작 후 예약 실행이 복구됐는지 확인하기

  • 실행 중인 앱 버전에 #8386 수정이 포함돼 있고, 예약 스위치가 켜져 있으며, 간격을 기록했음.
  • 완전히 종료했다가 다시 연 뒤 설정을 더 바꾸지 않고 전체 간격을 넘겨 연속 실행했음.
  • 해당 시각의 새 -auto-scheduled.zip과 Scheduled 성공 로그가 있으며, 파일이 열리고 설정 내용이 현재 상태와 일치함.
  • 다음 정상 재시작 후에도 같은 조건에서 다시 확인하기. 한 번 성공했다고 재시작 후 검증을 대신할 수는 없음.
  • 임시 간격을 원래 값이나 필요한 값으로 되돌리고 외부 사본을 보관하기. 저장 후에는 다음 대기 간격이 처음부터 다시 시작됨.

고정 버전 코드는 -auto- 표시가 있는 최근 자동 백업 파일 20개만 보관합니다. 예약 실행과 전역 덮어쓰기·스크립트 변경으로 생성된 파일이 이 수량을 공유하며, 각각 20개씩 보관하는 것이 아닙니다. 로컬 폴더는 영구 기록 보관소가 아니므로 정상임을 확인한 백업도 따로 내보내세요.

이 사이트는 실제 Clash Verge Rev 클라이언트에서 한 시간을 기다리거나 복원 실험을 하지 않았습니다. 위 내용은 공식 사용자 보고와 고정 버전 소스를 바탕으로 정리한 확인 절차입니다. 이 사이트의 페이지·번역·빌드 검사가 통과해도 사용자 기기에서 예약 백업이 실행되는지 확인하는 절차를 대신할 수는 없습니다.

계속 실행되지 않으면 수동 백업부터 구분하기

수동 백업도 실패함

첫 파일 쓰기 오류와 현재 데이터 사본을 보관하고, 오류가 가리키는 경로·권한·여유 공간을 확인하세요. 예약 스위치를 계속 바꿔 실제 파일 쓰기 오류를 가리지 마세요.

수동 백업은 되지만 예약 파일이 없음

앱 버전, 스위치, 마지막 시작 또는 설정 저장 시각을 확인하고 전체 간격 동안 연속 실행했는지 점검하세요. 해당 로그도 보관하세요. '스위치를 켜도 안 된다'는 설명만으로는 부족합니다.

WebDAV 업로드만 실패함

서버 주소, 인증, 업로드 오류를 별도로 확인하세요. 로컬 Scheduled 백업 파일이 이미 생성됐다면 업로드 실패만으로 이 수정이 효과가 없다고 판단할 수는 없습니다.

업데이트 후 앱이나 기존 설정을 사용할 수 없음

더 이상 변경하지 말고 현재 상태와 첫 오류를 별도로 보관하세요. 그런 다음 프로젝트가 지원하는 방법으로 업데이트 전에 안전하게 사용할 수 있었던 프로그램과 그에 맞는 외부 사본을 이용해 복구하세요.

예약 실행만 실패한다면 수동 백업을 계속 만들고 내보내세요. 예약 동작을 시험하려고 복원을 실행해 현재 설정을 덮어쓰지 마세요. 실제로 앱 버전을 되돌리거나 데이터를 복원해야 한다면 먼저 완전히 종료하고 업데이트 전후의 사본을 각각 보관하세요. 새 프로그램과 이전 프로그램이 하나뿐인 데이터 폴더를 함께 사용하게 해서는 안 됩니다.

이전 앱에는 같은 결함이 남아 있을 수 있습니다. 버전 되돌리기는 임시 대응이며 자동 예약을 고친다는 뜻은 아닙니다. 프로그램과 데이터를 복구한 뒤 기존 Profile, 덮어쓰기, 프록시 모드, 실제 연결을 확인하세요. 수동 백업도 계속 외부에 보관하고, 예약 실행의 복구 여부는 앞 절의 조건에 따라 다시 기다린 뒤 검증하세요.

공식 프로젝트에 제보할 때는 운영체제, 전체 앱 버전, 원래 간격, 실제 시작·설정 저장 시각, 수동 백업 결과, 예약 파일 이름, 민감 정보를 가린 첫 오류를 제공하세요. 전체 ZIP, 구독 링크, 인증 정보는 올리지 마세요. 다른 플랫폼에서 수행하지 않은 검증을 통과했다고 적어서도 안 됩니다.

참고 자료