Vault’s database (vault.sqlite) knows which archive holds which file, keeps every fingerprint taken at import, every integrity check, the journal and the register of issued certificates. Your files and archives would survive its loss, but this memory would not. The Backups screen (group Copies) makes copies of it and restores them.
Back up now
Click Back Up Now. Vault takes a consistent copy of the database without closing the app, and confirms: “Database backed up — date, size.”
Backups are kept in the library’s Backups folder, one per subfolder. Show in Finder opens it. Each backup in the list shows its date, its size and the database’s schema version.
Automatic backups
Vault also backs up the database on its own, without asking: after an import, an archive, an audit, an offsite transfer or a certificate issuance, and at launch, as soon as the last backup is more than six hours old. A day of use therefore always leaves a backup less than 24 hours old. These backups are marked Automatic in the list and follow the same retention rule. A failed automatic backup never interrupts the action that triggered it, but it is reported: a “Database backup failed” line in the journal, and the message on the dashboard and on the Backups screen. A backup, manual or automatic, is first written and checked aside (complete database, integrity check, readable Vault database); it appears in the list only once complete, and a failed backup does not change the date of the last one. A backup folder with no usable database (left by a crash or an older version) is never listed nor restored: the Backups screen names it, so that you can delete it.
The dashboard shows the date of the last backup, and warns when none is less than 24 hours old.
A second location
The backups in the Backups folder are on the same disk as the database: a failure of that disk would take both. Second Location… designates a folder on another disk (an external disk, a NAS): every backup, manual or automatic, is also copied there, into a folder “Obscura Vault - sauvegardes de la base”, with the same retention rule. Remove stops these copies (those already made remain).
If the second location cannot be reached (disk unplugged), the backup is made in the library and Vault says so: “The backup is done in the library, but copying it to the second location failed”.
Keys are not in the database: back them up separately (see Keys and security).
How many backups to keep
The Keep the latest n backups setting (from 1 to 100, 10 by default) sets how many backups are kept; beyond that, the oldest are deleted. Backups taken before a restore count like the others.
Restore a backup
- Click Restore… on the backup’s line.
- Read the warning: “The current database will be replaced by the backup of … Everything recorded since — imports, verifications, certificates — will no longer be in it. The current database is backed up first: you can go back from this list.”
- Click Replace Database.
The restore is refused while an operation is running (import, archive, verification, audit, offsite transfer, certificate, backup): “An operation is running… Wait for it to finish, then restore the backup.”
Before replacing anything, Vault checks the backup: that it is indeed an SQLite database, that it passes the integrity check, and that it does not come from a more recent version of Vault. Then it backs up the current database (backup marked Before restore), puts the chosen backup in its place and reopens it. If it does not open, the previous database is put back.
Once the database is restored, a window whose only button is Relaunch Now appears: the other screens still read the previous database, so Vault must be relaunched before anything else. No operation starts until then. The relaunch closes the database before opening the new instance, which waits a few seconds for the previous one to quit.
To undo a restore, restore the Before restore backup.
Backing up and restoring the database are recorded in the audit log (the restore, in the restored database).
Possible messages
- “This backup is incomplete: … cannot be found.” — the backup folder has lost its file; choose another one.
- “This backup is damaged. The current database was not modified.”
- “This backup comes from a more recent version of Obscura Vault. The current database was not modified.” — update Vault before restoring it.
- “The database could not be replaced. The previous database was put back.”
- “The restored database could not be opened. The previous database was put back.”
A library from before 1.0
A library created by a development version of Vault older than 1.0 does not have the 1.0 structure. Vault sees it when opening it, before reading anything, and does not change it: “This library was created by a development version of Obscura Vault older than 1.0 and cannot be opened.”
The dashboard then offers Set This Library Aside…. Once confirmed, the database (with its -wal and -shm files) and the Backups folder are moved into a dated set-aside-… folder inside the library folder. Nothing is deleted; the licence (License), the archives and the certificates stay where they are. Vault starts over with a new library, whose journal records the operation (“Library set aside”).
What the backup does not contain
- Your original files and your archives: they are separate files, which you copy to your media and offsite.
- The PDF certificates (
Certificatsfolder) and their settings (certificate-settings.json): the register is in the database, the PDFs and settings are not. - The keys, which are in the Mac’s keychain.