Progress pill
Creating your first Lightning node

Backing up your Lightning node

Set up Your First Lightning Node

Backing up your Lightning node

  • What should I save on a Lightning node?
  • How does Umbrel manage the backup of your LND node?
  • Best practices to limit the risk of loss
  • How do I save my Lightning node on Umbrel?
Before sending your first sats to your node, it's important to understand how its backup works and what the associated risks are. Unlike a simple Bitcoin onchain wallet, backing up a Lightning node is quite complex: the wrong strategy can lead to the permanent loss of your funds. In this chapter, we'll look at what really needs to be backed up, and how Umbrel handles this process with LND.
In this course, we'll be using the LND (Lightning Network Daemon) implementation. Although the principles are similar on the other implementations, the recovery files and procedures I'm going to talk about are specific to LND.

What should I save on a Lightning node?

On a Lightning node, it's not enough to save the seed and hope that everything will return to normal. Several elements play different roles, so it's important to distinguish between them.

The seed (aezeed)

When you initialize LND, you receive a 24-word seed. This is a LND-specific format called "aezeed". It's not a classic seed BIP39, although it looks a lot like one. From this seed, LND derives the private keys of your onchain wallet associated with the Lightning node, i.e. the addresses into which you can receive or to which you can repatriate bitcoins following channel closures.
This seed can therefore be used to recreate the onchain wallet associated with your node, and to retrieve funds that have already been repatriated onchain (e.g. after a channel closure). On the other hand, the seed alone is not sufficient to restore your Lightning channels that are still open, as it does not contain the necessary information on the status of your channels.

The channel database (channel.db)

LND stores the detailed status of your channels in a database named channel.db. This database contains:
  • the list of your open channels;
  • your peers and their identifiers;
  • the last commitment transactions for each channel (the successive states that define who owns what in the channel and enable onchain funds to be recovered in the event of a problem);
  • the information needed to punish a peer who tries to broadcast an old report.
The problem with this database is that it's constantly changing: every payment, every routing, every opening or closing of a channel modifies its contents. This is why a conventional backup (e.g. a periodic copy of your channel.db) is dangerous. If you restore too old a version of channel.db and reassemble the node with this obsolete state, your peers may consider that you are broadcasting an old channel state. In this case, the protocol provides for a penalty: your peer can recover the full amount of the channel's funds, as if you'd tried to cheat.
In practice, then, channel.db is not a backup medium as such. It's the living state of your node. The only situation in which it makes sense to use it to restore your node is when you recover this database directly from a machine that has just failed (e.g. a disk that is still readable). In this case, you recover the most recent state and can restart LND on another machine based on this database, safe in the knowledge that this state is as up-to-date as possible, since the old machine is no longer running. Another situation where this method can serve as a relevant backup is in a two-disk configuration, with a dynamic, permanent copy from one to the other. However, this type of set-up is more complex to implement.
But making periodic copies of channel.db and storing them as backups to be restored later is a very bad idea: the day you use them, you run the risk of penalizing yourself and losing all your sats.

Static Channel Backup (SCB)

To make disaster recovery possible, LND has introduced the Static Channel Backup (SCB) mechanism. This is a special file, often called channel.backup, which contains static information about your channels: who your peers are, how to contact them and what your channels are.
This file does not contain detailed channel status or update history. It does not allow you to reopen channels in the exact state they were in, nor to continue operating this Lightning node. Rather, its role is to act as an anchor point to ask your peers to help you cleanly close all your channels, and thus receive your sats onchain, on keys that you can retrieve thanks to the seed. So, unlike the channel.db file, which is modified with each payment or routing, the SCB file is only updated when a channel is opened or closed.
When recovering via SCB, the process is as follows:
  • You restore your seed (aezeed), which recreates your onchain wallet associated with the Lightning node;
  • You provide LND with your most recent SCB;
  • LND uses the SCB to find the list of your peers and the channels you have with them;
  • It contacts each peer, tells them that you've suffered a data loss and asks them to "force-close" your channel with them, so that you can recover your onchain share.
