Save copies, back up and recover

Protect local books and browser storage, and know what history can recover.

Choose a backup method

Backup scheduling, retention and restore testing are your responsibility for local books and the host’s responsibility for shared books. Kabacus’s audit history records edits; it cannot recover a deleted database or failed disk.

Use File → Save a Copy As… to create a separate .kabacus copy from the application.
Keep copies on a separate device or backup service with a retention policy you control.
Open a copied file separately and check accounts, recent transactions and Activity before relying on it. Keep the original until the copy is verified.

Copying SQLite safely

A live local database may use SQLite’s write-ahead log. Copying only the main .kabacus file while it is open can miss committed changes. Prefer the application’s copy operation. For an operator backup, use SQLite’s consistent backup mechanism, or stop all writers before making a filesystem copy. Do not delete -wal or -shm files beside an open database.

Browser books

Chromium can write back to the file you selected, subject to permission. Other browsers keep books in browser storage; Save a Copy As… downloads them. Export a copy before clearing site data, switching browser profiles or uninstalling the PWA. An installed PWA’s offline assets are not a backup of the books.

Recover deliberately

Stop writes and preserve a copy of the damaged or unexpected state.
Open the last verified backup in a separate window or isolated server instance.
Compare the last transactions and revision history with your statements.
Restore using your database or hosting procedure, then reconnect clients and refresh before writing.

A past revision is useful for understanding changes. There is no one-button revert of the books: a void adds a reversal, an edit records a new revision, and every earlier revision remains in history. A journal export is an interchange format, not a full-history database backup.