Backing Up and Restoring a Zotero Library

Zotero’s own documentation is blunt about a mistake researchers make constantly: assuming that because a library syncs automatically, it is also backed up. It isn’t, and the distinction matters the first time a library gets damaged, an update goes wrong, or a laptop dies. Zotero’s sync servers keep only the most recent version of a library, and a single automatic sync is enough to push a mistake — a bulk delete, a corrupted import, a bad merge — straight to that server copy with nothing older to fall back on. A real backup is a separate habit, and restoring one is a specific, mechanical procedure worth knowing before it’s needed under pressure.

Why syncing to Zotero’s servers isn’t a backup

Zotero’s own support documentation states the risk directly: the servers “only store the most recent version of your libraries, and it takes just a single (possibly automatic) sync to change the server copy.” Sync is a replication mechanism, keeping every device showing the same current state — it is not a version history. If an item, a whole collection, or a note gets deleted and Zotero syncs before anyone notices, the deletion propagates everywhere the library appears, including any other synced device. There is no separate “last week’s copy” sitting untouched on Zotero’s servers to recover from.

This is true even for people paying for one of Zotero’s storage plans — the metered quota covers attached files, not a backup history of the library. Storage tier and backup protection are two unrelated things.

What’s actually inside a Zotero data directory

Everything a backup needs to capture lives in one folder, Zotero’s data directory, found via Zotero’s Advanced preferences (“Show Data Directory”). By default it sits at:

• macOS: /Users/<username>/Zotero
• Windows: C:Users<User Name>Zotero
• Linux: ~/Zotero

Two things inside it matter most:

• zotero.sqlite — the database holding item metadata, notes, tags, collections, and saved searches. This is the library’s actual content; losing this file loses the library.
• The storage subfolder — a set of 8-character-named subfolders, one per attachment, holding the actual files: PDFs, web-page snapshots, audio files, and anything else imported into an item. A backup of zotero.sqlite alone recovers references and notes but not a single attached PDF.

Linked files are the exception. An attachment added as a “linked file” rather than a “stored copy” is never copied into storage — Zotero keeps only a path pointing at wherever that file actually lives on disk. Those files need to be backed up separately, as part of whatever folder they sit in; see Zotero Storage Plans and Quota Management for how stored-vs-linked affects quota, the same distinction that determines what a data-directory backup actually captures.

The right way to back it up

Zotero’s own guidance favors ordinary, boring full-system backup tools over anything Zotero-specific: Time Machine on macOS, File History or a scheduled copy job on Windows, or an equivalent scheduled backup tool on Linux, configured to include the whole data directory. That gets the library backed up automatically as part of a routine that already exists, rather than depending on anyone remembering a separate Zotero-only step.

The manual alternative — periodically copying the entire data directory to an external drive or a cloud-storage folder — works too, with one hard rule attached: close Zotero completely before copying it. Zotero warns explicitly that moving or copying data-directory files while Zotero is running can damage the database, since the SQLite file can be mid-write.

One method that looks like a backup but isn’t: pointing Zotero’s live data directory itself at a folder that’s continuously synced by Dropbox, OneDrive, or Google Drive, so the cloud service “backs it up” in the background. Zotero’s documentation is explicit that this is not safe practice — “storing the Zotero data directory directly in a cloud storage folder is extremely likely to corrupt your Zotero database.” The SQLite database gets written to constantly during normal use, and a cloud-sync client can grab a file mid-write or resolve a sync conflict by renaming or duplicating it, either of which can corrupt the library. A periodic, closed-Zotero copy into cloud storage is fine; a live, continuously-synced data directory is not.

What not to use as a backup: export and re-import

Exporting a library (RIS, BibTeX, or Zotero’s own RDF format) and treating that export file as the backup is a common substitute, and it doesn’t hold up. Re-importing an exported library does not reproduce an exact copy: it resets each item’s Date Added and Date Modified to the import time, and — more disruptively for anyone mid-manuscript — it breaks the links between library items and any citations already inserted into a word-processor document via Zotero’s Word, LibreOffice, or Google Docs plugin. Citations inserted with Zotero’s word-processor integration reference the original items by internal ID, not by their visible text, so a re-imported library with new IDs silently orphans every citation already placed in a draft. Export is for moving citations into a different tool or format, not for disaster recovery.

Restoring a Zotero library from backup

Restoring reverses the backup: with Zotero fully closed, either

1. copy the backed-up data directory over the current (damaged or empty) one at Zotero’s default data-directory location, or
2. keep the backup where it is and point Zotero at it — Advanced preferences → Files and Folders → Data Directory Location — then relaunch.

The same procedure is how Zotero recommends moving a library to a new computer: close Zotero, copy the entire data directory to the new machine (directly, or via a synced folder used only as a transfer step with Zotero closed on both ends), then open Zotero there. There’s no separate “restore” feature to look for in Zotero’s menus — the data directory itself, copied whole, is the restore.

One practical consequence worth planning for: if the backup being restored is older than the copy on Zotero’s servers, the next sync will reconcile the two, and a stale local restore can end up merging back toward the (possibly still-damaged) server state rather than fully replacing it. For a serious recovery — restoring after real data loss, not just moving computers — disconnect from the network or disable sync in Zotero’s preferences until the restored library has been reviewed and confirmed correct, before letting it sync again.

FAQ

Does Zotero’s free sync back up my library?

No. Sync keeps devices current with each other and with Zotero’s servers, but the server only holds the most recent state — there’s no version history to recover an earlier one from. A real backup is a separate copy of the data directory, kept independently of sync.

Is it safe to just keep my Zotero folder inside Dropbox or OneDrive?

Not as the live, active data directory — Zotero’s own documentation calls this “extremely likely” to corrupt the database, because the sync client can interfere with the SQLite file while Zotero is writing to it. A periodic copy into cloud storage, made with Zotero closed, is a reasonable backup method; a continuously-synced live directory is not.

Can I use my Zotero storage plan as a backup?

No — storage plans and WebDAV-based file storage cover where synced attachments live, not a versioned history of the library. If a change syncs, it overwrites what was there before on the server too.

What if I only need to recover one deleted item, not restore the whole library?

Check Zotero’s trash first — a deleted item usually sits there until it’s manually emptied, and can be restored from it without touching a backup at all. A full data-directory restore is for damage a trash recovery can’t fix: database corruption, a bad update, or a lost/wiped computer.

For the rest of the reference-manager toolkit — setup, storage limits, sharing, and comparisons with other tools — see Zotero for Researchers, Zotero Setup and Troubleshooting, and Sharing a Zotero Library, or browse the full research tools hub.