Antes de elegir dónde guardar los respaldos de su nodo Lightning, defina cómo recuperaría los fondos si el servidor dejara de funcionar. Los archivos necesarios y el procedimiento dependen de la implementación que utilice.
Una copia cifrada en otra ubicación puede sobrevivir a la pérdida del servidor principal. Sin embargo, no convierte una base de datos desactualizada en un respaldo seguro ni garantiza que los canales permanezcan abiertos. La ubicación del respaldo y el método de recuperación deben evaluarse por separado.
Identifique qué necesita su implementación
Documente la versión del nodo, el sistema de base de datos, los archivos que debe conservar y las instrucciones de recuperación correspondientes. No suponga que un procedimiento válido para LND también sirve para Core Lightning.
LND: conserve la semilla y el respaldo estático de canales
Proteja la semilla de recuperación de su billetera, cualquier contraseña adicional que la proteja y una copia actualizada del respaldo estático de canales, normalmente almacenado en channel.backup. Copie ese archivo fuera del nodo cuando cambie, especialmente después de abrir canales, y verifique que la transferencia se complete.
Restaurar un archivo channel.db desactualizado de LND puede causar pérdida de fondos. Una instantánea periódica de la base de datos no debe tratarse como un mecanismo seguro para reiniciar canales activos. Ante una falla, conserve los archivos originales antes de intentar una recuperación y consulte la guía de recuperación de LND.
El respaldo estático de canales, o SCB, permite iniciar un proceso de recuperación de fondos. Solicita a los nodos contraparte que cierren los canales de forma forzada para recuperar los fondos en la cadena de Bitcoin. La disponibilidad de las contrapartes, las confirmaciones y los plazos de bloqueo aplicables influyen en cuándo podrá disponer de ellos.
La guía de preparación de respaldos de LND detalla qué material debe conservar antes de una falla.
Core Lightning: siga su propio procedimiento
Core Lightning utiliza material de recuperación diferente, como hsm_secret y, cuando corresponda, emergency.recover. Conserve los secretos y las contraseñas que requiera su versión. El secreto raíz por sí solo no basta para recuperar todos los fondos en canales.
Core Lightning también advierte sobre las instantáneas de la base de datos: perder estados de canales puede provocar pérdida de fondos. Consulte su documentación de respaldos para la versión y configuración que utiliza.
Otras implementaciones y plataformas de administración
Revise el alcance del respaldo que genera su plataforma. Un botón llamado "respaldo" puede guardar la configuración o información de la billetera sin incluir todo lo necesario para recuperar fondos de los canales.
Mantenga copias cifradas fuera de la ubicación principal
La separación geográfica reduce la posibilidad de que un incendio, robo o interrupción regional afecte tanto al nodo como a sus respaldos. Una ubicación en el exterior puede aportar esa separación, pero la distancia por sí sola no elimina las dependencias compartidas.
Evalúe también el proveedor, las cuentas y las credenciales. Si una sola cuenta comprometida permite borrar todas las copias, su estrategia conserva un punto común de falla.
Organice el almacenamiento con estos criterios:
- Cifre antes de transferir. Proteja el contenido almacenado y utilice una conexión cifrada para enviarlo.
- Conserve acceso independiente. Guarde las claves de descifrado y el material de recuperación de cuentas donde pueda recuperarlos aunque pierda el nodo principal.
- Limite los permisos. Asigne al proceso automático únicamente el acceso necesario y proteja las copias retenidas frente a borrados cuando sea posible.
- Supervise las transferencias. Configure alertas ante fallas y compruebe que los cambios esperados lleguen al destino.
- Identifique cada respaldo. Registre la implementación, versión, fecha y finalidad de recuperación sin incluir secretos en los registros de actividad.
Una copia antigua puede aportar información para investigar una falla. Eso no significa que sea seguro activarla como estado vigente del nodo. El cifrado protege los archivos; no corrige un estado de canal desactualizado.
Practique la recuperación sin poner en riesgo los canales activos
Un simulacro debe comprobar que usted puede acceder al material necesario y seguir el procedimiento, sin activar accidentalmente una segunda copia del nodo de producción.
- Compruebe el acceso desde otro equipo. Verifique que una persona autorizada pueda obtener el respaldo aunque el servidor principal esté fuera de servicio.
- Valide el descifrado y la integridad en un entorno aislado. Evite exponer secretos en servicios públicos, registros compartidos o cuentas ajenas al proceso.
- Revise las instrucciones. Confirme que correspondan a la implementación y versión instaladas.
- Ensaye el procedimiento completo con un nodo de prueba. Utilice una red de pruebas y fondos de prueba para conocer la secuencia y sus limitaciones.
- Documente los problemas encontrados. Repita las comprobaciones después de cambiar software, credenciales, destinos de almacenamiento o responsables.
No conecte una copia restaurada del nodo de producción a sus contrapartes como parte de un simulacro rutinario. Tampoco invoque la recuperación SCB sobre canales activos solo para comprobar el archivo: puede provocar su cierre.
Distinga la recuperación de fondos del retorno al servicio
Su plan debe contemplar dos resultados: recuperar acceso a los fondos y volver a operar pagos o enrutamiento.
La recuperación mediante SCB no es una conmutación sin interrupciones. En LND, los canales se cierran en lugar de reanudar su funcionamiento. Volver a operar puede requerir abrir canales nuevos, financiarlos y reconstruir la liquidez.
Que el servidor arranque correctamente no significa que la recuperación financiera haya terminado. Considere la disponibilidad de las contrapartes, la sincronización con la cadena, las comisiones y el trabajo necesario para restablecer el servicio. El tiempo de creación de un servidor no basta para estimar todo ese proceso.
Preguntas frecuentes
¿Una instantánea diaria del servidor es suficiente?
No. Una instantánea no demuestra que el estado de los canales sea seguro para restaurar. Utilice el método admitido por su implementación y compruebe que el material necesario llegue a un almacenamiento independiente.
¿El respaldo debe estar en otro país?
El término "offshore" suele referirse al exterior. Para planificar la recuperación, lo esencial es separar las copias de las fallas que podrían afectar la ubicación principal. Otro país puede aportar diversidad geográfica, pero no elimina sus responsabilidades de seguridad ni las obligaciones legales aplicables.
¿Una torre de vigilancia sustituye los respaldos?
No. Una torre de vigilancia, o watchtower, puede ayudar frente a ciertos intentos de cerrar canales con estados revocados. No sustituye los secretos de la billetera, los archivos de recuperación ni un procedimiento probado.
Elija infraestructura para su plan de recuperación
Una vez definido qué debe conservar, estime la capacidad, la retención, las transferencias y el acceso administrativo que necesita. Confirme quién se encargará del cifrado, la automatización, la supervisión y las pruebas.
Si necesita un destino de respaldo administrado por separado, revise las opciones de servidores virtuales de CR Servers según esos requisitos. La infraestructura debe responder al procedimiento de recuperación que usted haya definido.
Para evaluar el entorno de despliegue, consulte la guía sobre hospedaje de infraestructura Bitcoin en Costa Rica.