On this page
Scheduled backups are enabled, and you may still have older ZIP files, but reopening Clash Verge Rev no longer produces new files at the configured interval. A working proxy and an enabled switch do not prove that the backup schedule is running. First distinguish the app's timer, manual backups and actual file-write failures.
Why are no new backups created after restart when the switch is on?
In official issue #8331, a user on Windows 11 with Clash Verge Rev v2.5.8 configured backups every 1 hour. After fully quitting and reopening the app, they left the settings unchanged and the device awake for more than 1 hour, yet saw neither an automatic archive nor a corresponding Backup log entry.
After that user changed a setting and waited another full interval, a scheduled backup appeared. This comparison helps identify the problem; changing an arbitrary setting after every launch is not a lasting fix. You do not need to keep changing the language, proxy or subscription to investigate it.
This guide draws on that Windows report, the shared backup code and the official fix notes. It does not claim that every platform or older version was tested and found affected. The issue is officially fixed in v2.5.9. First rule out normal timing conditions, such as an incomplete interval or an app that has already exited.
Distinguish these three kinds of backup evidence
| What you see | What it shows | What it does not prove |
|---|---|---|
| A successful manual local backup | A local archive can be created now | The scheduled task has started after restart |
| A filename containing -auto-merge or -auto-script | A global override or script change triggered a backup | The -auto-scheduled backup schedule is working |
| A successful WebDAV upload | This upload to the server completed | The local schedule ran or uploaded automatically |
| A new -auto-scheduled.zip and a successful Scheduled log entry | This scheduled run actually created a local file | It will definitely work after the next full restart |
Create a manual backup and save a copy outside the app's data directory
Protect the current configuration before waiting for another scheduled backup. Open Settings → Verge Advanced Setting → Backup Setting. Under Local backup, click Backup, then open View history and export the new ZIP outside the app's data directory.
Check that the exported file exists and opens, then inspect profiles.yaml, profiles/ and your essential configuration. A ZIP is an archive, not encryption. It may contain subscription tokens, node passwords and local overrides, so keep it in protected storage that you control.
If a manual backup also fails, save the first error and make a separate copy of the existing data before investigating the file-write failure. Do not immediately attribute it to the schedule-after-restart defect, or experiment by emptying the app directory, restoring an old ZIP or uninstalling the app.
Keep these items before upgrading
- A current backup that opens and has been exported outside the app directory.
- The client version, backup-switch state, original interval and time of the last successful file.
- Your external files, original subscription URLs and essential settings, saved separately and securely.
- The redacted Backup error from the failure. Do not upload a complete ZIP or subscription credentials to a public issue.
The fix is in the v2.5.9 app, not a separate Mihomo update
Official PR #8386 explains that the old implementation sent the saved backup settings before the timer task subscribed. With no receiver, send on the watch channel did not retain the new value. The task that started later therefore read the default disabled state and waited for another settings change.
The fix replaces both the startup and settings-refresh sends with send_replace, so a task that starts later can read the saved value. It was merged and included in the stable v2.5.9 release published on 11/2/2026. An issue being closed or a development-branch change alone would not establish that a fix had shipped.
This is a backup-scheduling issue in the Clash Verge Rev app. Updating only the Mihomo core, refreshing a subscription or restarting the core cannot replace updating the app. If you already run a later stable release with separate evidence that it includes this fix, there is no need to downgrade to v2.5.9 for this guide.
The app's own timer task creates local backup files. It is neither a separate operating-system backup service nor a calendar task that runs at a particular time each day. Do not expect backups while the app is fully exited, or assume it will catch up on missed backups when reopened.
Update from the official release page and keep the existing configuration
The stable fix verified for this guide is Clash Verge Rev v2.5.9. Use the official v2.5.9 Release linked in the references and choose your operating system and processor architecture. This maintenance run did not update the installers hosted on this site; an older v2.5.8 mirror is not the fixed package.
Update the app using its existing installation method
Save the external copy before preparing the official update
Keep the ZIP exported above, the current data and your external files. Use an officially supported update method and retain the existing installation location. Do not mix in a portable directory, development build or package of unknown origin.
Quit normally and install when a connection interruption is acceptable
Save your work, stop the system proxy or TUN using the client's supported controls, then fully quit the app from the tray and update through the platform's normal installation procedure. Closing only the window, manually replacing the internal core or deleting app data is not this procedure.
Reopen and confirm the app version and original configuration
Check the full app version in Settings and confirm that v2.5.9, or a later stable release with evidence of this fix, is actually running. Check the Profile, overrides and original proxy mode, then restore the connections you need. A closed installer window alone does not confirm completion.
If you cannot obtain the official package or installation fails, keep the working environment and the error, then resolve that download or installation problem first. Do not disable signature checks or security protection, or treat an older package being downloadable on a website as a successful update.
Wait a full interval after restart, then check the ZIP and logs
Under Backup Setting → Automatic backup, check Enable scheduled backup and Backup frequency. The pinned v2.5.9 code defaults to 24 hours and allows 1–168 hours. You may temporarily choose 1 hour for observation; record the original value, save, then fully quit and reopen the app.
Start timing from this reopening. Keep the app running and the device awake, without changing settings or restarting. Do not edit global overrides or scripts to trigger other backups. Wait longer than a full interval; the absence of a file immediately after launch is not evidence of failure.
Restarting the app or receiving a settings notification starts a fresh full interval. Repeatedly saving settings can keep postponing the observation point. Distinguish this from a schedule that remains enabled but never runs despite a long period with no settings changes.
After the interval, open Local backup → View history, look for a new file and check for Auto backup created (Scheduled) in the logs. A scheduled archive ends in -auto-scheduled.zip. An -auto-merge, -auto-script or manual file alone does not complete this verification.
Confirm that the schedule works after restart
- The running app includes fix #8386, scheduled backups are enabled and the interval is recorded.
- After fully quitting and reopening, the app has run continuously for longer than a full interval with no further settings changes.
- A new -auto-scheduled.zip and a successful Scheduled log entry have matching times; the archive opens and contains the current configuration.
- After the next normal restart, check again under the same conditions. One successful run does not replace verification after restart.
- Restore the original interval or choose the interval you need, and retain the external copy. Saving starts the next waiting period again.
The pinned code keeps only the latest 20 automatic archives carrying the -auto- marker. Scheduled backups and those triggered by global override or script changes share this limit; it is not 20 for each kind. The local directory is not a permanent history store, so export known-good backups separately.
We have not waited an hour or performed a restore experiment in a real Clash Verge Rev client. These acceptance steps come from the official user report and pinned source code. Passing this site's page, translation and build checks cannot replace checking scheduled backups on your device.
If it still does not run, first check whether a manual backup can be created
Manual backups fail too
Keep the first write error and a copy of the current data. Check the path, permissions or available space identified by the error. Do not keep toggling scheduled backups and obscure the actual file-write failure.
Manual backups work, but the schedule creates no new files
Check the app version, switch state, time of the last launch or settings save, and whether the app ran continuously for a full interval. Save the relevant logs rather than reporting only that the enabled switch does nothing.
Only the WebDAV upload fails
Investigate the server address, authentication and upload error separately. If a local Scheduled archive already exists, an upload failure does not show that this scheduling fix failed.
The app or original configuration stops working after the update
Stop making changes. Save the current state and first error separately, then use the project's supported procedure to recover with the safe, working pre-upgrade app and its matching external data copy.
If only the scheduled task fails, continue creating and exporting manual backups. Do not restore over the current configuration merely to test the schedule. If an app rollback or data restore is genuinely needed, fully quit first and keep independent copies from before and after the upgrade. Do not let old and new app versions compete for the only data directory.
The older app may still have this defect: rollback is an emergency measure, not a scheduling fix. After restoring the app and data, check the original Profile, overrides, proxy mode and real connections. Continue saving manual backups externally, and verify the schedule by waiting again as described above.
When reporting to the project, provide the operating system, full app version, original interval, actual launch and settings-save times, manual-backup result, scheduled filename and first redacted error. Do not upload the complete ZIP, subscription link or credentials, or report tests on other platforms that you did not perform as passed.
References
- Clash Verge Revv2.5.9 stable release: scheduled backups after restart fixed
- Clash Verge RevUser report #8331: the v2.5.8 schedule does not run after restart
- Clash Verge RevFix #8386: retain backup-schedule settings at startup and refresh
- Clash Verge RevPinned v2.5.9 source: timing, triggers and automatic-archive retention
- Clash Verge RevPinned v2.5.9 UI: manual local and WebDAV backup controls
- Clash Verge Revv2.5.9 Chinese UI: backup switches, interval and history labels
- Clash Verge RevPinned v2.5.9 source: configuration included in a backup ZIP
