Clash Verge Rev Profiles Disappeared After Restart: Backup and Recovery

First check what is missing after restarting Clash Verge Rev v2.5.2: whether multiple subscriptions, local Profile entries, or global Merge/Script disappeared together and overrides returned to empty templates. A Profile is a configuration saved by the app. If this scope matches, check the startup logs for file deletion; a single subscription update failure or empty node list needs separate investigation.

Official issue #7577 records 30 of 32 Profile files being deleted during startup on macOS. Issue #7804 records 18 of 20 files being deleted on the next Fedora startup after a normal shutdown, with later comments also reporting Windows and macOS cases. These reports point to orphan-file cleanup during startup, not a subscription provider simultaneously removing every node.

Open the app log first and look for Removed file, Profile 文件清理完成, and an unusually high deletion count during a single startup. If the Profile still exists on disk and only the Proxies page is blank, troubleshoot core communication first. If the file exists but reports Invalid YAML, fix its formatting or fields first. If only one subscription update failed while other Profiles remain, do not immediately restore the entire app backup.

Restoring a backup rewrites the app data directory with config.yaml, verge.yaml, profiles.yaml, and the profiles directory from the archive. First copy the entire current directory and its clash-verge-rev-backup subdirectory to another location.

Keep a copy even if the current directory already looks incomplete. If you select the wrong backup or an old configuration overwrites newer changes, that directory copy lets you return to the state before the restore.

A standard installation usually stores data in the io.github.clash-verge-rev.clash-verge-rev folder under the system data directory. A portable installation uses the .config directory next to the program instead. If you are unsure, use the app-directory shortcut in the client settings. Do not delete data based only on a similar folder name.

Clash Verge Rev v2.5.2 stores local backups in clash-verge-rev-backup inside the app data directory. Automatic backup filenames may include -auto-scheduled, -auto-merge, or -auto-script.

The official v2.5.2 backup includes the profiles directory, config.yaml, verge.yaml, optional DNS configuration and profiles.yaml in one ZIP. The reporter in issue #7804 recovered a global script from an auto-script ZIP made three days earlier. This type of backup may contain the complete configuration, not just a script.

Do not restore a ZIP merely because it opens. Copy it first, confirm that the archive contains both profiles.yaml and profiles/, then choose the newest one created before the failure.

The fixed v2.5.8 source no longer calls Profile cleanup at startup and preserves files if the configuration index fails to load. To upgrade, get the package for your platform from the official v2.5.8 Release. Keep your complete backup: upgrading cannot recover content that was deleted without a backup.

After installation, check the app version first. Recover missing content from a backup or its original source using the following sections. After recovery, check the Profile count and a real connection, then fully quit and restart the app to check again. Keep the current backup.

Keep the system proxy and TUN off. Go to Settings → Verge Advanced Settings → Backup Settings → Local Backup → View History. Select a backup from before the failure, export it outside the app data directory, then click Restore and confirm. Wait for the app to restart automatically; do not force it to quit. Check the Profiles after restart before enabling the proxy.

If the ZIP was moved elsewhere, use "Import Backup" to add the copy to the local backup list, then restore it from the history. Do not extract the ZIP directly into the directory of a running app. Built-in recovery reloads config, profiles, and interface settings after writing them; manual replacement can leave the files on disk out of sync with in-memory state.

When no usable ZIP exists, do not invent profiles.yaml references or arbitrarily rename randomly named files. Reimport each remote Profile from its saved subscription URL. For a hand-written local configuration, identify the copied profiles files from before the failure one at a time, create a new local Profile, paste in the content, and let the client regenerate the index relationship.

If an older copy of the global Merge.yaml or Script.js still exists, compare it in an offline copy first, then restore it through the client's global extension editor. Rewrite it only when no older content exists in any backup. Do not reconstruct complete rules that may contain secrets or internal domains from public screenshots.

If the subscription URL is also lost, retrieve or reset it through the original provider instead of piecing together a token from browser history, public logs, or someone else's configuration. Save the state after restoring each source so that a problem is traceable, rather than importing everything at once.

Do not enable TUN immediately after the app restarts. Check the Profile count, names, types and selected entry. Open Merge and Script to ensure key rules are not empty templates. Remote subscriptions should update manually, and a local Profile should pass validation and start Mihomo.

Next, select one known-good node, enable only the system proxy, and complete a real HTTPS request. Confirm the domain, rule, and outbound in Connections. Finally, fully quit and reopen the app once more, then check the Profile count and logs again. Recovery is stable only if the second startup also shows no abnormal deletions.

If restoring prevents startup, reduces the Profile count or fails configuration validation, fully quit from the tray and confirm the related processes have stopped. Do not try multiple ZIP files in succession. Save the restored directory and logs separately, then restore the entire original directory copy without mixing in unknown backups.

Keep TUN and the system proxy off first. If the client still does not work after rollback, leave it closed for now. Preserve the log, backup ZIP, and directory copy, then submit the redacted version, operating system, deletion count, and first error to the official issue. Do not uninstall virtual adapters, reset the entire system network, or delete all app data to repair a configuration.

After recovery, enable scheduled local backups in Backup Settings and keep “Back up automatically on critical changes” enabled. The v2.5.2 implementation creates archives on schedule and after global Merge/Script changes, retaining up to 20 automatic archives. This limit means the local directory is not a permanent history.

Export at least one verified ZIP outside the app data directory, or configure a WebDAV service you control. Before a major subscription-override change, client migration, or upgrade, manually create and export a backup. Run recovery drills only when a rollback copy is available.