Verificación de restauración

Una copia de seguridad que termina sin errores no es lo mismo que una copia que realmente puede restaurar. La única prueba real es restaurarla. Databasus lo hace por usted de forma programada:

toma la última copia de seguridad
ejecuta la restauración en un contenedor de base de datos desechable
compara la base de datos restaurada con la de origen
elimina el contenedor
informa del resultado

¿Qué es un agente de verificación?

El agente de verificación es un pequeño binario en Go que se ejecuta en una máquina que usted controla: sirve cualquier equipo con CPU, RAM y disco libres. El agente se registra en Databasus, recoge trabajos de verificación de una cola, los ejecuta localmente y devuelve los resultados.

Qué necesita

Un host con acceso HTTPS de salida a la URL de su Databasus.
Docker disponible en ese host: el agente crea contenedores de base de datos efímeros con la versión mayor correspondiente para cada trabajo.
Capacidad de disco para cada trabajo de verificación que cubra el tamaño del archivo de la copia, el tamaño bruto de la base de datos y un margen de seguridad adicional.
Al menos 1 núcleo de CPU y 512 MB de RAM disponibles por trabajo concurrente.

¿Por qué no basta con checksums?

Los checksums y los códigos de salida detectan algunos modos de fallo, pero pasan otros completamente por alto:

Los checksums detectan corrupción de bits en el archivo, pero no dicen nada sobre si el volcado en sí está completo o es semánticamente válido.
El código de salida del volcado indica que el comando se ejecutó. No detecta un rol sin permisos de lectura sobre ciertos objetos, una extensión ausente en el origen o una discrepancia de tablespaces, situaciones que pueden hacer que se omitan o recorten objetos en silencio.
La verificación de restauración pasa el archivo por la herramienta de restauración nativa de la base de datos y cuenta las filas de cada tabla. Es la única comprobación que detecta todo lo anterior: si una copia no se puede restaurar, lo descubre antes de necesitarla, no en medio de un desastre.

Configuración

Crear un agente en la interfaz

Abra Settings → Verification agents y haga clic en Create verification agent. Elija un nombre descriptivo como staging-verifier o eu-west-host-1. El siguiente diálogo muestra el token y el ID del agente.

El token se muestra una sola vez: cópielo antes de cerrar el diálogo. Si lo pierde más adelante, use la acción Rotate token en la fila del agente para emitir uno nuevo; el token antiguo deja de funcionar en el siguiente latido del agente. El diálogo posterior muestra los comandos de instalación para la arquitectura de su servidor, los mismos que se describen a continuación.

Lanzar el agente en su servidor

Conéctese por SSH a la máquina que ejecutará las verificaciones. Primero descargue el binario del agente. Sustituya https://your-databasus-host por la URL de su Databasus y cambie amd64 por arm64 si su servidor es ARM:

curl -L -o verification-agent "https://your-databasus-host/api/v1/system/verification-agent?arch=amd64" \
  && chmod +x verification-agent

Después lance el agente. El ID del agente y el token provienen del diálogo del paso anterior:

./verification-agent start \
  --databasus-host=https://your-databasus-host \
  --agent-id=<AGENT_ID> \
  --token=<TOKEN> \
  --max-cpu=2 \
  --max-ram-mb=2048 \
  --max-disk-gb=20 \
  --max-concurrent-jobs=1

start convierte el agente en un daemon y escribe sus flags en databasus-verification.json en el directorio de trabajo, de modo que los siguientes reinicios pueden usar ./verification-agent start sin ningún flag. Los logs se escriben en databasus-verification.log junto al binario.

El host de Databasus debe ser https://. El HTTP plano solo se permite si añade --allow-insecure-http, y está pensado para pruebas locales; nunca exponga un agente de producción sobre HTTP sin cifrar.

