Question
Chrome Profile Restore from Local Backup with Sync Enabled — Merge Behavior and Integrity Verification Gaps
Lax Maple
0 reputation · 22 Sept 2022, 08:23 UTC
111.3K views
Loading…
0 reputation · 22 Sept 2022, 08:23 UTC
Restoring a Chrome profile from a local filesystem backup while Sync is enabled triggers an automatic merge between the restored SQLite databases (History, Bookmarks, Login Data, Web Data) and the Google cloud state. Chrome provides no built-in restore mode that pauses Sync, validates database integrity, or previews conflicts before merging. The merge can duplicate bookmarks, create conflicting password entries, or resurrect deleted history. Additionally, the Login Data database is encrypted with OS-bound keys (DPAPI on Windows, Keychain on macOS, libsecret on Linux), making cross-machine restoration impossible without the original encryption context. Bookmarks and History databases lack checksums or version headers, so corruption from incomplete copies may cause Chrome to silently rebuild indexes, showing empty or partial data without error reporting. Google's documented recovery guidance treats local backup restoration as an unsupported manual operation.
What specific merge rules does Chrome apply when local timestamps conflict with cloud timestamps during restore? How can an administrator verify the integrity of restored SQLite databases before Chrome processes them? Does Chrome expose any internal API or flag to pause Sync during a controlled restore workflow?
33275 reputation · 22 Sept 2022, 16:09 UTC
When a local profile folder is swapped into an installation that already has Sync enabled, Chrome treats the new SQLite files as a second data source and merges them with the cloud state. The merge is governed by the Sync protocol, not a dedicated restore mode.
chromeLogin Data database is encrypted using OS-bound keys (DPAPI on Windows, Keychain on macOS). Restoring this file to a different machine will result in Chrome being unable to decrypt passwords, as the underlying encryption context is missing.Since Chrome does not provide internal checksums for its profile databases, you must manually verify the SQLite files using the sqlite3 command-line tool before letting Chrome process them. This prevents Chrome from silently rebuilding corrupted indexes into an empty state.
Run the following command for critical files (History, Bookmarks, Web Data):
sqlite3 path/to/profile/History "--" "PRAGMA integrity_check;"If the output is ok, the database is structurally sound. If errors are returned, the file is likely corrupted or incomplete, and Chrome will likely discard it or fail to sync, leading to data loss.
Chrome does not expose an internal API or hidden flag to "pause" Sync during a restore. To prevent an automatic merge, you must manually disable Sync before replacing the files:
chrome://settings/syncAndServices and select Turn off under Sync.Diagnostic Question: Was the backup created from the same Chrome version and operating system as the current installation? Mismatched schemas can cause Sync to skip entries entirely.
Use comments to ask for clarification. Post a solution as an answer.
33,275 reputation · 22 Sept 2022, 15:39 UTC
The answer covers user databases but omits SyncData.sqlite3, which stores the Sync engine's local view of entity versions, server acknowledgments, and conflict resolution state. Restoring user databases (Bookmarks, History, Login Data) without this file causes the engine to treat all local entries as new, pushing stale or deleted data to the cloud.
SyncData.sqlite3 alongside user databases from the backup.sqlite3 SyncData.sqlite3 "PRAGMA integrity_check;" to confirm structural integrity.--disable-sync --user-data-dir=/test/profile and inspect chrome://sync-internals → Local State to verify pending commits match expectations before re-enabling Sync.This reduces duplicate propagation and provides a merge preview Chrome otherwise lacks.