Restoring under another key

A pg_dump holds the ciphertext of the three encrypted columns and none of the key: the key is in your .env, and only there. Restoring into an instance whose .env holds another key therefore half works, and it is worth knowing which half before you find out.

All your figures come back untouched, because none of them was ever encrypted: accounts, balances, operations, holdings, prices, snapshots, categories, achievements. Your password comes back too, so you sign in normally. What does not come back is the three things that were sealed with the key that is gone.

Your provider API keys

The row is there, the last four characters beside it are in the clear, and the value cannot be read. Settings → Access marks such a key unreadable rather than configured, and says to paste it again; a wallet sync fails with the same sentence rather than blaming the provider. Delete the line, paste the key, and that part is done.

Your second factor

An account with 2FA on cannot be signed into with its authenticator any more: the code is correct and the secret it is checked against cannot be opened, so the answer is Code required, the same one an empty field gets.

The only way in left is one of the recovery codes printed when 2FA was turned on.

Each sign-in spends one recovery code, so the way out is to turn 2FA off once you are in. Settings -> Security says the stored secret is unreadable and asks for your password instead of a code, because no code can be checked any more. Confirm it and the second factor is off, the unreadable secret and the leftover recovery codes gone with it; sign in with your password alone from then on, and turn 2FA back on whenever you like, which creates a secret under the key this instance actually runs on.

Only that one account is concerned, and only while its secret cannot be opened: everywhere else, turning 2FA off still takes a code.

If you would rather keep the second factor as it is, generate a fresh set of recovery codes from the same screen before you run out. That needs no code either, only the session you are already in.

Your relay’s opening code

A relay set up with an opening code keeps running, but the code it would seal the letter with cannot be read. Settings → Hand-over says so on the relay’s card. Code on paper, with your password, draws a new code; print it and hand it over: the old paper no longer opens anything. Until you do, the night the letter is due its sending fails and is tried again the next night, which the card’s journal shows.

The cost of a lost key

Losing the key costs you your provider keys, a new opening code for a relay that had one, and one detour through 2FA for the accounts that had it turned on. No figure is lost.

A JSON export sealed with a passphrase has none of this problem. Its secrets are re-encrypted under the key of the instance doing the restoring, which is why a sealed backup opens on a machine that never saw the old one.