Chrome Profile Restore from Local Backup with Sync Enabled — Merge Behavior and Integrity Verification Gaps

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?