An untested backup is not a backup. It is a file you hope is useful.
Most library backup strategies fail not because nobody took a copy, but because the copy was incomplete, lived on the same disk as the original, or had silently been failing for months. This guide covers all three. It assumes you are running Koha yourself; a backup you have never restored is also the one thing that makes an upgrade unsafe.
What a complete Koha backup contains
| Component | Why it matters | Rebuildable? |
|---|---|---|
| The database | Everything — records, patrons, loans, fines, settings | No |
| Uploaded files | Cover images, patron images, attached documents | No |
| Configuration | Instance config, Apache vhosts, SIP2 config, cron entries | Painfully, from memory |
| Search index | Search performance | Yes — rebuild from the database |
| Koha software | The application | Yes — reinstall the package |
Most guides cover only the database. A library that backs up the database alone can restore its catalog but not its cover images, and will spend a bad week reconstructing configuration from memory.
How often should you back up?
Ask the question the other way round: how many hours of circulation can you afford to re-enter by hand?
- Daily — the minimum for any library that circulates. Loses at most one day.
- Twice daily — sensible for busy libraries; take one before opening and one after closing.
- Weekly — only for a catalog that barely changes. Losing a week of circulation is worse than it sounds, because the data cannot be reconstructed from anywhere.
Taking a database backup
A logical dump of the Koha database is the standard approach. Two practical points:
- Do not lock the library out mid-day. Use a dump method that does not hold long table locks, or schedule outside opening hours.
- Verify the file. A truncated dump — disk full, process killed — looks like a backup until you need it. Check the file size is plausible and that the dump completed cleanly.
Automating it
A scheduled job that dumps, compresses, copies off-server and rotates old copies.
The critical point: a backup job that fails silently is worse than no backup at all, because it buys false confidence. Whatever runs your backup must tell someone when it fails — an email, a monitoring alert, anything that reaches a human. Libraries that discover their backups stopped in March, in November, are not rare.
Where to keep backups
The 3-2-1 rule, applied to a library: three copies, on two kinds of storage, one of them off-site.
- A copy on the same server is not a backup. It dies with the disk, and it does not survive the server being compromised.
- A copy only on your hosting provider's storage is a dependency, not a safeguard. It protects you from hardware failure. It does not protect you from a billing dispute, an account lockout, or a provider that disappears.
- Keep at least one copy you control — your own cloud drive, an emailed archive, or a download somebody physically keeps.
That last point is the one to insist on when evaluating a host, and it is worth asking directly: can I hold my own copy?
How to restore
In order, because the order matters:
- Install Koha — the same major version the backup came from. Restoring an older database into a newer Koha means running the upgrade afterwards, which is fine but must be deliberate.
- Create the instance with the same name — instance names appear in paths and users.
- Restore the database from the dump.
- Restore uploaded files to their correct location and ownership.
- Restore configuration — instance config, Apache vhosts, SIP2.
- Fix file permissions. The most common reason a technically successful restore does not work.
- Rebuild the search index. Until you do, the catalog looks empty — which panics people into thinking the restore failed.
- Re-check cron jobs. Frequently forgotten, and everything looks fine for a fortnight until fines stop accruing.
Run a restore drill
Restore into a spare server or a virtual machine. Confirm record counts match, spot-check a handful of records, log in, issue and return a test item. Note how long it took.
Do this once a year, and after any significant change to the backup process. Almost nobody does. The libraries still operating after a disk failure are the ones who did.
What a hosted service should give you
If someone else is running your Koha, ask specifically:
- How often are backups taken, and what exactly is included?
- How long are they retained?
- Have restores been tested — and when?
- What is the realistic time to restore after a failure?
- Can I hold my own copy?
That last question separates a real answer from a comfortable one. Backups that are taken automatically every day and delivered to storage you control — your own Google Drive, your inbox, or a direct download — give you the safety of self-hosting without any of the work. Your data stays genuinely yours, and nobody has to remember to run anything.
Backup checklist
- Database dumped on a schedule
- Uploaded files included
- Configuration files included
- At least one copy off the server
- At least one copy you control
- Retention policy defined
- Failures alert a human
- A restore performed and timed within the last year
- The restore procedure written down where someone else can follow it
Not sure your backups would actually restore? We audit Koha backup setups and run test restores. It is a short job, and it is the cheapest insurance a library can buy.