Why Does Remote Sync Recopy an Entire Folder After Reconnecting?

Remote sync recopies an entire folder when the client can no longer prove that the local and remote files are the same.

After a laptop, NAS, mounted share, or remote peer reconnects, the sync engine may rebuild its index, see a different filesystem identity, lose stored hashes, detect changed timestamps, treat renamed files as new objects, or compare against an outdated database. The correct diagnosis protects both copies first, then determines whether the client is rescanning, rehashing, re-downloading, or actually retransferring data before resetting any library.

Confirm Whether the Client Is Scanning, Hashing, or Transferring

Record network throughput, disk reads, CPU use, client status, and log messages during the apparent recopy. A full scan or checksum pass can look busy for hours without sending the full folder across the internet.

An rclone discussion describes how checksum mode can repeat checksum processing on every run. That behavior consumes storage and CPU but differs from a true network retransmission.

Use per-file transfer counters or packet totals to classify the event. If only metadata and hashes are read, optimize scan state; if full payload bytes move again, continue with identity, index, timestamp, and rename tests.

Check Whether the Sync Database or Index Was Rebuilt

Inspect the client logs around the reconnect for database migration, corruption, missing index, reset, rescan, or first-run messages. Compare the client configuration directory and database timestamp with the last successful sync.

A Syncthing support case explains that a corrupt index database may need to be rebuilt, making the device behave as if folders were newly added and potentially causing a large initial rescan.

Back up the database before deleting or resetting it. If the recopy started immediately after an app reinstall, container recreation, profile reset, or database loss, preserve the good data and use the client’s supported reconnect-to-existing-folder workflow.

Compare File Identity Beyond the Filename

Select several files that the client wants to recopy and compare size, modification time, checksum, permissions, ownership, case, extended attributes, and path on both sides. Record which field differs.

FreeFileSync users discuss storing checksums because size and timestamps alone may not always prove that paired files remain identical, while checksum databases add their own state requirements. This illustrates why file comparison metadata matters after reconnecting.

If content hashes match but timestamps or permissions differ, correct clock, metadata-preservation, or comparison settings rather than retransferring content. If hashes differ, identify which side is authoritative before allowing automatic overwrite.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Check Whether the Folder Reconnected Under a Different Identity

Compare the mounted path, filesystem UUID, network-share name, drive letter, volume identifier, container bind mount, and case sensitivity before and after the disconnect. A familiar folder path can point to a different mount or an empty local directory.

Sync tools often store folder identity in a local database rather than trusting the displayed path alone. A remounted NAS share, replaced USB disk, changed Docker volume, or recreated client profile can therefore look like a brand-new target.

Stop syncing if the expected mount is absent or the folder points to local fallback storage. Restore the original mount and verify sample files before reconnecting the library to prevent deletions or duplicate downloads.

Test Whether Moves and Renames Are Being Detected

Choose one small folder, rename it while both peers are connected, and observe whether the client performs a metadata move or uploads every file as new content. Repeat after a disconnect and reconnect.

A Syncthing feature discussion notes that moves or renames can be treated as new transfers when the tool cannot match the changed paths through its existing index, producing delete-and-reupload behavior.

If the recopy follows a high-level folder rename, let the client complete its index exchange before making more changes. For large libraries, avoid simultaneous mass renames on multiple peers and keep versioning or backup protection enabled.

Reconnect Safely Without Resetting the Good Copy

Create a backup or snapshot of the authoritative side, pause synchronization, and test one small subfolder using the client’s existing-folder or re-link function. Do not click a generic reset or resync button before understanding its direction.

The ZimaSpace guide to restoring one shared folder safely provides the same containment principle for protecting unaffected data.

The issue is resolved only when reconnecting preserves the index, compares existing files without payload transfer, applies only genuine changes, and survives another disconnect. If the database repeatedly corrupts or disappears, fix the storage, shutdown, container persistence, or client-installation problem rather than accepting recurring full syncs.