Lightning Auto-Backup / Monitoring

Technik
,
#1

Hallo zusammen,

aufgrund des Beitrags von @Carlos im Lightning Channel Austausch-Thread habe ich mich auf die Suche nach einer Backuplösung gemacht und bin über diesen informativen Beitrag gestolpert: Enable Channel Backups and Fund Recovery on LND — Lightning Network | by Rahil Shaikh | Medium

Darin wird eine Möglichkeit beschrieben, die für den LND-Recovery-Prozess essentielle Datei „channel.backup“ automatisiert bei jeder Änderung (mittels " inotifywait") zu sichern: GitHub - darwin/lnd-auto-backup: A simple automatic backup service for your LND node

Die Datei „channel.backup“ wird durch Channel-Öffnungen, -Schließungen und Operationen (Routings, Rebalancing, etc.) im LND-Netzwerk geändert.

Das Ziel der Sicherung kann hierbei vielfältig sein:

  • rsync (ssh) zu Cloud-Lösung, wie z.B.
  • S3 (Amazon Cloud Service)
  • Custom-Lösung (z.B. Kopie der channel.backup auf einen USB-Stick speichern)

Dies lässt sich in die bestehende Umbrel-Lösung als zusätzlicher Service integrieren. Die Backupdateien haben - zur besseren Unterscheidung - Zeitstempel im Namen: bitcoin_mainnet_20210406_1410_58_channel.backup

Ressources:

Lightning Unklarheiten
#2

Toll! SCB ist echt ein mega feature!
Was mir jetzt sorgen bereitet ist, dass durch diese Methode zwar Hardware-Fehler nicht mehr so schlimm sind, aber was wenn die Software, durch einen Fehler, defekte Daten schreibt? Hierfür müsste man also eine Art „Rolling-Backup“ erstellen, dass man im Notfall nicht das aktuellste Backup (mit defekten Daten), sondern das Backup von vor 24h wiederherstellen kann. Damit würde man dann vielleicht nicht alle Channel retten können, aber wenigstens einige!

#3

Welche Software soll defekte Daten schreiben? LND oder das Monitoring?

#4

Hab hier auch noch was

1 Like
#5

Das LND meine ich. Kann ja immer mal passieren, dass es einen Bug gibt. Um sich davor zu schützen, sollte man mehr als nur den aktuellsten State sichern, oder?

#6

Gut, wenn LND falsche Daten schreibt, ist man sowieso raus aus der Nummer. Dann hilft ggf. nur noch die channel.db.
Für die Wiederherstellung muss es die letzte Version sein, alles davor könnte bereits einen alten Stand darstellen, was bei den Channelpartnern als Betrugsfall gewertet werden könnte.

#7

Das kommt ganz drauf an wie viele Channel du hast. Evtl. lohnt es sich einen Channel zu „betrügen“ um 100 weitere zu retten. Weißt du wie ich das meine?

#8

Ja, das ist verständlich. Mit einem Restore per channel.backup werden die Kanäle sowieso geschlossen. Es geht daher eher um die Vermeidung der Strafe. Habe das Monitoring nun mal Laufen und beobachte, wie oft die Channel-Datei tatsächlich weggesichert bzw. geändert wird (bei aktuell 14 Kanälen).

1 Like
#9

Ich freu mich sehr auf deinen Bericht!

#10

Kurzes Zwischenfazit:
Apr 6 14:08 bitcoin_mainnet_20210406_1410_58_channel.backup ← Initiales Backup
Apr 8 09:03 bitcoin_mainnet_20210408_0903_28_channel.backup ← Neuen Kanal initiiert
Apr 8 09:22 bitcoin_mainnet_20210408_0922_20_channel.backup ← Neuer Kanal bestätigt
Apr 8 12:48 bitcoin_mainnet_20210408_1248_16_channel.backup ← Reboot (Start/Stop) Umbrel
Apr 8 14:04 bitcoin_mainnet_20210408_1405_00_channel.backup ← Reboot (Start/Stop) Umbrel

Bislang hatte ich noch keine Änderung der Channel Balance. Ein Rebalancing hatte ich bisher nicht hinbekommen. Ich beobachte weiter.

#11

Was Rebalancing angeht war ich bis jetzt nur mit BOS erfolgreich. Ich hab einige Channels manuell gebalanced. Simple mit der anderen Seite Kontakt auf genommen, einer macht onchain TX der andere Keysend (und ja das ist eine vertrauens sache). Loop Out und In klappt auch aber halt sehr teuer.

#12

Fazit:
Nach ein paar Routing Events konnte ich feststellen, dass dies keine neue channel.backup erzeugt bzw. diese verändert. Daher würde es genügen, die channels.backup manuell nach jeder Kanalöffnung und -schließung wegzusichern.