Backup and recovery.

Where CentProof stores your data

Everything CentProof saves lives in ONE directory on your Mac:

~/Library/Application Support/com.javamantra.pdfapp/

├── data.db                       SQLite database — transactions,
│                                  accounts, statements, entities,
│                                  categories, correction rules.
│                                  PLAINTEXT (no encryption on the DB).
├── pdfs/
│   ├── <sha>.bin                 Encrypted source PDFs — one .bin
│   ├── <sha>.bin                  per imported statement.
│   └── ...
├── models/
│   └── qwen2.5-3b-instruct...     Local AI model (~1.9 GB).
│                                   Re-downloadable from CentProof
│                                   on demand if missing.
└── settings, logs, etc.

Open in Finder: ⌘ Shift G then paste ~/Library/Application Support/com.javamantra.pdfapp/ into the dialog.

What's encrypted vs. what isn't

• Source PDFs in pdfs/ are encrypted — AES-256-GCM with a 32-byte key stored in macOS Keychain under service=com.javamantra.centproof, account=storage_key. Even file-system access to a .binfile doesn't reveal the PDF contents without the key.
• The SQLite database (data.db) is NOT encrypted. Transactions, tags, rules — all plaintext. If full-disk encryption matters to you, rely on macOS FileVault (System Settings → Privacy & Security → FileVault) which encrypts the entire home folder transparently. We chose not to add a separate DB encryption layer on top because FileVault already handles it and adding a second layer would complicate backups + recovery.
• The local AI model is not sensitive. It's a public open-source model file — same contents on every CentProof install.

Time Machine (the easy path)

If you have Time Machine configured, you're already backed up. Time Machine snapshots every hour to your backup disk and includes:

• The CentProof app data directory (all of the above).
• The macOS Keychain (which holds your CentProof encryption key).
• Everything else in your home folder.

Recovering after a hard-drive failure is the standard macOS Migration Assistant flow on the new Mac — point it at your Time Machine drive, and CentProof comes back working, with all imported PDFs decryptable thanks to the restored Keychain.

Manual backup (without Time Machine)

If you'd rather snapshot CentProof's data manually, two things to copy:

1. The app data directory: ~/Library/Application Support/com.javamantra.pdfapp/. The .bin files are already encrypted, so copying them to a cloud-synced folder (Dropbox, iCloud Drive) keeps them encrypted in transit and at rest.
2. The macOS Keychain entry that holds the encryption key. From Keychain Access: search for com.javamantra.centproof, right-click → Export → save as a .p12 file with a passphrase you remember. Store that .p12 offline (e.g. on a USB drive you keep in a desk drawer).

With both backed up, restoring on a new Mac is: copy the app data directory back to ~/Library/Application Support/com.javamantra.pdfapp/, re-import the .p12 into Keychain Access on the new Mac, install CentProof from the website, and launch.

You don't strictly need the SQLite database to be in a separate backup format. SQLite files are just binary files; treating them like any other document is fine.

Restoring on a new Mac (or after a wipe)

Three scenarios:

• Used Migration Assistant from Time Machine backup:nothing extra needed. CentProof comes back working. Verify by opening a previously-imported statement's source PDF — if it loads, the Keychain key was restored cleanly.
• Manual restore with Time Machine drive but without Migration Assistant:copy the app data directory from the Time Machine drive back to its original location. Re-grant Keychain access if macOS prompts on first PDF view. Install CentProof from the website (it's a fresh binary install; settings come from the data directory).
• No backup at all:install CentProof fresh, re-import your statements from your bank's portal. You lose any manual tags + correction rules you'd built up. Statements themselves come back identically (same parsers, same reconciliation).

What if the Keychain key is lost

The Keychain key is the encryption key for your stored PDFs. If it's lost — say, you wiped Keychain without a backup, or your Mac's drive failed and you had no Time Machine — the stored .bin files become permanently unreadable.

CentProof detects this situation on launch and refuses to silently generate a new key (which would orphan every existing .bin). Instead it shows a recovery dialog with options:

1. Restore the Keychain entry from Time Machine or another Mac where this app ran.
2. Accept the loss of stored PDFs (transactions in the DB are intact!) and clear the encrypted blobs:

   rm ~/Library/Application Support/com.javamantra.pdfapp/pdfs/*.bin

   Then re-import the source PDFs from your bank's portal to restore the PDF references.

Important: your transactions are in the SQLite database, NOT in the encrypted PDFs. Losing the Keychain key means losing the source-PDF audit trail, not the transaction data itself. Search, reports, tags, and rules all keep working from the DB.

Cloud-sync the data folder?

Some users put their CentProof app data directory inside an iCloud Drive / Dropbox / OneDrive sync folder for multi-Mac access. This works but has trade-offs:

• The SQLite file (data.db) is NOT designed for concurrent multi-process access via cloud sync. Running CentProof on two Macs simultaneously, both syncing to the same iCloud copy, can cause data corruption.
• The .bin files are encrypted, so cloud sync sees encrypted blobs and never the plaintext PDF. This is fine for privacy.
• The Keychain key does NOT sync via iCloud / Dropbox. On the second Mac you'd either need iCloud Keychain sync (which Apple provides separately) or a manual export/import.

For two-Mac use, the cleanest setup is: launch CentProof on only one Mac at a time, and let iCloud sync the data directory between sessions. Pro Lifetime includes 2 Macs with this kind of usage in mind.