La documentación de Core Lightning lo resume así: recuperar el hsm_secret basta para los fondos on-chain, pero es necesario e insuficiente para los fondos en canales. En LND ocurre lo mismo con la seed aezeed.

Cada vez que un canal se actualiza, los dos nodos revocan el estado anterior. Si un nodo publica un estado revocado, su par puede reclamar todo el saldo del canal como castigo. Ese mecanismo protege contra el fraude, pero también castiga a quien restaura por error una base de datos atrasada.

De ahí salen dos reglas que conviene escribir en tu ficha: nunca arranques el nodo con una base de datos antigua y nunca tengas dos instancias del mismo nodo funcionando a la vez. La guía de LND insiste en que el nodo antiguo permanezca apagado durante toda la recuperación y después.

Si tu wallet Lightning es custodial o la gestiona un proveedor, la recuperación depende de sus mecanismos: consulta su documentación y no apliques esta guía. Si administras un nodo LND o Core Lightning, identifica implementación y versión con lncli getinfo o lightning-cli getinfo: los procedimientos no son intercambiables entre productos ni siempre entre versiones.

1. PASO 1 · Secreto raíz en LND: la seed aezeed se muestra una sola vez al crear la wallet. Si no la anotaste entonces, no puedes volver a verla: planifica migrar a una wallet nueva antes de confiar en el nodo.
2. PASO 2 · Secreto raíz en Core Lightning: en versiones con frase BIP39, lightning-hsmtool getsecret la muestra; en versiones anteriores el hsm_secret es un archivo binario que se respalda en hexadecimal. Guárdalo offline, como una seed.
3. PASO 3 · Copia estática en LND: el archivo channel.backup está en .lnd/data/chain/bitcoin/mainnet/ y se actualiza al abrir o cerrar canales. También puedes exportarlo con lncli exportchanbackup --all --output_file RUTA. Guarda una copia fuera del equipo tras cada canal nuevo.
4. PASO 4 · Copia estática en Core Lightning: el archivo emergency.recover del directorio de datos se actualiza al abrir canales; respáldalo después de cada canal nuevo.
5. PASO 5 · Base de datos: no hagas copias «instantánea» del nodo en marcha para restaurarlas después. Core Lightning recomienda la replicación en tiempo real de su base de datos; en LND, channel.db solo es útil si es el último estado del propio nodo que falló.
6. PASO 6 · Ensaya en laboratorio: en signet o regtest, restaura seed y copia estática en un nodo nuevo y observa cómo se cierran los canales y vuelven los fondos on-chain. Nunca con canales reales.
7. PASO 7 · Documenta: implementación, versión, dónde está cada copia, cuándo se actualiza y quién decide restaurar, sin escribir secretos. Usa una ficha física de recuperación.

En LND, tras restaurar la seed se usa lncli restorechanbackup --multi_file RUTA/channel.backup. Tu nodo contacta con cada par, le indica que ha perdido datos y le pide que cierre el canal publicando su último estado. Después, tu parte llega on-chain, en algunos casos tras un periodo de espera.

En Core Lightning, emergency.recover cumple un papel equivalente y, según su documentación, requiere la cooperación de los pares y debe usarse solo como último recurso.

Consecuencias en ambos casos: pierdes los canales (se cierran todos), pagas las comisiones on-chain de los cierres y dependes de que cada par esté en línea. Lo que normalmente no pierdes son los fondos que te correspondían.

1. Seed: sé que recupera fondos on-chain, no el estado de los canales.
2. Copia estática: sé dónde está, cuándo se actualiza y que cierra los canales al usarla.
3. Base de datos: no restauro copias antiguas ni arranco dos instancias.
4. Implementación: sigo el procedimiento de mi software y versión.
5. Ensayo: pruebo la recuperación solo en laboratorio y documento el resultado.

• LND — recuperación ante desastres ↗
• Core Lightning — copia de seguridad del nodo ↗