Restoring an export

Settings → Data → Your data → Import a file. The restore merges into the account you are signed in as. It never creates an account and never changes who you are, so on a fresh instance you sign up first, with any email and password you like, and restore into that.

For the operator’s copy of the whole database, read Reloading a dump instead.

Both shapes go in through the same button. An encrypted file is recognised on sight and asks for its passphrase before anything is written; a wrong one is refused outright, with nothing restored, because the file authenticates itself before a single byte of it is read back. It never produces a half-plausible restore to clean up after.

What comes back is stated, not assumed: the page prints which of the two shapes it received, one count per table, and under it every line the restore declined to write with the reason it declined. Read that list. A restore that came back short says so there.

Restoring the same file twice changes nothing. Every table is matched on a natural key before it is written, so a second restore reports zeroes.

If a restore is interrupted

A restore is not atomic. It writes table after table, in one long sequence rather than inside a single database transaction, so a browser closed halfway, a container restarted or a connection cut leaves the account in an intermediate state: some tables back, some not, and no error page to tell you which.

The recovery is one line: import the same file again. That is enough, and it is enough for the same reason a second restore of a complete file reports zeroes. Every row is matched on a natural key before it is written, never on a database id: an account by its name, a balance by its account and its date, an operation by its fingerprint, a category by its name and its parent, a price by its asset and its day. Rows that landed the first time are recognised and skipped; rows that never landed are written. It is the same code path either way, so there is no special recovery mode to get wrong.

Read the counts the second run prints. Anything it reports is what the interrupted run had not yet written.

Danger

Do not restore a different file in the hope of filling the gap. The two would merge rather than replace, and you would be reading a mix of two backups.

What a restored account does not get back

An export carries no API key and no second factor, so neither comes back. Issue new keys, and enrol afresh in your authenticator app; your old enrolment still shows codes, but nothing reads them any more.

Secrets from an encrypted file are re-encrypted under the SECRET_ENCRYPTION_KEY of the instance doing the restoring, which is why a sealed backup opens on a machine that never saw the old key.