Backing up your books

Your .solid file holds every transaction, list, attachment, and audit-log entry your business has accumulated. Losing it would be catastrophic. Backing it up properly is non-negotiable.

This guide covers the strategy and the mechanics. The short version: 3 copies, 2 different media, 1 offsite. Solid Accounting makes this easy.

The 3-2-1 rule

The standard backup strategy:

• 3 copies of the file
• 2 different media (disk + cloud, disk + drive, etc.)
• 1 offsite (different physical location)

For a Solid Accounting file, that translates to:

That's the 3-2-1 minimum. Many users add more — an additional cloud-sync copy in Dropbox, a quarterly archive to a separate USB, etc. — but 3-2-1 is the floor.

Setting up Cloud Backup (the offsite copy)

Cloud Backup is Solid's built-in encrypted offsite backup. It runs in the background, deduplicated and encrypted with a key only you control.

1. Open the file you want to back up
2. Settings → Cloud Backup → Set up
3. Pick a destination:
   • Managed B2 (recommended) — included with an active Updates plan, 10 GB included, simplest setup
   • Your own S3-compatible bucket — AWS S3, Backblaze B2, Wasabi, R2, MinIO — bring your own credentials
   • A folder — a local drive, NAS, or a mounted cloud-sync folder (with the warning about cloud-sync conflicts)
4. Set a backup password — this is the password used to derive the key encryption key (KEK). Use your file's main password unless you want different access controls.
5. Save the recovery phrase — Solid generates a 24-word BIP39 mnemonic encoding the BEK (block encryption key). Write this down on paper and store it somewhere safe (a fire-proof box, a safety deposit box, a separated location). It's the only recovery path if you lose your login password.
6. Confirm the recovery phrase — Solid asks you to re-enter a few of the words to confirm you wrote them down
7. Review and finish — backup runs immediately, then on the configured schedule

The first backup is the slowest because every block is new. Subsequent backups deduplicate and only upload what changed.

Setting up local backup (the second copy)

The local backup is your fast-recovery option if the working file gets corrupted (rare, but possible). Several patterns:

Pattern 1 — File → Backup (manual, on demand)

File → Backup creates a compressed archive of the current state of the file in a folder you choose. Run this:

• Before any major operation (year-end close, mass import, accountant copy creation)
• At the end of every workday for high-value files
• Before applying app updates (in case the new version has issues with your file)

The backup is a .solid.backup file with the same encryption as the original. Store these in a date-organized folder (/Backups/SolidAccounting/2026/04-30.solid.backup).

Pattern 2 — Time Machine / File History / etc.

OS-level backup tools (macOS Time Machine, Windows File History, Linux rsnapshot) work fine on .solid files because the file is just one binary blob. They snapshot whenever the file is closed; partial-snapshot risk is low because Solid auto-saves and closes the file when you exit the app.

The downside vs File → Backup: the OS snapshots aren't accounting-aware. You can restore the file but not selectively roll back a transaction.

Pattern 3 — A copy script

For users with a NAS or an always-on second machine, a simple sync script (rsync, robocopy, syncthing) keeps a continuously-updated copy of the file. Run it nightly via cron / Task Scheduler.

This is the easiest "set and forget" option for technical users. Pair it with Cloud Backup for the offsite leg.

Pattern 4 — Cloud-sync folders

Storing the working .solid file in Dropbox / iCloud / Google Drive technically gives you "cloud backup," but with caveats:

• The cloud-sync client uploads partial blocks during saves, occasionally producing sync conflicts
• The sync client's history isn't designed for binary database files (most version histories are line-based)
• Your provider can read the encrypted file's metadata (name, size, timestamps); content is encrypted by Solid

Cloud-sync folders work for individuals doing infrequent edits; they're not recommended for active multi-user files or for users who edit hourly. Use Cloud Backup instead — same offsite-protection goal, conflict-free.

What gets backed up

The .solid file contains everything:

• Every transaction (the GL)
• Lists (chart of accounts, customers, vendors, items, classes, locations, projects)
• Reports definitions (custom reports, where supported)
• Attachments (PDFs, receipt images)
• The audit log
• Settings and preferences
• User accounts (in multi-user files)

So a backup of the file is a backup of everything. There's no "did I remember to back up the receipts?" — receipts are in the file.

What's not in the file:

