Writing Software
Bulletproof Scrivener Backup: Never Lose Work Again
You opened Scrivener and your project won't load. Or the chapters are empty. Or the whole thing shows "zero bytes." Here's how to prevent that nightmare and recover if it happens.
Scrivener has a backup system. It runs automatically, in the background, without asking. The problem is that most writers never check if it's configured correctly until the moment they need it. By then, it's too late to change anything.
This guide walks you through two things: setting up your backups so you're protected before disaster strikes, and recovering your work if you're reading this in a panic right now.
If you're currently staring at a corrupted project, skip ahead to the recovery section. Otherwise, take fifteen minutes to configure your settings properly. Future you will be grateful.
Where Scrivener Stores Your Backups
Scrivener saves automatic backups in a specific folder on your computer. This folder is separate from your project files, and knowing where it is matters more than any other piece of information in this guide.
On Mac: The default location is ~/Library/Application Support/Scrivener/Backups inside your home folder. The Library folder is hidden by default, which is why many writers have never seen it.
On Windows: The default location is %LocalAppData%\LiteratureAndLatte\Scrivener\Backups, which typically resolves to something like C:\Users\YourName\AppData\Local\LiteratureAndLatte\Scrivener\Backups.
The fastest way to find your backup folder is through Scrivener itself. On Mac, go to Scrivener > Settings > Backup and click "Open backup folder." On Windows, go to File > Options > Backup and click the same button. A Finder or Explorer window will open showing your backup files.
Do this right now. Don't continue reading until you've located your backup folder and verified that it contains zipped files with recent dates. If the folder is empty or the files are months old, your automatic backups aren't working correctly.
Configuring Automatic Backups Correctly
Scrivener's backup system is flexible, which means you can configure it badly. Here's what each setting does and what you should choose.
Turn On Automatic Backups
This checkbox should be enabled. It's on by default, but some writers accidentally disable it while exploring the settings. Verify it's checked.
When to Back Up
Scrivener offers several triggers: when you open a project, when you close a project, when you manually save, and before syncing with mobile devices. You can enable multiple triggers.
The most reliable choice is "Back up on project close." This creates a backup every time you finish a writing session. If you're the type who keeps Scrivener open for days at a time, also enable "Back up with each manual save" so you get periodic protection during long sessions.
Avoid relying solely on "Back up on project open." If your project corrupts while you're working, the next time you open it, you'll back up the corrupted version and potentially overwrite a good backup.
Number of Backups to Keep
Scrivener lets you keep between 3 and 25 backups per project. It rotates these automatically, deleting the oldest when you exceed the limit.
Five backups works for most writers. If you open and close Scrivener multiple times per day, increase this to 10 or 15. You want enough history to go back several days if a problem goes unnoticed.
The trade-off is disk space, but compressed Scrivener backups are small. A 100,000-word novel with research materials might be 10-20 MB zipped. Even 25 backups would only use 500 MB.
Compress Backups as Zip Files
Enable this option. Zipped backups take slightly longer to create (a second or two), but they provide three benefits. First, they're smaller. Second, they transfer more reliably to cloud storage. Third, and most importantly, they're harder to accidentally corrupt.
A Scrivener project is actually a folder containing hundreds of small files. Cloud sync services can corrupt these packages if they sync incompletely. A zip file is a single file that either transfers completely or fails completely. No partial corruption.
Use Date in Backup File Names
Enable this option. It adds a timestamp to each backup filename, so you'll see something like "MyNovel Backup 2026-02-05 09-30-15.zip" instead of "MyNovel Backup.zip". When you need to recover, you'll immediately know which backup is most recent and can work backwards through time.
Choosing a Backup Location
The default location works, but consider moving your backups to a cloud-synced folder like Dropbox, Google Drive, or iCloud Drive. This gives you offsite protection: if your computer dies, your backups survive.
Click "Choose" in the backup settings to select a new location. Create a dedicated folder like "Scrivener Backups" inside your cloud storage. Never put backups in the same folder as your active projects. If something corrupts that folder, you lose both your project and your ability to recover.
One warning: Don't put your active projects in cloud storage without proper precautions. The backups are safe because they're zipped. Active projects are not. That's a separate topic, but for now, just know that backups in the cloud equals good, active projects in the cloud equals risky.
Manual Backups for Extra Protection
Automatic backups protect you from most disasters, but they rotate out old files. Before major revisions, create a manual backup you can keep forever.
Go to File > Back Up > Back Up To and choose a location. Name it something descriptive like "MyNovel Pre-Edit March 2026" so you'll recognize it later. This backup won't be overwritten by the automatic system.
I create manual backups before sending to beta readers, before major structural edits, and before any revision that might destroy passages I want to preserve. These permanent backups cost nothing and have saved me multiple times.
Snapshots: Version Control for Individual Scenes
Backups protect your entire project. Snapshots protect individual documents. They serve different purposes.
A snapshot is a frozen copy of a single scene or chapter, stored inside your project. Before you rewrite a scene, take a snapshot. If the rewrite fails, you can restore the original without affecting anything else in your manuscript.
To create a snapshot, select a document in the binder and press Cmd+5 (Mac) or Ctrl+5 (Windows). You can also go to Documents > Snapshots > Take Snapshot. Scrivener will timestamp it automatically. For clarity, add a title like "Before major revision" or "Version sent to editor."
View your snapshots in the Inspector panel. Select a document, open the Inspector, and click the Snapshots tab (the camera icon). You'll see all snapshots for that document with their dates.
The Compare feature shows differences between your current text and a snapshot. Select a snapshot and click Compare. Deletions appear as red strikethrough text, additions as blue underlined text. This is useful for reviewing what changed during revision.
If you want to restore a snapshot, select it and click Roll Back. Scrivener will offer to create a snapshot of your current version first. Accept this offer. You can always delete the extra snapshot later, but you can't undo a roll back without it.
Snapshots are not a replacement for backups. They only protect the documents where you've taken them. A corrupted project file can lose snapshots along with everything else. Use both.
Need Something to Put in Your Scrivener Project?
The 7 Essential Arcs gives you seven complete story structures to compare and build from. Pick the arc that fits your novel, then use Scrivener's corkboard to map every beat.
Get the 7 Essential ArcsFree resource. One of 75+ storytelling frameworks on Loreteller.
Recovering from a Corrupted or Lost Project
If you're reading this section, something went wrong. Your project won't open, shows empty documents, or displays a "zero bytes" error. Stay calm. Your backups probably have everything you need.
Step 1: Stop Syncing
If your project is in Dropbox, Google Drive, or any cloud service, pause syncing immediately. Right-click the cloud service icon in your system tray or menu bar and pause sync. You don't want the service to overwrite your backups with corrupted files while you're trying to recover.
Step 2: Find Your Backups
Open Scrivener (you can do this even if your project won't open) and go to Settings/Options > Backup > Open backup folder. Look for files with your project name and recent dates.
If the backup folder is empty or your backups are old, check cloud storage version history. Both Dropbox and Google Drive keep previous versions of files for 30 days by default. Right-click your project file in the cloud and look for "Version history" or "Previous versions."
Step 3: Copy the Backup Before Opening
This is critical. Do not open a backup file directly from the backup folder. Copy it to your Desktop or another safe location first. Scrivener's backup system might overwrite the file if you open it in place.
If the backup is a .zip file, copy the zip file first, then extract it. You'll get a folder or .scriv package that you can open in Scrivener.
Step 4: Work Backwards Through Time
Start with the most recent backup. Open it and check if your work is there. If documents are missing or empty, close it and try the next oldest backup. Keep going until you find a complete version.
You might lose some recent work depending on when the corruption occurred. A backup from yesterday is better than losing everything. Once you have a working version, you can manually recreate any missing recent changes.
Step 5: Check for Recovered Files
If the project opens but seems incomplete, scroll to the bottom of your Binder. Scrivener sometimes dumps recovered or conflicted files there when it detects problems. Your missing chapters might be waiting in a "Recovered Files" folder. Drag them back to their correct locations.
Dealing with Zero Bytes Errors
The "zero bytes" error usually indicates a cloud sync problem. The project's internal files were partially uploaded or downloaded, leaving empty placeholders.
First, make sure you're running the latest version of Scrivener. Older versions have more sync issues. Second, if the project is in Dropbox, right-click it and select "Make Available Offline" to force a complete download before opening.
If the project still shows zero bytes, it's probably corrupted beyond repair. Your recovery option is the backups. Follow the steps above to restore from your most recent complete backup.
Preventing Future Disasters
Most Scrivener data loss comes from cloud sync conflicts. The project format (a package of small files) doesn't play well with services that sync file-by-file.
The safest approach is keeping your active projects on your local drive and only putting zipped backups in the cloud. If you must sync active projects, use these rules: Only open the project on one device at a time. Wait for sync to complete before closing Scrivener. Wait for sync to complete before opening on another device. Never leave Scrivener open on multiple computers.
Set a calendar reminder to verify your backups monthly. Open the backup folder and check that recent files exist. It takes thirty seconds and catches configuration problems before they matter.
The Fifteen-Minute Setup
Here's the configuration I recommend for most writers.
Open Scrivener's backup settings. Enable automatic backups if they're not already on. Check "Back up on project close." Check "Compress automatic backups as zip files." Check "Use date in backup file names." Set the number of backups to keep at 10. Click "Choose" and select a folder in your cloud storage named "Scrivener Backups."
Close the settings. Open one of your projects. Close it. Go to your backup folder and verify a new zipped backup appeared with today's date. If it did, you're protected.
Every few months, make a manual backup of important projects to a separate location. Label them clearly. Keep them forever.
This system won't prevent every possible disaster, but it will give you recovery options for almost anything that goes wrong. The fifteen minutes you spend setting it up correctly now will save you from the hours of panic and potential loss when something eventually fails. Because something always fails. The only question is whether you'll have a backup when it does.