GoodSync Versioning Recover Deleted and Overwritten Files
Deleted the wrong file, or synced an old copy over the new one? Before you panic, check the folder most GoodSync users never open. Your file may have been sitting in it the whole time.
✍️ Technical Anshu💻 File Recovery⏱️ 8 minute read
🎥 Jobs and the _gsdata_ folders appear throughout the video — this guide shows the recovery side of the same system
Every sync run makes small judgements: this file is newer, that one is a duplicate, this one was deleted. When GoodSync acts on those judgements it deletes and overwrites real files — and by design it does not have to destroy them. With the right option on, every file a job deletes or replaces is first moved into a saved history folder. That folder is the difference between “we lost Tuesday's accounts” and a two-minute copy-back. Here is where it lives and how to use it — including the honest cases where it cannot save you.
Inside the saved history folder — versions kept by date
Office Data\_gsdata_\_saved_
2026-10-21 20-00\
invoice-book.xlsx
2026-10-23 20-00\
invoice-book.xlsx (the good copy)
old-rates.docx
2026-10-24 09-15\
price-list-2026.xlsx
👆 The _saved_ folder inside a sync folder, with one subfolder per sync moment. Each holds the files that run deleted or replaced — the 23rd's invoice book is the one everyone thought was gone.
1
Where Deleted and Replaced Files Actually Go
Inside every sync folder, GoodSync maintains a hidden folder named _gsdata_ holding the job's state — and inside it, _saved_ holds the rescued files
The rule to remember: a file is saved on the side where it was deleted or replaced. If sync overwrote the copy on the laptop, the laptop's _gsdata_\_saved_ holds what was there before
Saved files are organised by the moment they were replaced, so you can pick the version from before the bad sync, not just any old copy
Do not delete the _gsdata_ folders to “clean up” a sync folder — alongside history they hold the state the job needs to know what changed. Deleting state forces a confused full re-compare
2
Switch It On — Last Version Only, or Multiple Versions
Open Job → Options and find the setting to save deleted and replaced files
Last version only (the traditional default) keeps just the most recent replaced copy of each file — small footprint, protects against the latest accident only
Multiple versions keeps a chain of earlier copies — choose this for files that change daily and whose mistakes are discovered late, like accounts and stock sheets
The trade-off is disk space, stated plainly: versions are real files eating real storage. A media folder churning gigabytes will grow a gigabytes-sized history. Set it per job, by how much the data hurts to lose
3
Bring a File Back — The Two-Minute Recovery
Stop the job first. If the job is still running on a schedule, pause it — you do not want the next run making decisions while you recover
Open the sync folder on the side where the file was lost, enter _gsdata_\_saved_, and find the subfolder from just before the bad moment
Open the rescued file and verify it is truly the version you remember — check a recent entry or figure inside it
Copy it back to its real location with a normal file copy. Then resume the job; on the next Analyze, GoodSync will see the restored file and treat it as the current version
4
The Honest Limits — When the Net Is Not There
The option was off — if saved versions were disabled for that job, the deletion was final on that side. Check the other side's saved folder and the Recycle Bin before giving up
Fast 1-way mode — the no-state fast mode of a job does not keep the recycle/history safety net. Speed was traded for exactly this protection
Retention passed — old saved versions are eventually cleaned up, and a full disk speeds that day. If the accident is older than your retention, the file is gone from here
It was never synced — a file created and deleted between runs may never have met the job at all. Versioning protects what the job touched, not everything on the disk
That is why versioning is a layer, not the whole strategy — pair it with a 1-way backup job to a destination nobody edits by hand.
🔴 Do this today, before you need it: open each of your important jobs, turn on saved versions, and deliberately recover one test file so your hands know the route. The first time you open _gsdata_\_saved_ should not be during a crisis. The video shows the job options screens where this setting lives.
🎥 Watch the Complete Video
Watch where the job options live in the video, then flip this one setting on every job that matters.
I cannot see any _gsdata_ folder in my sync folder. Where is it?
It is hidden by attribute in some setups and simply may not exist until the job has run. In File Explorer, enable View → Hidden items, and also look on the correct side of the job — the saved folder for a deletion lives on the side where the file was deleted. If the job never deleted or replaced anything, the _saved_ folder may still be empty or absent.
How long does GoodSync keep old versions?
Until its cleanup rules or your disk pressure remove them — treat the saved folder as a short-term safety net measured in days and recent runs, not as a permanent archive. For files you must be able to recover months later, keep a separate dated backup copy that no sync job touches.
Can I recover a whole folder that a bad sync emptied?
Yes, if saved versions were on: the emptied folder's files will be in that side's _saved_ history from the run that removed them. Copy the whole subfolder's contents back in one go, then run Analyze and read it carefully before syncing again — you want the restored files to be recognised as current, not re-deleted.
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 🙏