Lightning Learning Path

"It's very attractive to the libertarian viewpoint if we can explain it properly. I'm better with code than with words though."

Satoshi Nakamoto— November 14, 2008

Lightning Node Backups

Proper backup procedures are crucial for Lightning nodes as they manage active payment channels with real funds. Unlike regular Bitcoin transactions, Lightning channels require additional state information to be backed up. A comprehensive backup strategy is essential for disaster recovery.

Why Lightning Backups Matter

Lightning backups are fundamentally different from on-chain Bitcoin backups. Understanding these differences is key to proper node management.

Risks of Data Loss

Losing Lightning channel data can lead to:

  • Fund Loss: Without proper channel state data, you may be unable to recover channel funds.
  • Force-closures: Peers may force-close channels if your node is unresponsive during downtime.
  • Counterparty theft: Without up-to-date channel states, malicious peers could attempt to steal funds using old states.
  • Network reputation: Unreliable nodes damage their reputation in the network.

Lightning vs. On-chain Backups

On-chain Bitcoin
  • Only requires seed phrase backup
  • Static data that doesn't change
  • Backup once, use forever
  • Recovery is straightforward
Lightning Network
  • Requires seed phrase AND channel state
  • Dynamic data that changes with each payment
  • Requires regular, frequent backups
  • Recovery procedures are more complex

Essential Backup Types

A comprehensive Lightning node backup strategy includes several different types of backups, each serving a specific purpose in your recovery plan.

Static Channel Backup (SCB)

SCBs are compact files containing the essential information needed to recover funds from your channels in case of node failure. These files are implementation-specific (e.g., channel.backup in LND).

  • What it contains: Cryptographic information necessary to identify and recover from channels
  • When to update: Every time a channel is opened or closed
  • Limitations: Forces all channels to close during recovery, can't maintain channel states
  • Size: Very small (typically kilobytes), easy to back up frequently
Note: While SCBs are essential, they only enable emergency channel closure, not preservation of exact channel states. This means potential fee loss from force-closures.

Channel Database Backup

The full channel database contains complete state information for all your channels. For LND, this is the channel.db file; for Core Lightning, it's part of the lightningd.sqlite3 database.

  • What it contains: Complete channel states, payment histories, routing information
  • When to backup: Extremely risky—must be backed up atomically while node is stopped, or use continuous backup solutions
  • Limitations: Using outdated database backups can lead to fund loss via "justice transactions"
  • Size: Larger (megabytes to gigabytes), harder to back up frequently
Warning: Never restore an old channel database backup while channels are still active. This can broadcast outdated states and trigger penalty mechanisms, potentially resulting in total loss of funds.

Seed and Private Key Backup

Your node's seed phrase and any additional private keys are the foundation of your node's security.

  • What it contains: Secret key material that controls all node funds
  • When to backup: Once during initial setup, store securely offline
  • Limitations: Seed alone isn't enough to recover Lightning channels
  • Storage: Must be kept in the most secure manner—paper backup, metal backup, or hardware security module
Security Note: Never store seed phrases digitally in unencrypted form. Consider using multi-signature or seed splitting techniques for critical nodes.

Backup Best Practices

Implementing a robust backup strategy requires attention to several key aspects.

Regular Scheduling

  • Automate SCB backups after channel events
  • Set up periodic backup verification checks
  • Document backup history and verification results
  • Maintain backup frequency appropriate to your node's activity level

Secure Storage

  • Encrypt all backup files before storing
  • Use strong, unique passwords for encryption
  • Store critical backups offline in secure locations
  • Implement the 3-2-1 backup rule: 3 copies, 2 different media types, 1 off-site

Testing & Verification

  • Regularly test recovery procedures in a safe environment
  • Document step-by-step recovery processes
  • Verify backup integrity through checksums
  • Practice recovery annually or after major software upgrades

Advanced Backup Solutions

  • Continuous Backup Services: Some implementations offer services that stream channel updates to remote backup locations in real-time.
  • Channel Data Redundancy: Running redundant nodes with synchronized channel states.
  • Infrastructure-as-Code: Automated node setup scripts that can redeploy your entire node configuration from scratch.
  • Backup Encryption: Use GPG or similar encryption to protect backups stored remotely.

Recovery Procedures

Having a documented recovery plan is as important as the backups themselves. Here's a general outline of recovery procedures.

Recovery Planning

  • Documentation: Maintain detailed, step-by-step recovery instructions for different failure scenarios.
  • Contact Information: Include contact details for support resources, peers, and service providers.
  • Recovery Environment: Prepare a secure environment (hardware, software) for recovery operations.
  • Decision Tree: Create a flowchart for determining which recovery procedure to follow based on the nature of the failure.

Common Recovery Scenarios

SCB Recovery (Data Loss, Node Failure)
  1. Set up a new node with the same seed
  2. Import the most recent SCB file
  3. Start the recovery process (implementation-specific)
  4. Wait for force-close transactions to confirm
  5. Recover on-chain funds after timelock periods expire
Full Restoration (Hardware Replacement)
  1. Install OS and Lightning implementation
  2. Restore seed/private keys
  3. If safe, restore database backup (only if node was cleanly stopped)
  4. Alternatively, use SCB for emergency recovery
  5. Reconnect to peers and verify channel states
Seed-Only Recovery (Last Resort)
  1. Restore node with seed phrase
  2. Recover on-chain funds
  3. Without channel data, you'll need to wait for peers to force-close channels
  4. Monitor the blockchain for closing transactions
  5. Claim funds after appropriate timelocks expire

Warning: This approach is the least optimal and may result in loss of funds if peers don't force-close or attempt to cheat.

Implementation-Specific Recovery Commands

LND Recovery

lnd --lnddir=~/.lnd --bitcoin.active --bitcoin.mainnet --restorebackup.filepath=/path/to/channel.backup

Core Lightning Recovery

lightning-cli restorebackup /path/to/backup_file

Note: These are simplified examples. Always refer to the most current documentation for your specific implementation and version.

Node Operations

Node Operations→Backups
Intermediate
Complete verification first