Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
LND Backup, Restore, Migrate

(This is still a work-in-progress)

As of 2019-04-02 the following PR is has been merged into master which implements channel backups

See also https://twitter.com/alexbosworth/status/1112857863393763329

SCB has been merged into the lnd master branch:
lightningnetwork/lnd#2313
It allows for a small backup file to be made to recover a
data-lost channel's funds with peer cooperation. The file
doesn't get out of date and only needs to be backed once on
channel start, not every update.

(to-do: add specifics on how to enable channel backups)

(to-do: include Alex Bosworth's guide Backup channel.backup using inotify )

LND Backup and Restore

Scenarios:

  • you wish to backup your LND installation in case of emergency, with ability to recover channels.
  • you wish to move your LND installation to another host, while preserving channels.

TLDR

Backup procedure

  • shutdown LND
  • make a full copy of .lnd folder
  • optional: restore copy of .lnd folder on same host, or new host
  • start LND

Restore Checklist

  • Are you restoring to same the version of LND?
  • Are you restoring on same OS?
  • Are the original files still available? (don't delete yet!)

Disclaimer & Cautious Approach

LND currently allows recovery from seed phrase, but this only recovers onchain funds not allocated to a channel. It does not recover funds in a channel.

If migrating between hosts, the more cautious approach would be to close all active channels, shutdown the host, and recover from seed on the new host, followed by establishing new channels.

Alternative, potentially reckless method

In the Lightning Makers Telegram chat @Reza asked

is there a way to export an LN wallet/channel and import again later?

@NuevoDinero responded

Just copy the .LND folder to the other computer and start lnd.

When @Reza asked the same question on the LND slack, @alexbosworth replied

Turn off the node, move the directory to where you want, restart the node with the same directory, make sure not to run both at the same time

The following issue comment also details the process

lightningnetwork/lnd#664 (comment)

Not sure if this helps, but my current solution to this is to create a script that stores
a backup of the code, channel.bd, and wallet.db.

  Stop LND 
  Backup code 
  Backup channel.db and wallet.db 
  Restart LND 

Matching the backed up data and code has always worked for me. You have to back up that
code also because at this time code changes can be breaking changes :/. I do this backup
before every attempt to update the code.

Caveats

There are some caveats with corrupted channel.db, specifically due to disk problems, or changing OS, or changing LND version, or randomly deleting files under the assumption the seed is sufficient to recover funds.

And it's important to stop LND before backing up, so in-memory components get written to disk

@joeblow mentions the following:

you'd have to backup the channel.db every time your channel states change (receiving, sending, routing) if it's a bigger node, you'd have to backup several times per day

@alexbosworth covers the shortcomings in weekly mail update:

Currently we don't support backups in lnd, which is a major gap.
One idea you can use is to use RAID to get redundancy at the filesystem level.
Our first real backup goal right now is "static backups". This will allow outsourced, simple backups.
That allow a first step of backups which will not allow a channel to be restored to its full online state, but will allow you to close out to retrieve your local balance.
A major shortcoming of the simple "static backups" is that they will require the cooperation of your peer, so obviously we are working on further improved backup solutions.
Backup solutions are made difficult by some protocol quirks that we would love to see updated, but that would require cooperation across groups and is more of an ongoing effort.

LND release notes for version 5 also includes

Dataloss Protection Recovery

Within the protocol, there exists a measure put in place that will allow nodes that have partially
or complete lost data to recovery a portion of the funds they had within active channels. We call
this feature "dataloss protection". The latest version of lnd has now completely implemented this
feature! In the rare case that users exhibit partial data loss, upon connection to a peer which we
had a channel open with, lnd will automatically prompt the user to close out the channel as it can
no longer be used. At that point, we'll then proceed to sweep out settled balance within the
commitment transaction on-chain, and clean up the remaining channel state.

Future versions of lnd, will finalize the ingratiation of this feature by also introducing static
channel backups. These backups are essentially static files which represent a description of the
channel, namely: the parameters used, location on chain, channel peer, key paths we used within the
channel, etc. With this set up backups and a users seed, in the face of total data loss, we'll be
able to recover the settled balance in the set of open channels.

As of 2018-12-10 channel backups are working in principle with a PR due soon.

lncli --network=simnet exportchanbackup --all --output_file=channels.backup

ll channels.backup
-rw-r--r--  1 roasbeef  staff   381B Dec  9 18:16 channels.backup

As of 2018-12-11 the following PR is up for testing which implements channel backups

LND Feature Requests

Feature Request to allow live backing up on channel.db without stopping LND. However it doesn't appear to be resolved yet?

Pull Request to add Data loss protect resending

From 2018-11-20 LND Evolution mailer

Static Channel Backups

Not in 0.5.1 but under very active development is the ability to
create what we call Static Channel Backups. These are serializations
of the last channel state that can be used to recover all funds in a
channel and are very compact for easy redundancy but channels must be
force-closed to complete recovery.

As always given breach potential you will need to be sure to only use the current channel state and not a revoked past state.

A PR to look at for progress on this is: "Data loss protect resending"
lightningnetwork/lnd#1937

This PR is related to storing the necessary state for backups and
recovery and may be prioritized even for 0.5.1 as a last minute
addition in anticipation of these backup features progressing in the
near term.

A future with these backups will look like having special backup files
on disk which can be monitored for outsourced backup by filesystem
monitoring or a streaming API from lnd, and these backups can also be
persisted out to remote volumes.

Also under consideration is a standardization of this format to
include a standard method of backup encryption and state so that you
could even migrate your node identity between implementations.

Automating backups

As LND is being stopped and restarted, you will need to unlock your wallet again, which makes automating the backup process troublesome.

It may be feasible to automate the process of shutting down LND, backing up, restarting LND and unlocking the wallet via the API.

More info: https://api.lightning.community/rest/index.html#v1-unlockwallet with shell script example below

$ MACAROON_HEADER="Grpc-Metadata-macaroon: $(xxd -ps -u -c 1000 $LND_DIR/admin.macaroon)"
$ curl -X POST --cacert $LND_DIR/tls.cert --header $MACAROON_HEADER https://localhost:8080/v1/unlockwallet  \
    -d '{ "recovery_window":<int32>,"wallet_password":<byte>, }' 
{ 
}

wallet_password is type byte
wallet_password should be the current valid passphrase for the daemon, set as the base64 encoded string representation of a raw byte array

However this requires storing the password in a script, which may defeat the purpose if host is compromised.

TODO: add script

Also check out lnd-auto-backup for a user-contributed solution

Relevant Discussions for Other LN Implementations

Concerns over backups of channels aren't limited to LND.

clightning

eclair

@bretton
Copy link
Author

bretton commented Apr 7, 2019

Copy link

ghost commented May 14, 2019

👍

@bretton
Copy link
Author

bretton commented May 24, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment