Copia de seguridad y recuperación de una instancia de Keyright autoalojado

Un servidor de licencias se gana el sueldo estando ahí en el momento exacto en que un cliente activa. Eso hace que sus datos sean valiosos: pierde el registro de quién tiene licencia, qué puestos están reclamados y cuántos créditos quedan, y no solo estás caído —has perdido la verdad de la que dependen las instalaciones de tus clientes. Así que la copia de seguridad y la recuperación ante desastres de Keyright autoalojado merecen el mismo diseño deliberado que diste a la alta disponibilidad. La buena noticia es que la misma arquitectura que facilita la HA facilita también la DR.

Conclusión clave: Keyright autoalojado es una app sin estado cuyo estado completo vive en tu PostgreSQL, así que la DR es en realidad copia de seguridad y restauración de Postgres más salvaguardar dos secretos que tú generas. Respalda la base de datos para todo tu estado; respalda tu KEYRIGHT_KEK y tu KEYRIGHT_SIGNING_KEY por separado y de forma segura —porque sin la KEK, las claves de firma cifradas de la base de datos no pueden recuperarse.

Qué hay que respaldar de verdad

Keyright tiene exactamente dos partes móviles: una app sin estado y tu base de datos. Esa división es toda la historia de las copias de seguridad.

La app es la imagen ghcr.io/delta1-labs/keyright —un servicio ASP.NET Core en el puerto 8080, sin base de datos dentro. No guarda estado entre peticiones. Así que no hay nada en el contenedor de la app que respaldar: se reconstruye desde la imagen publicada más tu configuración y variables de entorno. Si un nodo, una VM o un clúster entero desaparece, redespliegas la misma imagen y vuelve idéntica. Trata la capa de app como ganado, no como mascotas.

Todo lo que importa vive en PostgreSQL. Licencias, activaciones y puestos, saldos de créditos y su libro mayor, el registro de auditoría, el estado de webhooks y notificaciones, tu configuración de inquilino y productos —y las claves de firma, almacenadas cifradas en reposo. Apuntas la app a él con la cadena de conexión KEYRIGHT_DB y crea y migra su propio esquema. Como todo el estado duradero se concentra en una base de datos, respaldar Keyright es respaldar esa base de datos. No hay estado de archivos disperso, ni caché local de nodo con la verdad, ni nada en un disco en algún sitio que una copia de Postgres se perdería.

Los dos secretos que una copia de la base de datos no contiene

Aquí está la parte que pilla a la gente, y lo más importante de este artículo. Dos secretos son tuyos —tú los generas, Keyright nunca los ve— y no son reconstruibles desde una copia de la base de datos:

• KEYRIGHT_KEK — una clave de cifrado de claves de 32 bytes en base64. Cifra tus claves de firma en reposo, que es exactamente por qué esas claves pueden residir con seguridad en la base de datos. El reverso: sin la KEK, las claves de firma cifradas de tu base de datos no pueden recuperarse. Un snapshot perfecto de la base de datos más una KEK perdida equivale a una instancia que ya no puede descifrar sus propias claves de firma —puede restaurar cada fila y aun así ser incapaz de firmar un solo lease con la clave original. Cada cliente que fijó la clave pública correspondiente rechazaría entonces los nuevos leases.
• KEYRIGHT_SIGNING_KEY — la clave privada RSA PKCS#8 en base64 que firma los leases sin conexión y los bloques de crédito aislados (air-gapped), y cuya mitad pública incrustan las apps de tus clientes. Si la estableces explícitamente (recomendado), forma parte de tu configuración, no algo que puedas regenerar sin volver a fijar claves públicas en cada cliente distribuido.

Así que la regla, directa de la referencia de configuración: respalda la KEK y la clave de firma por separado de la base de datos y de forma segura —en un gestor de secretos con su propia copia, una bóveda sin conexión, donde sea que tu organización guarde los secretos de nivel raíz. Nunca en la base de datos que estás protegiendo, nunca en la imagen, nunca en el control de versiones. Una copia de la base de datos y la KEK son dos mitades de una sola copia de seguridad recuperable; guárdalas en sitios distintos, pero guárdalas ambas.

Respaldar la base de datos

Todo está en PostgreSQL, así que usa herramientas estándar de Postgres. Para la mayoría de los despliegues, un dump lógico programado es el enfoque correcto más simple:

pg_dump --format=custom --no-owner \
  "host=db.internal.example.com port=5432 dbname=keyright user=keyright_app sslmode=require" \
  --file "keyright-$(date +%F).dump"

El formato custom se restaura limpiamente con pg_restore y comprime bien. Ejecútalo con un temporizador (cron, un trabajo sidecar, tu programador gestionado), copia cada dump fuera de la máquina a almacenamiento de objetos y aplica una política de retención. Verifica que el archivo no esté vacío y sea restaurable —una copia no probada es una esperanza, no un plan.