Los cuatro flags --max-* son presupuestos, no asignaciones por trabajo. El agente los comunica a Databasus en cada latido, y Databasus los reparte entre los trabajos concurrentes que usted permita. Con --max-cpu=2 --max-ram-mb=2048 --max-concurrent-jobs=1 el único trabajo recibe las 2 CPU y los 2 GB de RAM. Con --max-concurrent-jobs=2, cada trabajo recibe 1 CPU y 1 GB. El mínimo es 1 CPU y 512 MB por trabajo: si su presupuesto no alcanza ese mínimo, el agente anuncia una concurrencia menor. El presupuesto de disco es el más fácil de calcular mal: cada trabajo necesita espacio para el tamaño del archivo de la copia, el tamaño bruto de la base de datos y un margen de seguridad adicional de hasta 5 GB, así que fije --max-disk-gb con holgura por encima de eso para su base de datos más grande.

Gestionar el agente

El mismo binario ofrece cuatro subcomandos:

./verification-agent status — muestra si el daemon está en ejecución y qué trabajos tiene en curso.
./verification-agent stop — detiene el daemon. Las verificaciones en curso se reportan a Databasus como fallidas y vuelven a la cola.
./verification-agent start — relanza el daemon. Los flags se recuerdan desde el primer arranque; pase --token=<NEW> tras una rotación para actualizar el token guardado.
./verification-agent run — se ejecuta en primer plano en lugar de como daemon. Úselo al envolver el agente en una unidad de systemd o un contenedor Docker: esos supervisores esperan que el proceso no haga fork.

La página Settings muestra tres acciones con icono en la fila de cada agente: ver de nuevo los comandos de instalación (sin revelar el token), rotar el token y eliminar el agente. Eliminar es seguro: las verificaciones asignadas a ese agente vuelven a la cola y las recoge otro agente si hay alguno disponible.

Programación y notificaciones

La verificación de restauración se configura por base de datos. Abra la configuración de verificación de la base de datos, active Scheduled verification y elija un intervalo.

Opciones de intervalo

After backup — la garantía más fuerte: cada copia de seguridad correcta se verifica en cuanto termina.
Hourly, daily, weekly, monthly — elija una cadencia y una hora del día.
Cron — una expresión cron en UTC para lo que los preajustes no cubran. Ejemplos: 0 4 * * 0 (cada domingo a las 4:00 UTC) y 0 */6 * * * (cada seis horas).

Cómo maneja la cola "After backup"

Una verificación suele ser más lenta que la copia que la originó, así que si las copias llegan más rápido de lo que terminan las verificaciones, la cola crecería sin límite. Databasus lo evita cancelando cualquier verificación pendiente de la misma base de datos cuando llega una copia nueva: solo la copia más reciente espera en la cola. El compromiso es deliberado: es mejor saltarse la verificación de una copia obsoleta que pasar horas verificando algo desde lo que nunca restauraría.

Ejecuciones manuales

También puede lanzar una verificación puntual desde la pestaña Restore verifications de la base de datos sin cambiar la programación. Es útil para comprobar una copia concreta o probar de extremo a extremo un agente nuevo antes de confiarle la carga programada.

Notificaciones

El éxito y el fallo pueden enviarse por cualquier notificador ya configurado para la base de datos. Las dos casillas, Verification success y Verification failed, son independientes. La mayoría de los equipos activa solo la de fallo para evitar la fatiga de notificaciones. Consulte la documentación de notificadores para configurar Slack, Microsoft Teams, Discord, correo y otros.

Interpretar los resultados

Cada intento de verificación aparece como una fila en la pestaña Restore verifications de la base de datos. El estado es uno de Pending, Running, Successful, Failed o Canceled. Al hacer clic en una fila se abre un panel con la cronología completa, el código de salida de la restauración, el tamaño de la base de datos restaurada, el número de esquemas y tablas, y el desglose del recuento de filas por tabla. Las ejecuciones fallidas muestran el mensaje de error en la parte superior del panel.