Skip to content
Vehistra
Documentation navigation

Backup and restore

What has to be backed up

Two things belong together:

  1. The database – VehistraDB on the SQL Server in network mode, or the file Vehistra.db in solo mode
  2. The documents folder on the server

A backup of the database alone is not enough: documents and photos live in the file system and would be gone after a restore.

Retention

The guide recommends keeping seven daily backups and additionally weekly and monthly copies. At least one copy belongs on separate media – a backup sitting next to the database on the same disk helps against mistyped entries, but not against a hardware failure.

Cleaning up old backups

The program can remove old backups itself – Settings · Backups · retention in days. The default is 0, meaning off: deleting cannot be undone.

Whatever the retention is set to, these are always kept:

  • the three most recent backups,
  • every backup taken before a database migration,
  • every file that did not come from this program – only files matching its own naming scheme are deleted.

Only the configured directory is cleaned, not its subfolders. Every deletion is written to the log, and clean up old backups shows beforehand what would go and asks first.

The cleanup does not replace keeping a copy elsewhere: if only one copy exists and it sits in that same directory, no retention setting helps.

In solo mode

The backup from within the program creates a complete copy of the database file and then opens it to check it for damage. That works while the program is running.

Never copy Vehistra.db by hand while Vehistra is running: the most recent changes are still in the companion file Vehistra.db-wal and would be missing.

Because everything sits on one device in solo mode, the copy off the machine matters even more here – see Solo installation.

Setting up automatic backups (network mode)

Configure a scheduled backup job that runs at night and:

  • backs up the database,
  • includes the documents folder,
  • removes older backups according to plan.

The complete guide contains ready-made commands and how to set this up as a scheduled task.

Manual backup

Before larger operations – data import, a move, experiments – an additional manual backup is worth it.

Restoring

A restore brings back the database and then the state of the documents folder. What matters is the order, and that both states match: an old database does not know about newer documents.

Testing a backup

A backup that has never been restored is a guess. The guide describes how to restore a backup under a different name and verify it without disturbing ongoing operations.

Do that once a quarter.

Backups by the updater

Before every database change the updater additionally creates its own backup. If it fails, the update stops – see Updates.

Emergency plan

For the serious cases – server failure, ransomware, a lost site – the complete guide contains an emergency plan with an order of work and a checklist.