Herramientas de línea de comandos

Todos los programas de NGBackup están en /opt/backup/bin/.

Daemons

Programa	Función	Puerto
backup-dir	Director — agenda y orquesta	9101
backup-sd	Storage Daemon — lee/escribe volúmenes	9103
backup-fd	File Daemon — agente en las máquinas protegidas (por flags)	9102

Herramientas del operador

Programa	Para qué sirve	Equivalente Bacula
backup-console	Console interactivo (run/restore/status)	bconsole
backup-cli	Dirigir el Director por scripts	—
backup-copy	Copiar/migrar volúmenes entre pools	bcopy
backup-extract	Extraer archivos directo de un volumen	bextract
backup-ls	Listar el contenido de un volumen	bls
backup-scan	Reconstruir el catálogo desde volúmenes	bscan
backup-dbcheck	Verificar y reparar el catálogo	dbcheck
backup-dirjson · backup-sdjson · backup-fdjson · backup-consjson	Volcar cualquier config a JSON	—

Verbos de la consola

Dentro de backup-console manejas el Director con los mismos verbos que el bconsole de Bacula, y la salida de texto es idéntica byte a byte a Bacula 15.3 — los runbooks y parsers existentes siguen funcionando.

Verbo	Muestra
show <kind>[=name]	Un recurso configurado (Director / Client / Storage / Pool / Catalog / Content / Schedule / Job / Messages). show job=NAME incluye recursivamente los recursos referenciados; show all vuelca todo en el orden del stock. Forma plana Kind: name=value (con la forma de sub-recurso -->), no la sintaxis .conf.
status dir	Estado del Director — encabezado (Jobs: / Crypto: / Heap: / Res:), luego las secciones Scheduled Jobs (N/50) / Running Jobs / Terminated Jobs. status storage=NAME / status client=NAME hacen proxy al SD / FD.
list <kind>	Filas del catálogo como tablas con bordes +---+ (list jobs / clients / pools / volumes / joblog jobid=N / events / fleet). list volumes agrupa por pool. Filtra jobs por nombre único con list ujobid=NAME (un job — el id único JobName.timestamp_NN) o por nombre base con list jobname=NAME (cada ejecución de ese recurso Job); ambos respetan limit=N.
llist jobs	La forma larga / vertical (key: value) de list jobs, con las columnas unidas (clientname, poolname, content, …).
status tenant	Lista los recursos Tenant {} configurados y sus directivas de cuota — maxclients / maxjobs / maxstorages / maxvolbytes / warnvolbytes / isolated / enabled — o No Tenant resources defined. cuando no hay ninguno configurado. También accesible como el ítem 6 del menú interactivo status.
cancel <jobid=N | all>	Cancela un job en ejecución, o todos los jobs en ejecución con cancel all. El cancel solo abre un selector interactivo de jobs en ejecución.
purge <files | jobs | volume=NAME>	Elimina registros del catálogo sin tocar los datos del volumen. purge files jobid=N | job=NAME | client=NAME elimina filas de File; purge jobs client=NAME elimina filas de Job; purge volume=NAME hace purge de un volumen. Destructivo — las filas del catálogo se van, pero los bytes del volumen permanecen hasta sobrescribirse.
delete <jobid=N | client=NAME>	delete client=NAME elimina un cliente y hace cascade a sus filas dependientes del catálogo. delete jobid=N elimina un único registro de job. Solo catálogo; no libera espacio del volumen.

Todo verbo también acepta output=json para un envoltorio legible por máquina (lo que consumen las consolas Web y Desktop). El registro del job (list joblog jobid=N) renderiza el informe de resumen del job en varias líneas de Bacula — Build OS, JobId, Level, Client, FileSet, Pool, Storage, horarios, archivos/bytes escritos, tasa y estado de terminación.

Rastro de auditoría — list events