Para una instancia mayor, o un RPO más ajustado, añade copias físicas con recuperación a un punto en el tiempo (PITR). Toma una copia base y archiva el WAL para poder avanzar hasta cualquier momento:

pg_basebackup --pgdata=/backup/base --format=tar --gzip \
  --wal-method=stream --checkpoint=fast

Con el archivado de WAL configurado, el PITR te permite recuperar hasta una marca de tiempo elegida —invaluable si una migración errónea o un error del operador hay que deshacerlos hasta el segundo anterior a que ocurrieran.

Si ejecutas Postgres gestionado —que, para cualquier cosa más allá de la evaluación, deberías, con una topología de primario-más-réplica— apóyate en sus snapshots automáticos y su retención de copias. Un snapshot diario (o más frecuente) más la ventana de PITR del proveedor suele darte un RPO más fuerte que los dumps hechos a mano, y restaurar es una operación de consola o CLI. En cualquier caso, el principio es el mismo: la base de datos es donde vive cada byte de estado, así que la base de datos es en lo que inviertes para protegerla. No confíes en el Postgres de evaluación incluido que ofrecen los kits —es para probar Keyright en un portátil, no para DR en producción.

RPO y RTO para un servidor de licencias

Piensa en los dos números explícitamente, porque un servidor de licencias tiene un perfil de fallo inusualmente indulgente.

Tu RPO (cuántos datos puedes permitirte perder) lo fija tu cadencia de copias. Un pg_dump nocturno arriesga perder hasta un día de activaciones, gastos de créditos y registros de auditoría; el archivado continuo de WAL o snapshots gestionados frecuentes lo reducen a minutos. Elige la cadencia frente a cuánto historial de activaciones y libro mayor estás dispuesto a reproducir o perder.

Tu RTO (cuánto tarda la recuperación) es donde la arquitectura rinde. Como los clientes cachean un lease firmado y validan sin conexión entre activaciones, una caída no bloquea a nadie en el instante en que empieza —sus ventanas de gracia la absorben. Estás compitiendo contra la ventana de gracia de cliente más larga, no contra un cronómetro en cada arranque de la app. Eso convierte “restaurar una base de datos y redesplegar un contenedor sin estado” de una carrera frenética de segundos en una operación medida que puedes hacer bien. (Y si además ejecutas HA multinodo, los fallos rutinarios nunca llegan a ser un evento de recuperación.)

El simulacro de restauración

Practícalo antes de necesitarlo. Una restauración tiene cuatro pasos:

1. Restaura la base de datos. Desde un dump lógico, a una base de datos nueva y vacía:

   pg_restore --no-owner --clean --if-exists \
     --dbname="host=db.internal.example.com port=5432 dbname=keyright user=keyright_app sslmode=require" \
     keyright-2026-11-04.dump

   Desde un snapshot gestionado o PITR, restaura al punto que quieras a través de tu proveedor y anota la nueva cadena de conexión.

2. Redespliega la app sin estado apuntada a la base de datos restaurada vía KEYRIGHT_DB. Suministra la misma KEYRIGHT_KEK y KEYRIGHT_SIGNING_KEY de tu copia de secretos separada —este es el momento en que la KEK se gana el sueldo, descifrando las claves de firma que la restauración devolvió. Las migraciones se aplican automáticamente al arrancar, así que no hay SQL manual.

3. Instala la clave de autolicencia. Keyright es fail-closed: necesita una clave de autolicencia (o de prueba) válida para servir cualquier tráfico siquiera. Establece KEYRIGHT_SELF_LICENSE (la misma clave se ejecuta en todos los nodos) y arranca la app. Sin ella, cada petición devuelve 402 por limpia que fuera la restauración de la base de datos.

4. Verifica. Dos comprobaciones confirman una buena restauración:

   • GET /health/ready devuelve 200 —la app está arriba y alcanzó la base de datos restaurada (devuelve 503 mientras Postgres sea inalcanzable).
   • GET /admin/self-license reporta tu edición y una fase activa —la autolicencia prendió y la instancia está sirviendo, no bloqueada.

   Luego haz una prueba de humo de un /v1/validate real contra una licencia conocida para confirmar que la clave de firma restaurada sigue produciendo leases que tus clientes aceptan.

Si los cuatro pasan, estás de vuelta en la ruta de activación con tu estado intacto.

Intégralo en las operaciones

Respalda la base de datos a una cadencia que encaje con tu RPO, guarda la KEK y la clave de firma donde no las pierdas, y ensaya la restauración para que la primera vez que la ejecutes no sea durante un incidente. La guía de operaciones tiene el detalle de copias y actualizaciones, y como Keyright es un solo producto en ambos modos de despliegue, la misma forma de app-sin-estado-más-tu-base-de-datos se mantiene ejecutes uno o tres nodos. Keyright autoalojado se licencia por despliegue entre Standard, Pro y Enterprise —consulta los precios— pero la disciplina de DR es la misma en cada nivel: protege la base de datos, protege los dos secretos y practica recuperar ambos.