Designing a backup plan for your records

The aim of a backup is not more copies, it is copies that do not die together. A second folder on the same computer disappears with that computer. A second folder in the same cloud account becomes unreachable with that account. Start by listing the ways your records could actually be lost.

There are four main ones: hardware failure or loss; a cloud account locked or closed; physical disaster such as fire or flood; and your own deletion or overwrite. Local external storage survives an account lockout; cloud storage survives a dead drive and a house fire; version history survives your own mistakes. Only a mix of different kinds of storage covers the set.

For transaction records, two tiers works well: save each quarter's exports into a local folder, and sync that folder to the cloud. Either side can fail without taking the records with it. Consistent file naming and per-year folders mean the version of you three years from now can still find things.

Now the line that matters. All of the above concerns transaction records. Seed phrases and private keys are explicitly outside this policy. Do not put them in the cloud, do not photograph them, do not email them to yourself, and do not place them in a password manager. A key backup lives offline — on paper or a metal plate — held in more than one physical location, under a different set of rules. Convenience governs records; it does not govern keys.

Finally, test the restore. A backup only works if something comes back out of it. Once a year, pull one file down from the cloud and open it. Broken encoding, a forgotten password, a format nothing can read any more: this is when you want to find out.