The idea is that your peers, noticing that you're reporting a loss of data, will broadcast their last commitment transaction and close the force channel. Once these transactions have been confirmed, your funds reappear in your onchain wallet (linked to the seed).
This recovery mechanism isn't perfect, however. Firstly, it doesn't actually restore your Lightning node, since all channels will be closed. You'll then have to build a new Lightning node from scratch. Secondly, it does not guarantee 100% recovery, although it does considerably increase the chances of recovering your onchain balances in the event of a problem. Indeed, this recovery protocol depends on the cooperation and availability of your peers: if one of them is offline, has lost its own data or refuses to cooperate, your funds may remain blocked, or even be permanently lost. That's why it's important not to keep channels open on your Lightning node with unreachable peers for long periods of time. If you suffer a data loss at that point and the peer remains unreachable, recovery via SCB will be impossible, and your funds will remain lost until that peer comes back online (perhaps forever).
To sum up, a good Lightning backup strategy on LND rests on three pillars:
  • Your seed (aezeed), for the onchain layer;
  • Reliable automatic SCB backup;
  • Good channel management by choosing reliable peers and preventively closing those that are often unreachable.

How does Umbrel manage the backup of your LND node?

Umbrel offers a simplified backup mechanism for the LND node, based precisely on the SCB. The idea is to save you the trouble of manipulating this file yourself, making a backup of it and automating the process as far as possible.
When you create your node on Umbrel, you receive a seed which plays a dual role:
  • it derives your Bitcoin onchain wallet associated with your Lightning node;
  • it is used to derive a backup identifier and encryption key used for remote SCB backups.
Thanks to this mechanism, Umbrel automatically makes an encrypted backup of your SCB and stores it on its servers via Tor. The SCB is stored encrypted, thanks to a key derived from your seed. So, in the event of data loss, all you have to do is recreate a Bitcoin and Lightning node on Umbrel, on the same or another machine, then enter your seed. You'll then be able to retrieve the latest SCB status from the Umbrel servers, decrypt it and start the process of recovering your funds.
These backups are locally encrypted by your node before being sent, which guarantees the confidentiality of your data: Umbrel cannot read the contents of the SCB. Transmission takes place via Tor, which prevents your IP address from being leaked. What's more, your Umbrel adds noise to the traffic (random padding and false backups sent at irregular intervals) to prevent the server from deducing precisely when you open or close a channel.
The main advantage of this method is that it considerably simplifies the backup of your Lightning node: you only have to back up your seed once during node initialization. This does entail some risk, since it's only a backup of the SCB, but for reasonable amounts it's an acceptable compromise.

Best practices to limit the risk of loss

Even with Umbrel backup, a few simple good practices can greatly reduce the risk of losing sats:
  • Monitor the availability of your peers:
If an important channel is frequently associated with an unreachable or unstable peer, it's safer to close it cleanly while your node is still working. A preventive cooperative or forced closure eliminates a potential source of trouble in the event of SCB recovery.
  • Avoid concentrating too much liquidity on unknown peers:
The larger the channel a peer has with you, the more important it is to be reliable. Choose serious, well-connected and active nodes, so that any future recovery via SCB can run smoothly.
  • Supplement Umbrel with local backups:
In addition to Umbrel's automatic backup, you can also keep an encrypted copy of your SCB file (channel.backup) on external media and update it periodically. Ideally, you should renew it every time you open or close a channel. This gives you a backup solution if, for any reason, Umbrel's automatic backup service becomes unavailable.
  • Managing your seed the right way
Your seed Umbrel not only restores your onchain wallet, but also derives the encryption key for backups. An attacker with access to it could therefore launch a recovery and transfer your funds to his own wallet, without even having physical access to your node.
So, if you need to restore your node but no longer have your seed, you won't be able to recover anything: all your sats will be lost. So it's very important to save your seed with the utmost care, only on physical media (paper or metal), and to keep it in a safe place. For more information on managing a seed, please consult this tutorial:
backup-mnemonic
Back up your mnemonic phraseDiscover best practices for safeguarding your Bitcoin wallet

How do I save my Lightning node on Umbrel?

Now that you've understood how the theory works, let's get down to the nitty-gritty. From your Lightning Node application (which is actually LND), click on the three small dots in the top right-hand corner.
There are three elements of interest here for the backup:
  • Check that the Automatic backups option is enabled. This will automatically send your encrypted SCB to Umbrel's servers.
  • You can then choose whether to send via Tor or clearnet, using the Backup over Tor option. As explained in the previous sections, I strongly recommend that you use Tor to preserve your confidentiality.
  • Finally, there's a Download channel backup file button, which lets you download a channel.backup file, i.e. an encrypted snapshot of your SCB, to your computer. This enables you to make additional local backups from time to time, in addition to those automatically sent to Umbrel servers.
Now you know how to protect your Lightning node's sats from data loss. In the next chapter, we'll look at how to secure your node against cheating attempts.
Quiz
Quiz1/5
What's the name of the seed format specific to LND?