• License activation state (regenerable from the license key — you have the key, you can re-activate)
• The Cloud Backup keychain entries (machine-specific; you'd reconfigure Cloud Backup after restoring on a new machine)
• The recovery phrase (paper backup; not in the file)

Recovery scenarios

Scenario 1 — Working file is corrupted

You open the file and Solid says "file appears damaged."

1. Don't panic. Don't keep clicking. Each click might overwrite the working copy.
2. Restore from your most recent local backup — copy a recent .solid.backup to a fresh location and rename it .solid. Try opening that.
3. If the local backup also looks bad, restore from Cloud Backup. Settings → Cloud Backup → Restore on a new file location.
4. If that works, identify what changed since the backup and re-do that work manually.

The audit log helps here: even if you've lost the most recent N transactions, the audit log on the restored copy shows what was happening up to the backup snapshot, so you know exactly what to re-enter.

Scenario 2 — Laptop stolen or destroyed

You don't have the file. You have:

• Your license key (in your password manager)
• Your Cloud Backup recovery phrase (on paper somewhere safe)

1. Get a new machine
2. Install Solid Accounting, activate license
3. Settings → Cloud Backup → Restore from another machine
4. Enter the file's identifier (was the original filename + a UUID; Solid catalogs your active backups against your license key)
5. Enter the recovery phrase
6. Restore — the file downloads and decrypts on the new machine

The whole recovery takes 10 minutes plus download time (proportional to file size).

Scenario 3 — Accountant Copy went wrong, want to undo

If you imported accountant changes and they broke something:

1. File → Restore from Backup
2. Pick the local backup from before the import
3. Open that — your file is back to pre-import state
4. Address whatever was wrong with the accountant's changes; coordinate a fresh import

This is why the File → Backup before any accountant-copy import is in the Period Close walkthrough.

Scenario 4 — Cloud Backup destination became unavailable

Your S3 provider had an outage, or you forgot to renew Updates plan and the managed-B2 access expired.

• Working file unaffected — keeps working
• Local backups unaffected — still on your disk
• Cloud Backup history is what's at risk

For managed-B2 lapse: you have a 1-year restore window after lapse before the data becomes unavailable. See Cloud Backup → Lapse policy. For BYO S3 outages: just wait, then re-run a backup once the destination is back.

Verifying backups

A backup is only as good as your ability to restore from it. Verify quarterly:

1. Test restore — copy a backup to a fresh location, open it, verify a recent transaction is there
2. Cloud Backup integrity verification — Settings → Cloud Backup → Verify integrity runs the deep verification (rehashes random blocks against the manifest, validates AES-GCM tags). Takes a few minutes; reports any corruption.
3. Recovery phrase verification — annually, dig out your written-down recovery phrase and confirm you can read it. (Don't enter it into Solid as a test — entering counts as a phrase reveal, which is logged. Just confirm you can read your handwriting.)

Skipping verification is the most common backup failure mode — backups exist on paper but no one's confirmed they work until disaster strikes.

Backup discipline

The discipline matters more than the schedule. Pick a cadence you'll actually keep.

Common gotchas

"My backup is in Dropbox, that should be enough." Dropbox is one copy in one place (their cloud). It's not 3-2-1. Add a local NAS copy + Cloud Backup with a different provider for real protection.

"I have it on a USB drive in my desk drawer." That's local backup, not offsite. A fire takes both your laptop and your USB drive. Offsite means a different building (or in encrypted cloud storage).

"I encrypted the laptop disk, isn't that enough?" Encryption protects against theft but not against drive failure, ransomware, or accidental deletion. Backup is about availability, not confidentiality.

Recovery phrase lost. If you also lose the login password, the encrypted backups are unrecoverable. There's no backdoor. Print the phrase on paper and store it somewhere you trust — a safety deposit box, a fire-proof folder, with a trusted family member.

Backup is huge — Cloud Backup quota full. A heavily-attached file plus multi-year history can exceed the 10 GB included. Either compress attachments (PDF optimization can shrink an attachment library 50%+), prune ancient attachments to a separate archive file, or upgrade quota.

Restored on a new machine but Cloud Backup says destination unreachable. Keychain entries don't transfer. Settings → Cloud Backup → Reconfigure re-wraps the BEK with the new machine's keychain.

Cross-references

• Cloud Backup module — full architecture and controls
• Migrating between machines — backup-relevant move steps
• General Ledger → audit trail — what survives a restore
• Account & Billing — Renewal & maintenance — Updates plan affects managed-B2 backups