Cloud Merge vs. Restore: Which Should You Use When Two Devices Have Different Vault Data?

Two devices can both contain legitimate vault changes. A phone may hold a password created this morning while a laptop has a secure note edited last night. The cloud backup may be newer overall but still lack an item that exists only on the current device. At that point, “download the latest backup” is not a complete decision. The user must choose whether the cloud copy should replace this device or whether cloud changes should be reconciled into what is already here.

That distinction matters because restore and merge express different intent. Restore declares one backup authoritative for the target device. Merge says both copies may contain value. Confusing those actions can either discard useful local work or retain data that the user expected to replace.

Quick answer

Use Restore from Cloud when the selected cloud backup should become the vault state on this device—for example, when setting up a replacement phone with little or no local data. Restore replaces the local encrypted database. If the selected backup is a complete bundle, it also replaces the encrypted file generation. A database-only restore changes the database while preserving the current file generation, so its narrower contents should be understood before use.

Use Merge from Cloud when the local device and cloud backup both contain changes worth keeping. Krypt matches records by stable sync identity, imports cloud-only records, preserves local-only records, and updates a matching local record only when the cloud record has a newer sync timestamp. Database changes are applied in one SQL transaction. For a complete bundle, encrypted file blobs are staged and copied with rollback cleanup; superseded ciphertext is removed after the database transaction succeeds.

Merge is deliberate cloud-to-local reconciliation, not continuous bidirectional sync. After checking the combined local result, run Sync to Cloud to publish it. Newer-wins also does not decide which edit is more meaningful. It is a deterministic rule, not semantic conflict resolution, version history, or collaboration.

Merge and restore answer different questions

NIST SP 800-184 treats recovery as a planned and tested capability rather than an improvised download. Its emphasis on realistic recovery scenarios applies here: the operator should understand which state is being recovered, choose the correct action, and verify the result. NIST SP 800-209 likewise includes data protection, isolation, restoration assurance, and encryption among storage-security concerns. A correct choice is part of restoration assurance.

Restore is replacement, not reconciliation

Restore is the simpler mental model because it has one source of truth: the selected cloud backup. Krypt verifies that the cloud artifact belongs to the unlocked real vault context before committing it. The restore screen warns that local data on this device will be replaced and shows local and cloud summaries so the user can pause before choosing.

A complete cloud bundle includes the encrypted database and the encrypted file generation represented by that bundle. Krypt downloads it to temporary storage, verifies the outer cloud-backup metadata, prepares and authenticates the complete bundle for the expected vault and purpose, stages its database and files, and commits the replacement through the restore coordinator. That path is appropriate when the complete cloud generation is the state the user wants on the device.

A database-only cloud backup is narrower. Its restore replaces the local database through a staged database operation while preserving the device's current encrypted file generation. It should not be described as a complete media restore. The current interface identifies backup contents; users should read that summary instead of assuming every backup includes files, albums, and identity-document attachments.

Replacement is often the right choice on a new device. It can also be the wrong choice on a device that has unsynced local work. A locally created password or note that never reached the selected cloud generation cannot appear after replacement merely because another cloud record is newer. Back up the current local state before replacing it when there is any doubt.

Merge reconciles records by stable identity

Database row numbers are local implementation details. The same logical password may be row 12 on one device and row 47 on another, so Krypt cannot safely merge by integer primary key. Syncable records instead receive a stable sync_id that travels with the record. Krypt also maintains sync_updated_at, a timestamp used to compare two representations of that identity.

When older records lack those fields, the merge preparation adds the sync columns where necessary, creates sync-ID indexes, assigns a cryptographically random sync identity to records that need one, and stamps a version time from available updated, deleted, or created timestamps. Future ordinary updates advance the sync timestamp through database triggers when the identity itself has not changed.

The merge then evaluates cloud rows one table at a time. A cloud record with no matching local sync_id is inserted. A matching cloud record whose version is greater than the local version replaces the local row. A matching record that is older or equal is skipped. A local record absent from the cloud input is left alone. That is how cloud-only insertion and local-only preservation can coexist.

