A Lightning recovery plan needs to explain what happens to the channels when the device disappears. Restoring the keys can be only the beginning. LND’s recovery guide calls for both the original seed and an encrypted Static Channel Backup when recovering channel funds; its seed-only procedure covers the on-chain wallet. LND recovery documentation
The useful question is which information survives, who must participate in recovery, and whether the result is usable channels or coins returned to Bitcoin’s blockchain. Those answers depend on the software and backup method.
Keys and channel state have different jobs
A Lightning channel carries an evolving agreement between two nodes. As payments change that agreement, the nodes exchange signatures for updated commitment transactions and revoke earlier versions. A commitment transaction provides a way to settle the channel on-chain. The latest agreement cannot be reconstructed simply by deriving the same private keys again. Lightning’s channel-update specification
Core Lightning makes the distinction explicit: its root secret, stored in hsm_secret, is necessary but insufficient for recovering in-channel funds. Its backup guide separately identifies the secret, a static recovery file and the database containing detailed channel information. These components have different recovery roles. Core Lightning’s backup guide
That gives owners a useful way to review a backup claim: ask whether it preserves signing keys, information for emergency fund recovery, or the up-to-date state required to continue operating.
What a static backup can recover
LND’s usual SCB recovery reconnects to channel peers and invokes data-loss protection. The peer closes its side of the channel, allowing the recovering node to claim its funds on-chain. The documented process depends on the peer being online and responding. It is an emergency recovery route that closes the affected channels and involves on-chain fees. That peer-assisted route does not require a new static backup after every payment. LND’s SCB safety guidance
The scope matters. LND describes recovery of fully settled balances, excluding funds in pending conditional payments called HTLCs. Its backup is encrypted with a key derived from the node’s seed, so the file alone is insufficient. LND’s off-chain recovery limits
Core Lightning also offers peer-assisted emergency recovery. Its recoverchannel reference describes using minimal channel information to reconnect, request a peer close and sweep funds on-chain. It warns that this depends on the peer and is intended for severe data loss. Core Lightning’s recovery-command reference
A backup file therefore cannot establish a recovery deadline. Peer availability is one dependency; completion also requires the relevant on-chain transactions. Core Lightning’s recovery guide expressly warns that the process can take time. Core Lightning’s wallet-recovery guide
Why an old database is dangerous
A static recovery record can supply information for contacting a peer after data loss. An old operating database may instead contain a superseded channel agreement. Lightning’s specification prohibits broadcasting revoked commitments because the other participant can seize the channel funds. Lightning’s revocation rules
There is an important version-specific wrinkle. Starting with LND 0.19.0, backups include an unsigned force-close transaction. LND labels manual use a dangerous last resort: if channel state changed after the backup, a peer or watchtower may claim all funds through a penalty transaction. Its documentation says to consult a recovery specialist or the project before attempting that route. The extra transaction should never be read as a guarantee that any old backup is safe to broadcast. LND’s manual-recovery warning
Plan around the software you actually use
For LND, preserve the seed and keep a separate copy of the channel.backup file as it changes. Its multi-channel backup changes when channels open or close; a copy predating a newly opened channel cannot contain that channel’s recovery information. LND’s backup-file guidance
For Core Lightning, preserve the appropriate root-secret backup and emergency.recover file. Its guide says to refresh the latter when opening a channel and recommends real-time database replication for node data. Core Lightning’s backup options
Replication itself needs configuration-specific care. Core Lightning’s SQLite replication guide says its database copies are unencrypted and may require accompanying journal or write-ahead-log files for recovery. Simply seeing a database filename in a backup folder does not establish completeness or confidentiality. Core Lightning’s database-backup requirements
Record the application, version, backup method and official recovery instructions before an emergency. If moving a healthy LND node, use its migration procedure: the project warns against running two instances with the same identity or restarting the old instance afterward. LND migration precautions
A low-risk review starts by locating the saved files and checking the documented prerequisites without launching a replacement node. Record whether the backup covers every channel and whether any required storage account is still accessible. For a packaged wallet or node appliance, follow its maintained recovery instructions. Its interface and supported backup workflow may differ from the underlying node software.
Treat those records as a recovery plan someone can follow under pressure. Establish which files are needed, how their availability is checked, and where implementation-specific help comes from before channel funds depend on the answer.