Backup, Data, and Cloud Sync

Everything you need to know about where your data lives, how to protect it, and how (or whether) to share it across machines.

Where your data lives

A single SQLite database file:

%APPDATA%\Mise Manager\mise-manager.db

On most Windows installs that resolves to:

C:\Users\<your-username>\AppData\Roaming\Mise Manager\mise-manager.db

Quick way to navigate there: press Win + R, type %APPDATA%\Mise Manager, hit Enter.

Alongside the main file you'll see two sidecar files: mise-manager.db-wal and mise-manager.db-shm. Those are SQLite's write-ahead-log files (WAL mode = crash safety). If you copy / move / restore the database, copy all three together. The Export DB function handles this for you by writing a consolidated single-file copy.

Where your data does NOT live

• Not next to the .exe. You can move, rename, replace, or delete the .exe freely — the data stays put.
• Not in any cloud account. The app has no login. Nothing is uploaded automatically.
• Not in Documents or your user profile root. Just AppData\Roaming.

Per-Windows-account isolation

The database is per Windows user account on each machine. If two people log into the same PC with different Windows accounts, they get separate databases. If you want them to share data on one PC, log in as the same Windows user.

Surviving upgrades

When a new version of the .exe arrives, you just replace the .exe. The database is untouched. The new app may run migrations on first launch (visible in the dev console as [db] applied migration: 00x_...), but those migrations are idempotent and additive — you don't lose data.

Export DB (manual backup)

Sidebar → Shops → Export DB

Opens a Windows save dialog. Pick a destination, click save.

The app uses better-sqlite3's .backup() API which writes a clean consolidated .db file (no sidecar files needed for the export — they're folded in). Default filename includes a timestamp like mise-manager-backup-2026-05-29-14-23-15.db.

This is your manual safety net. Do it regularly. Some routines that work:

• After every shift
• Every Sunday morning
• Before testing something risky (importing someone else's DB, mass-editing, deleting a shop)

Import DB (restore / move to new machine)

Sidebar → Shops → Import DB

Opens a file picker → pick a previously-exported .db. Confirmation modal makes the consequences explicit (current data WILL be replaced).

What happens technically:

1. The app closes its DB connection
2. Deletes the existing mise-manager.db (+ sidecars)
3. Copies your chosen file to %APPDATA%\Mise Manager\mise-manager.db
4. Re-opens it (runs any pending migrations if your backup is older than the current app version)
5. Reloads the window so React state refreshes

After it's done you're looking at the imported data. The previous data is gone — there's no auto-rollback. Always Export first if you have anything you want to keep.

Cloud sync (Google Drive / OneDrive / Dropbox)

Mise Manager doesn't integrate with any cloud API directly — by design. You stay in control of where your data lives. But you can absolutely use cloud sync via the desktop sync client of your choice.

The pattern

1. Install Google Drive Desktop (or OneDrive / Dropbox) on your PC. It syncs a folder on your computer to your cloud account.
2. Mise Manager → Shops → Export DB → save into your cloud-synced folder (e.g. C:\Users\you\Google Drive\Mise\)
3. The desktop sync client uploads it automatically to your cloud account
4. On another machine: install the cloud sync client, install Mise Manager, then in the app Import DB → pick the file from the synced folder

No OAuth, no API keys, no Mise Manager account. The file flows your machine → your cloud client → your cloud account. We never touch it.

Why we didn't bake in Google Drive API

• It would require embedding an OAuth client ID in the .exe (extractable by anyone with the file)
• Google requires app verification for sensitive scopes (drive.file), which takes weeks
• It locks you into one provider — what if you prefer OneDrive or iCloud or a self-hosted Nextcloud?
• It puts us in the path of your data, which is exactly what you said you wanted to avoid

The "point your sync client at a folder" approach gives you the same outcome with none of those downsides.

Auto-backup on quit (future option)

Right now Export DB is manual. If you want set-it-and-forget-it backup — pick a folder once, the app writes a fresh export to it every time you quit — that's about 1 hour of work to add as Phase 11. The folder you pick can be your cloud-synced folder. Tell us if you want it.

Multi-machine considerations

Mise Manager is designed for single-user-at-a-time use. Here's what works and what doesn't.

Works: machine transfer

Owner uses the app on the office desktop. Wants to also work from home on a laptop. Pattern:

1. Office desktop → Export DB → save to Google Drive folder
2. Laptop → wait for Drive to sync → Import DB
3. Work on laptop (office desktop is closed)
4. Laptop → Export DB → save back to Drive folder
5. Next day at office → Import DB before starting work

This is fine. The discipline is "only one machine writes at a time, the other is updated by import."

Works: round-the-clock single writer

Only one machine ever writes. Other machines have read-only copies for viewing. They periodically reimport to refresh. No concurrent writes = no conflict.

Doesn't work: two people editing the same DB simultaneously

If two machines open the app from the same Google-Drive-synced mise-manager.db and both edit:

• Sync client doesn't understand SQLite internals
• It tries to upload both versions, picks one as canonical, renames the other as mise-manager (Owner's conflicted copy 2026-05-29).db
• One full set of writes effectively disappears — they're in a "conflicted copy" file that the app doesn't see
• You'd have to manually reconcile by opening both copies and picking which to keep

So don't do this. SQLite is great for what it does; live multi-user shared files isn't it.

What if you really need multi-user

That's a client/server architecture: the database lives on one machine (a small VPS, a desktop at the restaurant left always on, even a Raspberry Pi), and each Mise Manager app on each laptop/tablet talks to it over HTTP instead of touching a local file. That's a separate build — let us know if it becomes a real need.

For most kitchen owners, single-user with disciplined export-import is plenty.

Recovery scenarios

"I accidentally deleted important data"

If you have a recent backup, Import DB restores it. Anything that happened since the backup is lost.

If you don't have a backup — that's the whole reason to back up. There's no recycle bin inside the app for individual records (except the 10-second Undo on simple deletes).

"The .db file got corrupted"

Rare with WAL mode, but possible after a hard crash. Symptoms: the app fails to launch, or shows an error mentioning "malformed" or "not a database."

1. Try opening the file in a SQLite browser tool (e.g. DB Browser for SQLite, free). It may show partial recoverability.
2. If you have a backup, Import DB and proceed from there.
3. If you don't, contact us with the corrupted file — sometimes recovery is possible.

"I installed the app on a new computer and my data is gone"

Each Windows user account has its own database. If you switched machines or accounts and the data isn't there, that's expected — there's no auto-sync. Use Export DB on the old account / machine, Import DB on the new one.

Best practices

• Export weekly minimum, daily if you actively use the app
• Save backups to a synced cloud folder (Google Drive / OneDrive / Dropbox / iCloud) — gives you off-site safety without any in-app cloud integration
• Keep at least three backups — last week, last month, last quarter. If you discover bad data, you can roll back to before the issue.
• Test your restore process once so you know it works before you need it
• Don't store the database on a network share as the live working file. Network filesystems and SQLite don't always cooperate well. Backups to a network share are fine.

What we don't see

Just to be explicit: Mise Manager is a fully offline app. No telemetry, no analytics, no crash reporting, no usage tracking. Your data never leaves your machine unless you put it somewhere yourself.