This rule depends on identities and timestamps being carried forward correctly. It is not a content-based duplicate detector. If two devices independently create equivalent records with different sync IDs, both can remain after merge. Conversely, if both edit one shared identity, only the newer timestamp determines which complete row wins. Krypt does not merge the username from one copy with the note from another, and it does not infer that a password rotation is more important than a later cosmetic edit.

Because those versions ultimately depend on device time, a badly incorrect clock can also distort the ordering. Before reconciling important changes, let both devices obtain accurate time automatically and inspect surprising results instead of repeatedly merging. Timestamps provide a consistent comparison rule; they are not proof that an edit happened in the order a person remembers.

Database-only and complete-bundle merges cover different categories

A database-only cloud backup merges the categories that the product identifies for that path: passwords, passkeys, and secure notes. It does not claim to import encrypted file blobs, folders, albums, or identity-document attachments. This is intentional. A database artifact cannot provide file bytes it does not contain.

A complete bundle can include passwords, secure notes, passkeys, folders, encrypted files, albums, identity documents, and the relationships among those categories. Krypt merges folders before files so parent references can be translated from cloud row IDs to local row IDs. It then maps album and identity-document relationships to the corresponding local IDs. Relationship rows that cannot be mapped safely are skipped instead of inventing a reference.

For encrypted files, the merge copies the incoming staged ciphertext before updating the database row that will reference it. If the preferred path already exists, Krypt creates a unique target rather than overwriting bytes blindly. If the SQL transaction fails, Krypt attempts to delete copied blobs in reverse order. Once the transaction succeeds, it also attempts to remove replaced blobs that are no longer referenced. Both cleanup paths are best-effort: a deletion failure can leave unreferenced ciphertext, although a committed database continues to point to the new encrypted generation.

One SQL transaction protects the database boundary

Passwords, notes, passkeys, files, folders, albums, and relationship changes must agree as one database result. Krypt runs the local database merge inside one transaction. If record processing throws an error, the transaction does not intentionally commit a half-merged set, and the complete-bundle path attempts to remove blobs copied for the failed attempt. Because that filesystem cleanup is best-effort, deletion errors can leave unreferenced encrypted blobs even though the database transaction rolls back.

SQLite's official transaction documentation explains the BEGIN, COMMIT, and ROLLBACK boundary and notes that only one write transaction can be active at once. Its atomic commit documentation describes the goal that all database changes in a transaction appear to occur or none do, including interruption handling under SQLite's documented filesystem assumptions.

The SQL transaction does not magically make external files part of SQLite. Krypt therefore couples database atomicity with explicit blob staging and cleanup. That is a practical cross-resource strategy, not a claim that a database transaction alone can roll back every filesystem operation. Storage exhaustion, permission failures, hardware problems, and operating-system interruption remain real reasons to keep separate recovery backups.

Authenticate the cloud artifact before trusting its timestamps

A deterministic merge is only useful if the input belongs to the intended vault. Krypt scopes cloud access to an unlocked real vault and an unlock-session generation. The selected backup must be owned by that vault context. Download verification checks the artifact against signed cloud metadata, including its expected vault, name, kind, length, and digest.

Current metadata is authenticated with a keyed construction, so an attacker cannot simply replace both the downloaded bytes and nearby unkeyed metadata without the relevant vault key. NIST FIPS 198-1 defines HMAC as message authentication using a cryptographic hash function and a shared secret. For complete bundles, Krypt also validates the authenticated archive manifest, expected complete_cloud_sync purpose, exact member inventory, database, encrypted files, and vault identity before merge reads the staged database.

Authentication does not certify that every user edit was wise or that the newest record is the desired one. It establishes that the protected bytes and metadata agree under the expected secret and context. Human intent still determines whether to restore, merge, or stop and inspect another backup generation.

Krypt's answer: make the direction and consequence explicit

Krypt is a zero-knowledge password manager whose optional cloud workflows never give the storage provider the plaintext vault key; uploaded recovery metadata includes only a Rescue Key-wrapped copy. For Krypt Pro users in an unlocked real vault, the cloud screen presents separate actions: Sync to Cloud uploads this device's vault, Restore from Cloud replaces this device with a selected backup, and Merge from Cloud imports cloud changes while retaining local-only records.

