Happy Umbrel user here running on a DTV Electronics CmRat with UmbrelOS, backing up to another CmRat with CasaOS.
I’ve noticed something strange with how some apps handle backups. Core Lightning specifically excludes certain files like lightningd.sqlite3 from backups. The reasoning given is something like “data that could cause issues if restored (such as outdated app states that might lead to conflicts or inconsistencies).”
The lightningd.sqlite3 file contains all my channel states, balances, payment history, and peer information. Without it, I can’t properly restore my node even if I have my seed phrase. The secret gives me my keys, but that database file tells me what channels exist, their current states, and their balances.
If I lose that file and need to restore:
I lose track of which channels I have open
I can’t claim funds from those channels correctly
My counterparties could broadcast old channel states, and I won’t have the data to dispute them
All payment records disappear
I understand the concern about restoring outdated states causing conflicts. But excluding the file entirely seems like the wrong approach. At minimum, I need access to the most recent version of that database for a proper recovery.
Is there a way to include lightningd.sqlite3 in Umbrel backups? Or am I misunderstanding something about how Core Lightning recovery is supposed to work? Any insights would be appreciated.
Reasoning is that you are not supposed to “restore“ database with old channel state, which gets updated every second and cannot be safely backed up without real time replication (otherwise could get you penalty closure later), however I agree that backup / restoration workflow is kind of bad because of this and node OS like umbrel should absolutely backup lightningd.sqlite3 and channel.db (lnd) but with special workflow.. Not for automatic restoration, but to allow advanced manual recovery procedures (mostly to close zombie channels which cannot be closed with SCB during regular restoration and for few other edge cases). Over last 5-6 years dozens of bitcoins were burned because of such very unnecessary database erasures. If shtf, recovering zombie channels (not even mentioning in-flight htlcs) without database tends to be incredibly difficult due to rarely reachable / cooperative zombie peer operators.
CLN is a lot weaker compared to LND when it comes to recovery simplicity, tools and support (and LDK is only “safe to use“ for retail user strictly within Alby infrastructure.. It doesn’t use deterministic paths for channel related keys so no advanced diy recoveries like in lnd or cln..)
Sum up:
“I lose track of which channels I have open”
If you regularly backup emergency.recover, then you don’t (I assume umbrel does backup that). W/o emergency.recover you would be mostly dependent on public LN explorers to find your channels..
“I can’t claim funds from those channels correctly”
Restoring with emergency.recover will remotely f-close and claim funds as long as peer is reachable / healthy. W/o emergency.recover it can be done with chantools if you know peers and channel utxos
“My counterparties could broadcast old channel states, and I won’t have the data to dispute them”
This is a boogeyman. Can happen and that is important design assumption, but irl I have never seen confirmed instance of anyone actually doing this attack deliberately.
“All payment records disappear”
With hsm tool you can derive describtors from your hsm secret and import them to sparrow to recover onchain history and balances in sparrow (except of to_remote balances, these needs to be recovered in CLN with emergency.recover or swept manually with chantools), but LN payment records would be gone with lost database ofc..