list events lee la tabla de catálogo Events (solo-anexar) — un registro de auditoría que el Director escribe a medida que se ejecutan jobs y comandos del operador. Las filas vuelven de la más nueva a la más antigua (por defecto limit=100, ajusta con limit=N) en una tabla de siete columnas: code, type, time, daemon, source, ref y text. El Director registra DJ0001 cuando un job recibe un JobId y DJ0002 cuando finaliza, así que un único job deja un par claro de inicio/fin:

*list events
+--------+------+---------------------+------------+--------+------------+--------------------------+
| code   | type | time                | daemon     | source | ref        | text                     |
+--------+------+---------------------+------------+--------+------------+--------------------------+
| DJ0002 | job  | 2026-06-30 18:21:07 | *Director* |        | JobId=1080 | Job 1080 terminated OK   |
| DJ0001 | job  | 2026-06-30 18:20:55 | *Director* |        | JobId=1080 | Job Daily (1080) created |
+--------+------+---------------------+------------+--------+------------+--------------------------+

El texto de terminación incluye el desenlace — terminated OK / with warnings / cancelled / with errors — para que la fila de auditoría muestre el resultado en línea.

output=json devuelve los mismos campos (code / type / time / daemon / source / ref / text) como un envoltorio de lista estable.

Inventario de la flota

El Director mantiene un inventario de versión por daemon (la tabla de catálogo FleetInventory) para que veas de un vistazo qué ejecuta cada FD/SD de la flota:

*version client=NAME      # consulta el FD de un cliente y registra versión + plataforma
*version storage=NAME     # consulta el SD de un Storage
*version all              # consulta todo (y el propio Director)
*list fleet               # el inventario registrado; señala daemons nunca vistos

version sin destino sigue imprimiendo el banner del propio Director. Las consultas usan los canales autenticados normales DIR↔FD/DIR↔SD — sin puertos ni agentes extra — y cada despacho de job también actualiza la fila del cliente automáticamente (como máximo una vez por hora por cliente), de modo que list fleet se mantiene al día en un Director ocupado sin consultas manuales. Ambos verbos aceptan output=json (envoltorio de lista kind: "fleet"). Los daemons Bacula stock no implementan la consulta y se reportan como UNREACHABLE/never seen.

Licenciamiento

Cada build incluye una concesión community firmada (10 objetos / 10 TB, perpetua), así que un Director nuevo queda licenciado sin configuración. El derecho de pago llega de tres formas, resueltas en este orden:

1. LicenseFile = /path/grant.lic en el recurso Director {} — un único archivo de concesión firmado (heredado, aún soportado y prevalece cuando se define).
2. Un recurso License {} con OfflineFile = /path/grant.lic — la vía air-gap; la concesión firmada se lee localmente, sin llamada de red.
3. Un recurso License {} con Serial + ApiUrl — activación en línea: el Director envía (POST) el serial + una huella de la máquina al servidor de licencias, cachea la concesión firmada devuelta y la renueva a diario (el servidor fija la cadencia). Todo fallo de red es fail-open — el daemon conserva la última concesión válida, así que el servidor de licencias inaccesible nunca bloquea los backups.

License {
  Name = Acme
  Serial = "NGB-XXXX-XXXX-XXXX"
  ApiUrl = "https://license.ngbackup.com/"
  # OfflineFile = "/opt/backup/etc/grant.lic"   # alternativa air-gap
}

La raíz de confianza es el token firmado en los tres casos — el Director verifica cada concesión (archivo o en línea) contra la clave pública embebida, así que el servidor de licencias nunca puede conceder más que el firmante offline. Verbos de la consola:

*license                    # edición, uso vs límites, expiración, estado y origen
*license activate           # fuerza activación/renovación en línea inmediata (tras un nuevo serial)

license añade una línea source (community | offline-file | online:<serial-tail>); ambos aceptan output=json.

Validar una config

backup-dir  -t -c /opt/backup/etc/backup-dir.conf
backup-sd   -t -c /opt/backup/etc/backup-sd.conf
backup-fd   -t -c /opt/backup/etc/backup-fd.conf

-t prueba y sale; combínalo con las herramientas *json para alimentar automatización o el Web Console.