How to get your passwords out if the app stops working

Every password manager will tell you that you can export your data. Very few will tell you what happens when the thing you need to run the export is the thing that broke. The app fails to launch after an OS update, the company shuts down, your license server stops answering, the subscription lapses, or you are trying to recover a vault belonging to someone who has died.

That is worth thinking about before you need it, whatever manager you use. This page covers how to evaluate the exit path of any password manager, then how Buddy's works.

What a real exit path requires

An exit plan you can rely on has four properties. Check your current manager against them:

1. The format is documented. If nobody outside the company knows how the vault file is laid out, then the file is only readable by software the company chooses to keep publishing.
2. Recovery does not need the main application. A recovery path that runs inside the app assumes the app runs. That is the assumption most likely to be false when you need it.
3. Recovery does not need the network. If a license check, an account login, or a sync service has to answer before you can read your own data, then a company that has stopped paying its hosting bill controls your access.
4. You have tested it. An untested backup is a belief, not a backup.

Plenty of managers pass some of these. A cloud manager with a documented export format and a saved export file is in reasonable shape. A manager with a proprietary format, an account requirement, and no offline path is one company decision away from holding your data hostage.

How Buddy's break-glass tool works

Buddy publishes a separate command-line program called buddy-rescue. It reads a vault, authenticates your master password locally, and writes out a documented export.

It is deliberately small. It contains no licensing code, no updater, no browser integration, no analytics, and no networking feature at all. It shares the same public crypto core the desktop app uses, so it is not a reimplementation that might drift. It opens your database read-only, runs no migrations, and writes nothing beside the source file.

Step 1: inspect the file

Inspection needs no password and decrypts nothing. It reports whether the database is intact, which vaults are inside it, and what parameters they use:

$ buddy-rescue inspect buddy.sqlite
Format: buddy-vault-v1
SQLite integrity: ok
Schema migration: 1
Vaults: 1

Personal
  Vault version: 1
  Entries: 214 live, 0 trashed
  Attachments: 12 records, 12 present, 0 missing
  KDF: argon2id · 65536 KiB · t=3 · p=4 · version 19
  Status: compatible

The attachment line is the one people overlook. Attachment contents live in a directory next to the database rather than inside it, so a backup containing only the .sqlite file will report missing attachment files here. Better to learn that now than during a recovery.

Add --json if you would rather have the report in a machine-readable form.

Step 2: export

$ buddy-rescue export buddy.sqlite --format json --output ./out
Master password:
Recovered 214 entries and 12 attachments to ./out

If the database holds more than one vault, inspect it first and pass the vault you want with --vault <id>. The master password is read from a hidden prompt and is never accepted as a command-line argument, because arguments end up in shell history and process listings. For scripted use there is --password-stdin.

An export is a directory containing a manifest, the entries file, and any attachments:

out/
├── manifest.json
├── entries.json              # or entries.csv
└── attachments/
    └── <blob_id>/
        └── <original_filename>

Step 3: pick the right format

JSON is the full-fidelity option. It preserves entry and group IDs, every field shape and role, password history, usage timestamps, trash state, icons, and attachment references.

CSV uses the same eleven-column shape as Buddy's own exporter, which is the convenient choice for importing into another password manager. It drops anything those columns cannot express. Use JSON when preserving everything matters, and CSV when the destination is another app.

Step 4: read the exit status

The tool is designed to recover what it can rather than stopping at the first bad record. Each entry and attachment is authenticated independently, so one damaged record does not cost you the other two hundred. What it skipped is written to manifest.json.

Status	Meaning
0	Inspection passed, or every requested record exported
1	The command could not run, credentials were rejected, or nothing was written
2	Inspection found damage, or the export finished with record issues

Exit status 2 is the one to pay attention to. It means you got an export and something in it needs looking at.

Handle the output carefully

An export is your entire vault in cleartext. That is the point of it, and it is also the risk.

• Write it somewhere local, not to a synced folder or a network share.
• On Unix, exports are created with owner-only permissions. That is a floor, not a plan.
• Delete it when you are done, and remember that a normal delete on an SSD does not reliably destroy the data. An encrypted disk is what makes that deletion meaningful.
• If you exported to move managers, delete it after the import, not after you get around to it.

Test it now, not later

This takes about ten minutes and is the only version of this exercise that proves anything:

1. Copy your vault and its attachments directory to a scratch folder.
2. Run inspect on the copy and confirm it reports the vaults and attachment counts you expect.
3. Run export on the copy.
4. Open the export and check a handful of entries you would hate to lose, including one with an attachment and one with a TOTP secret.
5. Delete the scratch folder.

Do the equivalent with whatever manager you use. The test is the same everywhere: get your data out using something other than the app, and look at it.

Buddy's vault format is documented in full, so a recovery reader does not have to be ours. See how Buddy encrypts your vault for the format itself, or the open-source projects page for the repositories.