Bitcoin Core 0.12 Wallet Backups: Legacy Keypool Strategy

This guide explains Bitcoin Core wallet backups in plain English. It summarises the important changes, who they affect and what should be checked before an upgrade.

The historical backup unit

Core 0.12 backupwallet copied wallet.dat through the wallet database layer. Copying an actively written file with an ordinary filesystem tool could produce an inconsistent result. The blockchain, peers and cookie were separate. Protect the wallet file and its metadata while treating reproducible chain data differently.

Legacy keypool coverage

Legacy wallets generated unused keys in advance. A backup covered keys already in that keypool, including some future receiving and change addresses, but could become insufficient after enough keys were consumed. Monitor keypool state, refill under controlled unlock and take a new backup after material key-generation events.

Encryption changes require fresh backup

The Core 0.12 encryptwallet response stated that the keypool was flushed and a new backup was needed. Passphrase changes, key imports and keypool refills also alter recovery assumptions. A backup schedule must be event-driven as well as periodic, and every trigger should have an accountable owner.

Descriptor wallets are later

Descriptor wallets represent scripts and derivation rules explicitly and are commonly backed up differently in later Core releases. Do not describe them as a Core 0.12 feature or use legacy keypool rules blindly. Record whether a wallet is legacy, descriptor, watch-only, external-signer or blank before choosing the current supported export and backup method.

Confidentiality and integrity

Wallet backups grant spending authority or reveal transaction history. Encrypt approved storage independently, restrict access, maintain offline copies and record hashes without exposing content. A passphrase does not protect a backup if the passphrase is stored beside it, and encryption does not prove the file is complete.

Restore validation

Restore into an isolated supported node, verify wallet type and encryption, inspect key and descriptor coverage, rescan from an appropriate birthday and confirm known addresses and transactions. A pruned node may lack required history. Never make a production payment merely to test a backup; use signed-message or controlled test-network evidence where suitable.

Recovery drill and rotation

Test loss of the primary host, one damaged copy, an unavailable custodian and a stale legacy backup. Measure recovery time and prove new receiving and change keys are covered. Rotate media and access when staff or encryption controls change, retaining an auditable destruction record for superseded copies.

Conclusion

Wallet backups are only trustworthy when their key model, freshness and restoration have been proven. Core 0.12 legacy keypools and modern descriptors require different procedures, so record the architecture and rehearse recovery.