Enable Channel Backups and Fund Recovery on LND — Lightning Network

5 min readApr 24, 2019

Well, you have your lightning LND node ready and running, but now you are worried what if something goes wrong like your instance/VM crashes and you lose data… Especially channel data, how would you restore funds committed to open channels?

Note. Try this on testnet before working with mainnet.

Recently SCB — Static Channel Backup got integrated into the master branch. So I went ahead and tried it out.

This is a guide to help you implement static channel backup and restore on your LND node.

If you are new to Lightning Network, check out my beginners guide to setting up a lightning node and configuring it to send and receive payments.

Before we get into details, let me quickly tell you what can you expect from SCB and it’s way of working.

You have some channels open with local-balance committed. Without SCB you run a risk of losing these funds in case of a hard-drive failure. Well, then how does SCB protect against this loss of funds?

Enabling SCB automatically backs up your channel data whenever new channels are opened or old ones are closed. This is done by backing up the data into a file named channel.backup . Now, this file resides within the same machine which is not at all ideal, but we will address this later. Given that you have a channel.backup file and your seed, in case of data loss, you will restore the wallet using your seed, next you will use the CLI command restorechanbackup and pass the path to your channels.backup file. This should be enough to recover your on-chain and also the local funds committed into channels.

The channel backup file is encrypted using a key derived from your wallet seed.

$ lncli restorechanbackup [command options] [--single_backup] [--multi_backup] [--multi_file]# --single_backup value  a hex encoded single channel backup obtained from exportchanbackup
# --multi_backup value   a hex encoded multi-channel backup obtained from exportchanbackup
# --multi_file value     the path to a multi-channel back up file

More about this command here.

Once your LND node receives this command, it sends out a close channel request to the nodes with which you have channels open. Now the nodes with data loss protection enabled will force close the channel and you will have your funds back on-chain. The nodes with no data loss protection may or may not obey this protocol and your funds might get lost forever. Hence it’s a good parameter to consider before opening a channel with other nodes. However, the good news being, all lnd nodes above 0.5 support data loss protection.

Enabling Static Channel Backups on your LND node

As a practice, you must first implement the complete scenario on TestNet and once you are comfortable, move on to the MainNet implementation. This way you won’t run into an unexpected situation which could result in loss of coins.

Now that we know the importance of SCB, let’s enable it onto our node and make arrangements to upload the backup-file to AWS S3.

If you are running an older version you will have to first update your LND node to the version that supports SCB. SCB was released in v0.6-beta.

To do so navigate into the LND directory.

cd $GOPATH/src/github.com/lightningnetwork/lnd

next pull to the latest version `git pull`.

Run make clean && make && make install

Once done, restart your LND.

Now the SCB should be running and you will find a channel.backup file within your LND data directory. By default, it’s located at ~/.lnd/data/chain/bitcoin/testnet for testnet.

Securing Backups on AWS S3

Now we have SCB running but the backup file resides on the same machine. This is not an ideal situation.

We need to make sure the backup file is backed up on a different machine or on a service like S3. To be able to recover funds in case of a hard drive failure, which is a disaster.

Darwin here has created a script that watches channel.backupfile for changes using inotify and uploads it to S3. We will use the same to enable backups.

apt install inotify-tools awscli

Now we will first configure our AWS credentials.

aws configure

Enter your AWS-Access-Key and the Secret. In case if you don’t have them, you can read here how to get one.

This creates a .aws folder within your home directory and stores the credentials. However, what I have noticed during my implementation is that the lnd-auto-backup script looks for the AWS credentials within the /root directory, so just copy the folder to the same.

cp -r ~/.aws /root/

Next clone the lnd-auto-backup repository.

git clone https://github.com/darwin/lnd-auto-backup

cd lnd-auto-backup

Create an environment file to configure.

nano .envrc

export LNDAB_S3_BUCKET=lightningbtc#export LND_HOME= # if differs from $HOME/.lnd
export LND_NETWORK=testnet
export LND_CHAIN=bitcoin
export LND_BACKUP_SCRIPT=./backup-via-s3.sh
export LNDAB_CHANNEL_BACKUP_PATH=/home/ubuntu/.lnd/data/chain/bitcoin/testnet/channel.backup #Exact path to your channel.backup file.

Modify LNDAB_HOME(Absolute path to LND Auto-Backup directory) in ./service/lnd-auto-backup.service to point to the right directory.

Run…

./service/install.sh./service/start.sh - start it!./service/status.sh - just to check the status./service/enable.sh - if it looks good, enable service launching after system restart

Keep watching the lnd-auto-backup directory for updated instructions.

Recovering Funds

On-chain

Without going much into details, for recovering on-chain funds, you need to have the seed(24-word-mnemonic) of your LND wallet. After running lncli create you will be asked to enter this seed. Please read the official recovery guide here for more details.

Off-Chain

There are two methods of recovery one can use here, if you are creating a node from scratch you can pass the channel.backup on the create command.

lncli create -multi_file=channel.backup

Otherwise, you can also use the restorechanbackup command…

lncli restorechanbackup --multi_file=./channel.backup

Conclusion

SCB is a safe way to recover channel funds in case of a data loss. This is also recommended by the LND devs, other methods such as using rsync are quite risky and can result in a heavy penalty in case of a state mismatch.

My recommendation is to replicate a disaster scenario in testnet and try to recover funds: open a few channels, backup channel.backup file. Now stop this node and create a new one and try recovering the funds.