You started the first sync an hour ago and it says 14 percent. Before you cancel it in disgust, understand what a first sync must do — then remove the four things that make it slower than it should be.
🎥 The Analyze and Sync screens in the video are where these speeds show — this guide explains what the numbers mean
A first sync is the worst sync a job will ever do, for a simple reason: every single file must physically travel once. GoodSync's later runs look magical — only changes, only changed blocks — but nothing can delta-copy data that has never arrived. So a big first sync taking hours can be completely normal. That said, “normal” is often hiding fixable waste: a WiFi link doing a wired job's work, a single copy thread crawling through ten thousand small files, or antivirus software inspecting every file twice. Diagnose first, then tune.
Reading a slow sync — three very different bottlenecks
WiFi link35 Mbps
Same job, LAN cable920 Mbps
10,000 small filesslow anyway
A 200 GB first sync: about 13 hours on that WiFi — or 30 minutes on the cable
👆 The maths of first syncs. Most “GoodSync is slow” reports are the first row in this panel — a network doing exactly what physics allows.
1
Fix 1 — Measure the Real Bottleneck Before Touching Settings
Check the job's running speed in the sync window, then ask which is slower: the source disk, the network, or the destination. The slowest of the three is your speed — no setting changes that
Copying to a USB 2.0 pen drive or an old external disk? That device's write speed is the ceiling. A 200 GB job onto a 25 MB/s drive takes over two hours of pure writing, perfectly healthily
Thousands of tiny files (browser caches, node_modules, thumbnail folders) sync far slower than the same gigabytes in big files — every file pays connection and checking overhead
Watch Task Manager while it runs: disk at 100% means storage-bound; network pegged means link-bound; neither busy means the job's own settings are the brake — that is Fix 2
2
Fix 2 — Let the Job Copy in Parallel Threads
Open Job → Options → Advanced and raise the number of parallel copy threads — GoodSync is multi-threaded by design, and a single-threaded crawl through a big folder tree leaves most of your network idle
Raise it in steps (for example 4, then 8) and watch the speed — past a point, a spinning hard disk on the other side becomes the limit and more threads stop helping
If an option to compare file contents by checksum (MD5) is enabled on the job, know its price: every file gets read end-to-end for comparison. It is a paranoia setting for special cases, not a default for big first runs
3
Fix 3 — Stop Syncing Files Nobody Needs
Use Filters in Job Options to exclude the usual dead weight: temp folders, caches, Thumbs.db, browser profile caches, and application scratch data
Never include whole system folders in a data job — syncing C:\Windows or program folders is hours of copying that cannot even be restored usefully. GoodSync's own advice is to back up data, not the operating system
Split the job: one tight job for the important 5 GB that must land today, one bulk job for the 195 GB archive that can run over the weekend. The important files stop queuing behind the archive
4
Fix 4 — Seed the Destination Instead of Sending Everything
The professional trick for a huge first sync to a far-away or slow destination:
Copy the data to the destination by hand once — external disk carried over, or a fast local connection — into the exact folder the job will use
Then run the job's Analyze. GoodSync compares both sides, recognises the identical files, and transfers only the small differences that accumulated since
This is called seeding, and it turns a two-day internet first-sync into an overnight disk trip plus a ten-minute job. It works for cloud destinations too if the cloud app can ingest the local copy first
Guard the one rule: the seeded copy must be a faithful copy placed in the same folder layout — a shifted folder tree makes Analyze treat everything as new anyway
5
Fix 5 — Remove the Invisible Brakes
Antivirus real-time scanning inspects every file as it is written — on a first sync that is the entire dataset, scanned. Excluding the destination folder from real-time scanning during the seed run (and only then) can double throughput
Locked files make jobs pause and retry — GoodSync can copy many open files using Windows shadow copies (VSS), but the cleanest first sync of office data happens with the applications closed
Cloud relay vs direct: a GoodSync Connect job forced through a relay path is slower than a direct connection; a wired LAN job should be reaching near-network speeds. If it is not, the cable, switch or WiFi — see Fix 1 — is telling you something true
And the final comfort: judge the job by its second run. If run two finishes in a minute with three files copied, the system is working exactly as designed.
🔴 When slow actually means stuck: progress frozen at the same file for a very long time, repeated error lines about one path, or a job that restarts its Analyze forever. That is a sick file, a dying disk or a permission wall — read the job log for the named file instead of letting it churn. Normal slow has a moving progress bar and a boring explanation. The video shows both screens so you can tell them apart.
🎥 Watch the Complete Video
Watch the Analyze and Sync progress in the video, so your first big job's numbers read as information, not anxiety.
Divide your data size by the slowest link in the chain. 100 GB at a true 100 Mbps is roughly two and a half hours; the same 100 GB onto a slow external disk at 30 MB/s is about an hour of pure writing — plus per-file overhead if the data is millions of small files. If your estimate and the job's estimate are in the same world, it is normal, not broken.
Will increasing threads always make sync faster?
No. Threads help until the disk or network saturates — after that they just queue. On fast SSD-to-SSD LAN jobs, more threads help a lot with many small files. On a job writing to an old spinning external disk, two threads may already be its ceiling; watch the speed as you raise the number and stop when it stops improving.
My first sync to Google Drive is far slower than my internet speed test. Why?
Speed tests measure one fat stream to a nearby server. A first sync is thousands of separate file uploads with per-file overhead, often over long distance, and cloud services also throttle sustained bulk uploads. Seeding through the cloud provider's own desktop app first, then letting GoodSync take over the differences, is the standard workaround.
This guide is based on the Technical Anshu GoodSync Explained video • Stuck on any step? Ask in the video comments — you will get a reply there 🙏