Documentation
Backups and restore
How Bookleaf backups work, how to choose a passphrase you will not lose, and how to verify a backup is actually restorable.
Your entire library is one database file on one computer. That is what makes Bookleaf simple, and it is also the whole risk: a failed drive, a stolen PC or a bad power surge takes the catalog with it.
Backups are the answer, and they are only an answer if you have tested one.
How Bookleaf backups work
An export produces a single encrypted file containing everything: catalog, copies, members, loans, fines and gate logs.
The file is encrypted with AES-256 using a key derived from a passphrase you choose, and integrity-checked so tampering or corruption is detected rather than silently restored. Without the passphrase, the file cannot be read.
That matters because backups get carried around on flash drives. An encrypted backup on a lost drive is a lost drive. An unencrypted one is a data breach involving minors’ records.
Choosing a passphrase
There is no recovery. We cannot reset it, because we never receive your backups. If the passphrase is lost, the backup is permanently unreadable.
So:
- Use a phrase, not a word. Four unrelated words is both stronger and easier to remember than
L1br@ry2026. - Use the same passphrase for all your library’s backups. Different passphrases per file is how people end up unable to open the one they need.
- Write it down and store it physically — a sealed envelope in the principal’s office, or wherever your institution keeps things that matter. This is one of the rare cases where writing a password down is correct.
- Make sure more than one person can get to it. A backup only the librarian can open is not an institutional backup, and staff move.
A schedule that works
| Frequency | What to do | Where it goes |
|---|---|---|
| Weekly | Export a backup | A flash drive kept in the library |
| Monthly | Export a backup | A second drive kept outside the library |
| Each term | Export a backup and verify a restore | Long-term storage |
| Before any big change | Export a backup | Anywhere — this one is your undo |
Take that last one seriously. Before a large import, a policy overhaul, or an inventory session, a backup costs a minute and converts an irreversible mistake into an inconvenience.
The point of the monthly off-site copy is that fire, flood and theft take the library and everything in it. A backup that lives next to the computer does not protect against the events most likely to destroy the computer.
Restoring a backup
Restoring signs out every device — including the computer performing the restore. That is not a bug to work around: the restored database and the sessions that were open against the old one no longer agree on who is who. Everyone, yourself included, signs back in afterwards with whatever credentials are in the backup you restored.
Before Bookleaf touches the live database, it saves a copy of what was there, named
pre-restore-<timestamp>.db, next to it. If the restore turns out to be the wrong file, or you
change your mind, that copy is your way back — you did not need to have taken a second backup
first. Bookleaf shows you that file’s full path right after a successful restore — that is the
moment to note it down, before you close the app.
To undo a restore:
- Close Bookleaf.
- In that same folder, rename the database you just restored (
library.db) to something else, so it is out of the way rather than gone — you may want it back too. - Rename
pre-restore-<timestamp>.dbtolibrary.db. - Reopen Bookleaf. It comes back exactly as it was before the restore.
Verify a restore — actually do this
An unverified backup is a belief, not a backup. The failure mode is well known: a library backs up faithfully for two years, needs a restore, and discovers the files were unreadable the whole time.
Once a term, restore a backup onto a different computer and check that:
- It opens without a passphrase error
- Your book count looks approximately right
- A few members you recognise are present
- Recent borrowing records are there
Do it on a different machine, not the library one — restoring over your live database to test it is how a drill becomes an incident.
If the worst happens
If the library computer is lost or destroyed:
- Install Bookleaf on a replacement Windows PC.
- On the first-run screen, use the Restoring from a backup? link instead of setting up a new library — there is no account to sign in with yet, so restore happens before setup rather than in Settings.
- Re-enter anything that happened between that backup and the loss. This is why weekly beats monthly — the gap is the work.
Your licence is not tied to the machine. Replacing the hardware does not mean buying Bookleaf again.
What backups do not cover
Backups are a copy of your data at a point in time. They are not version history — restoring an older backup replaces the current database entirely, and anything recorded since is gone.
If you need to undo one mistaken edit, fix the record. Do not restore a backup to correct a single wrong entry.
Cover images are not in the backup file. They live in a covers folder next to your database,
not inside it. Copying only the backup file leaves the jackets behind — copy the covers folder too,
or every resource falls back to its plain material-type icon after a restore.
Backups taken by older versions of Bookleaf
A backup file records which version of Bookleaf wrote it, and a newer Bookleaf can restore a file an older one produced. You do not need to keep an old copy of the app around to read your own backups.
What an older file cannot contain is data for features that did not exist when it was written. A backup taken before acquisitions arrived, for instance, carries no vendors, orders or receipts — those parts of the library simply come back empty, and anything recorded since is not in that file either. Copies restored from such a backup also lose the link back to the order they arrived on, because the order is not in the file to link to; the copies themselves, and everything else about them, are unaffected.
The reverse does not hold. A backup written by a newer version of Bookleaf than the one you are restoring into is refused rather than partly read, because a file describing tables this build has never heard of cannot be restored honestly. Update Bookleaf, then restore.
Last updated