That separation prevents the word “sync” from hiding a destructive choice. If the device appears nearly empty, the interface points toward restoration rather than uploading an empty state over the existing cloud backup. If local and remote modification evidence conflicts, the decision screen shows summaries and offers explicit restore, merge, or local-upload directions.

On merge, Krypt uses stable identities and timestamps, applies database changes in one transaction, and performs staged encrypted-blob cleanup for complete bundles. The user-facing result summarizes records added, records updated, and file blobs copied; skipped counts remain internal. The user can then inspect representative records and files before running Sync to Cloud.

This is not automatic bidirectional synchronization. Merge does not remain connected, watch another device, or push its result back to the provider. It is not shared-vault collaboration, multi-user edit history, a field-level diff, or a deletion-conflict console. It works only with Krypt Pro cloud access, an unlocked real vault, compatible backup categories, and the same vault context. The decoy vault is not a cloud-merge target.

Decision checklist before two vault copies converge

1. Confirm which real vault is unlocked. Do not proceed because two vault labels merely look similar.
2. Review the selected backup time, kind, and item summary. Determine whether it is database-only or a complete bundle.
3. Ask whether the local device contains any password, passkey, secure note, file, album, or identity-document change that never reached cloud.
4. If the device is empty and the cloud backup is authoritative, choose Restore from Cloud.
5. If both copies contain useful changes, choose Merge from Cloud and expect newer matching cloud records to replace older local rows.
6. Create a current recovery backup before a consequential restore or merge, and keep the required Recovery Kit or Rescue Key through a separate protected path.
7. After merge, inspect high-value accounts, recently edited notes, passkeys, and representative files. Look for duplicates created independently on two devices.
8. Run Sync to Cloud only after the combined local state looks correct. Then verify that the new cloud generation completed.
9. Check the other device before making new changes there; it may still hold an older local generation.

CISA's StopRansomware Guide recommends maintaining offline, encrypted backups and regularly testing their availability and integrity. That advice remains relevant even with a careful merge: reconciliation protects a local operation, while independent backups protect recovery options if the chosen source or decision was wrong.

For setup and upload behavior, see How Krypt Encrypted Cloud Sync Works. Cloud convenience should sit on top of a tested recovery plan, not replace one.

FAQ

Does Merge from Cloud delete local-only items?

No. Krypt keeps local-only records while importing cloud-only records. When the same stable sync ID exists in both copies, the cloud record replaces the local record only when its sync timestamp is newer. A merge can still change matching records, so inspect the selected backup and keep a current recovery copy before proceeding.

When should I use Restore from Cloud instead of Merge from Cloud?

Use Restore from Cloud when the chosen cloud backup should become the authoritative state on this device, such as a replacement phone with an empty vault. Restore replaces local database state, and a complete bundle also replaces its encrypted file generation. Use Merge when both the local and cloud copies contain changes worth preserving.

Does Merge from Cloud automatically update the cloud backup?

No. Merge from Cloud is a deliberate cloud-to-local operation. After reviewing the combined local vault, the user must run Sync to Cloud to publish that state as a new cloud backup. Until then, another device can still download the older cloud generation.

Does newer-wins merging understand which edit is semantically correct?

No. Krypt compares stable sync IDs and timestamps; it does not understand whether one password, note, file, or account decision is more meaningful than another. Newer-wins is deterministic reconciliation, not field-by-field semantic conflict resolution, version control, or multi-user collaboration.

Technical references

NIST SP 800-184 covers recovery planning, testing, improvement, and realistic scenarios. NIST SP 800-209 addresses storage data protection, isolation, restoration assurance, and encryption. The CISA StopRansomware Guide covers offline encrypted backups and integrity testing. SQLite documents transaction control and its atomic commit mechanism. NIST FIPS 198-1 specifies HMAC.

Use Krypt Pro to restore an authoritative encrypted cloud backup or deliberately merge cloud changes while keeping local-only vault records.