Usually, you have one important key (the master key).
This can be your private bitcoin key, your password database key, the drive encryption key, or really whatever.
Normally you encrypt this key, because you want to change it as infrequently as possible and encrypt it using some user input (e.g. a password) because of costly re-setups of the system.
You now have two ways to implement backups (easily):
- Give the user the key and tell them to store it properly (probably ends bad)
- Give the user another means of authentication (e.g. a password) and store a copy of the master key that is protected using this mean next to your standard encrypted key.
The advantage of the first way is that it probably is a full backup of the header and thus you can still recover data if the header is corrupted.
The disadvantage of course is that you have to trust the user to store extremely sensitive data of course and this data usually is highly unfriendly to humans, being a random chunk of bytes.
The usual solution to this is to follow the second approach and let the user do backups of the header.
This way you store two copies of your encrypted master key: One for normal operation and one for the backup case. The backup material then allows for access to the data via this encrypted backup copy of the key. Usually you'd also do a backup of the entire header containing this key to prevent data loss.
Finally there's one last method, which is much more difficult to use and may make securing a system very difficult: deterministic key generation. This way you generate your master key in a deterministic way using a password and the same password input will always yield the same key. The advantage being of course that header backups are not really required and that all it takes is a single password. The disadvantage is of course that if the user choses a bad password (if this is an option) that brute-forcing the key via this method probably is a viable attack vector.