Why Does a Cloud Sync Job Re-Upload Previously Deleted Files After Its State Database Is Restored?
A restored sync database can re-upload deleted files when it no longer contains the deletion records that distinguished intentional removal from newly discovered local data.
Two-way sync relies on more than the files currently visible. It keeps an index or database of prior paths, versions, device IDs, tombstones, and synchronization state. Restoring an older database while leaving newer local files or cloud state in place creates a time mismatch: the client may scan a surviving local copy as new, or interpret the remote deletion as a conflict. Pause every sync participant before deciding which timeline is authoritative.
Confirm Which Database and File Tree Were Restored
Record the database backup time, local file-tree time, cloud state, client configuration, device identity, and the first re-upload event. Check whether the database and files came from the same recovery point.
Nextcloudโs restore procedure requires restoring the database and data directory as one consistent system, because restoring only one layer creates metadata that no longer matches stored files.
If the database predates the deletion but the local tree contains an older surviving copy, a re-upload is predictable. Preserve all three states before allowing another automatic synchronization pass.
Check Whether Deletion Tombstones Were Rolled Back
Identify whether the restored state contains the deletion event, file version, remote item ID, and device that originally removed the file. Compare logs from immediately before and after the deletion.
Syncthing keeps a local index database and warns that a database reset forces a full rescan and resync; if an older mounted file tree appears later, inconsistent versions can result.
A deletion that existed only in the newer database is absent after rollback. The next scan sees the remaining file but lacks the historical evidence that it should stay deleted.
Review Stateful Bisync or Two-Way Listing Files
For tools such as Rclone Bisync, locate both prior listings, working directory, lock state, and last successful run. Do not treat a fresh resync as equivalent to continuing from valid state.
Rclone documents that Bisync is stateful across successive runs and stores working data separately from the synchronized folders.
Restoring or deleting those listings can erase the distinction between โdeleted since last runโ and โexists only on this side.โ Use a dry run and save both listings before rebuilding state.
Update the Server Fingerprint After a Database Restore
Check whether the server platform provides a recovery marker that tells clients the database was restored. Apply it before clients reconnect.
OwnCloud instructs administrators to run maintenance:data-fingerprint after restore so desktop and mobile clients can recognize the recovered server state.
Without a changed recovery fingerprint, clients can continue from assumptions created against the later database. This can produce conflicts, re-uploads, or attempts to delete objects restored on the server.
Identify Local Copies That Survived the Cloud Deletion
Search every synchronized device, offline folder, excluded path, recycle bin, conflict directory, and temporary recovery folder for copies of the deleted file.
Dropbox explains that deleting an item can remove it across synchronized devices, but copies owned elsewhere or no longer participating in the same synchronized state can remain.
A surviving local file becomes a candidate upload when the restored database no longer recognizes it as the old deleted object. Hash and quarantine it outside the sync root before reconciliation.
Pause Clients Before Resetting or Rebuilding Sync State
Stop server sync workers and pause every desktop, mobile, container, and scheduled sync client. Reconnect one authoritative endpoint first.
Microsoftโs OneDrive reset procedure states that the client rebuilds its local DAT file, illustrating why a reset changes client state without deciding which historical file version should be authoritative.
Reset is not a substitute for choosing the correct timeline. If several clients rescan simultaneously, one can upload an old local copy while another propagates the deletion.
Reconcile One Folder With a Dry Run and Independent Backup
Export the restored database, copy all conflicting local files outside sync roots, choose the authoritative state, and test one small folder before resuming the whole library.
The ZimaSpace 3-2-1 backup guide provides the adjacent boundary: sync state is not an independent recovery copy when it can replay deletion or re-upload obsolete data.
The issue is resolved when deleted files remain deleted, intended survivors upload once, conflicts are documented, and a second controlled sync produces no unexpected resurrection.
Frequently Asked Questions
Does restoring the database also restore deletion history?
Only up to the database backup time. Deletions recorded after that point are absent unless another log or endpoint preserves them.
Should all sync clients remain connected during recovery?
No. Pause them and reconnect one authoritative endpoint first so older clients cannot immediately reintroduce stale files.
Will a full rescan safely fix the problem?
A rescan rebuilds what currently exists, but it cannot infer missing historical intent. It may re-upload surviving files unless the authoritative state is chosen first.
Recommended products
Support & Tips
More to Read
Why Does a Docker Volume Restore Recreate File Contents but Drop Extended Attributes?
A volume-restore diagnosis covering xattr inventory, tar and Rsync options, namespaces, destination support, privileges, labels, app metadata, and tests.
Why Does a Running Container Keep Its Old Memory Limit After the Compose File Changes?
A memory-limit diagnosis covering live cgroups, restart versus recreation, Compose fields, hard and soft limits, parent scopes, swap, and runtime heaps.
Why Does Restarting a Reverse Proxy Invalidate Every Session for One Self-Hosted App?
A session-loss diagnosis covering restart scope, cookie ownership, secret rotation, cache-backed sessions, sticky routing, auth gateways, and recovery.
