Skip to content

Conversation

@cdecker
Copy link
Contributor

@cdecker cdecker commented Apr 3, 2020

Backups are a major issue in the Lightning Protocol, given that any sort of
dataloss could potentially result in loss of funds. This means that restoring
an old backup of the database could result in the node broadcasting an old
state, which is a cheat attempt in the protocol, which is punished.

This plugin implements the basic mechanisms to create a synchronous backup of
any change to the database, and ensures that the backup stays in sync with the
database. It does so in a generic way allowing to write backups to a variety
of backends, but initially only implements a file-system based backup backend
that is located on the same machine, but on a separate disk. Doing so already
provides protection against data corruption on the primary disk. Potential
future improvements could include:

  • Backup to Google services. Examples include:
    • GDrive
    • Google Docs - Sheets
    • Google Cloud Storage
  • Backup to Dropbox
  • Send backup data to a peer using the custommsg hook
  • Backups to a dedicated backup server

In the case of a dedicated backup server the plugin could also manage a
subscription that is used to pay for the backup service.

@codecov
Copy link

codecov bot commented Apr 4, 2020

Codecov Report

Merging #97 into master will increase coverage by 4.92%.
The diff coverage is 86.80%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #97      +/-   ##
==========================================
+ Coverage   47.75%   52.67%   +4.92%     
==========================================
  Files          15       17       +2     
  Lines        1734     1984     +250     
==========================================
+ Hits          828     1045     +217     
- Misses        906      939      +33     
Impacted Files Coverage Δ
backup/backup.py 84.87% <84.87%> (ø)
backup/backup-cli 95.55% <95.55%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c3c2079...360180e. Read the comment docs.

@cdecker cdecker force-pushed the backup branch 2 times, most recently from 38afa59 to 57745da Compare April 12, 2020 14:29
@cdecker cdecker marked this pull request as ready for review April 12, 2020 14:30
cdecker added 15 commits April 12, 2020 18:55
Also implements the `stream_changes` function in the FileBackend which is used
by `restore` to get all the changes.
The node_factory from pyln-client clears the node directory when provisioning
a new node, which interferes with the backup-cli creation of the initial
snapshot. This just disables the cleaning until we can release the next
pyln-client version
We heavily rely on foreign key constraints to keep the DB consistent and drop
dependent objects such as UTXO set entries when we roll back a block. We also
need to enable the foreign key constraints when restoring otherwise these
dependents are not removed and we run into constraint violations.
@cdecker cdecker merged commit ef31a4a into master Apr 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants