A Lightning backup plan starts with a recovery question: which files and secrets does your node implementation need, and what happens when you restore them?
An encrypted copy in another location can survive the loss of your primary server. It cannot make an outdated channel database safe to use or guarantee that your channels stay open. Before choosing where to store backups, document the recovery method your node supports.
Start with your node implementation
Lightning implementations have different backup formats and recovery procedures. Record your software version, database backend, backup method, and the instructions that apply to that combination.
LND: protect the seed and static channel backup
Keep your wallet recovery seed, any required seed passphrase, and a current copy of the static channel backup, commonly stored as channel.backup. Copy the backup off the node when it changes, particularly after opening channels, and monitor whether those copies succeed.
Restoring a stale LND channel.db can lose funds. Do not treat a scheduled database snapshot as a safe way to restart active channels. If a node fails, preserve the original files before attempting recovery and follow the LND recovery guidance.
A Static Channel Backup (SCB) supports fund recovery. It does not restore channels for uninterrupted routing. Recovery asks peers to force-close channels so funds can return on-chain. Peer availability, confirmations, and applicable timelocks affect when funds become spendable.
The LND backup planning guide explains what to retain before a failure.
Core Lightning: follow its own backup procedure
Core Lightning uses different recovery material, including hsm_secret and, where supported, emergency.recover. Protect the secrets and any passphrase required by your version. The root secret alone is insufficient to recover all funds held in channels.
Core Lightning also warns against snapshot-style database backups because lost channel state can lead to lost funds. Follow its backup documentation for your version and database setup; do not apply LND file-copy instructions to CLN.
Other implementations and packaged nodes
Use the implementation's documented recovery process. A dashboard button labeled "backup" may cover configuration or wallet data without preserving everything required for channel recovery. Check its scope before relying on it.
Store encrypted copies outside the primary failure zone
Geographic separation helps when a fire, theft, storage failure, or regional outage affects your primary site. A location abroad can provide that separation, but crossing a border alone does not make a backup independent.
Evaluate the storage account, credentials, provider, and recovery access as well as the physical location. If one compromised administrator account can delete every copy, the arrangement still has a shared point of failure.
Build the storage process around these requirements:
- Encrypt before upload. Protect backup contents at rest and use an encrypted transfer connection.
- Keep recovery access independent. Retain decryption keys and account recovery material where losing the primary node will not make them inaccessible.
- Limit permissions. Give the automated backup process only the access it needs. Use separate protection for retained copies where available.
- Monitor successful copies. Alert on failed transfers and verify that expected backup changes reach the destination.
- Document the contents. Record the node implementation, version, creation time, and supported recovery purpose without exposing secrets in logs.
An old archive may help an investigation, but its existence does not make it safe to restore as live channel state. Encryption and retention protect files; neither establishes whether those files are suitable for recovery.
Rehearse recovery without endangering live channels
A recovery drill should prove that you can retrieve and use the required material without accidentally activating a second copy of your production node.
- Check access from a separate machine. Confirm that an authorized operator can retrieve the encrypted backup if the primary server is unavailable.
- Verify decryption and integrity in isolation. Keep production recovery material away from public services, shared logs, and unrelated accounts.
- Review the recovery instructions. Confirm that they match the implementation and version you run.
- Practice the full procedure with a disposable test node. Use a test network and test funds to learn the recovery sequence and its limitations.
- Record gaps and repeat after changes. Recheck the procedure when software, credentials, storage destinations, or responsible operators change.
Do not connect a restored production clone to peers as a routine drill. Do not invoke SCB recovery against live channels merely to check that the backup works: it can trigger channel closures.
Separate fund recovery from service recovery
Your recovery plan needs two different milestones: recovering access to funds and returning to routing or payment operations.
With LND SCB recovery, existing channels close rather than resume. Getting back to normal operation may require opening new channels, funding them, and rebuilding liquidity. A server that starts successfully has not necessarily completed financial recovery.
Plan for peer delays, chain synchronization, transaction fees, and the work needed to rebuild service. Avoid promising a fixed recovery time based only on how quickly a virtual machine can be recreated.
Frequently asked questions
Is a daily server snapshot enough?
No. A snapshot does not establish that channel state is safe to restore. Use the backup and recovery method supported by your Lightning implementation, and verify that its required recovery material reaches independent storage.
Does an offshore backup have to be in another country?
"Offshore" usually means abroad, but the practical requirement is meaningful separation from the failures you are planning for. Another country may help with geographic diversity; it does not remove security responsibilities or legal obligations.
Can a watchtower replace backups?
No. A watchtower can help respond to certain attempts to settle channels using revoked states. It does not replace your wallet secrets, recovery files, or a tested restoration procedure.
Choose infrastructure around the recovery plan
Once you know what you must store, estimate capacity, retention, transfer needs, and administrative access. Confirm which responsibilities remain with you, including encryption, backup automation, monitoring, and recovery testing.
For a separately managed backup destination, review CR Servers VPS options against those requirements. Choose the infrastructure after defining the recovery process.
For broader deployment considerations, read hosting Bitcoin infrastructure in Costa Rica.