Restauración, Instant Recovery y V2V

Las restauraciones de NGBackup van de un solo archivo a una VM completa arrancada en segundos — e incluso en un hipervisor diferente.

Instant Recovery y restauración entre hipervisores

Restaurar archivos (console)

/opt/backup/bin/backup-console
* restore

Elige un método de selección (el más común es “Seleccionar el backup más reciente”), elige el cliente, navega y marca lo que quieras:

cd /etc
mark passwd
mark hosts
done

Confirma el job. Por defecto los archivos van a /tmp/bacula-restores, así nunca sobrescribes los originales — cambia el destino (where=) en el diálogo cuando quieras. Control completo en la referencia del recurso Job (Where, Replace, Restore Client, …).

Restauración granular

Navega el filesystem del guest de una VM en backup (ext2/3/4, NTFS) y extrae archivos o carpetas individuales — sin rehidratar el disco completo. Las cadenas incrementales se consolidan sobre el Full automáticamente.

El motor corre embebido en el Storage Daemon — no hay daemon ni archivo de configuración aparte. El Director resuelve la cadena de volúmenes del job desde su propio catálogo y reenvía los verbos de sesión al Storage Daemon dueño:

* .gr_open jobid=42            # abre una sesión sobre la cadena del job 42
* .gr_ls session=S path=/etc   # lista un directorio del guest
* .gr_stat session=S path=/etc/hostname
* .gr_get session=S path=/etc/hostname   # lectura inline (archivos pequeños)
* .gr_close session=S
* .gr_sessions                 # sesiones activas en el SD

El .gr_open devuelve un state junto con el id de sesión. Para un backup de tamaño normal, la cadena se indexa inline y la respuesta vuelve como ready con la lista de discos.

Los backups grandes abren en segundo plano. Cuando la cadena de volúmenes es grande (más de ~32 GiB), indexarla retendría la conexión de la consola durante todo el recorrido. En su lugar .gr_open devuelve de inmediato con state: "opening" y el escaneo continúa en el Storage Daemon. Consulta el mismo verbo solo con el id de sesión hasta que pase a ready:

* .gr_open jobid=42            → {"session":"S","state":"opening"}
* .gr_open session=S           → {"state":"opening"}      # aún indexando
* .gr_open session=S           → {"state":"ready","disks":[…]}   # lista para navegar

Mientras la sesión está opening, los verbos de navegación (.gr_ls, .gr_stat, .gr_get) devuelven un error stage:"open" (“still opening”) — espera a ready. El .gr_sessions muestra el state de cada sesión. Agrega async=1 a .gr_open para forzar el camino en segundo plano en cualquier backup, sin importar el tamaño.

Dos ajustes gobiernan acceso y capacidad — ambos modificables desde la consola sin reiniciar el daemon:

Política por job: Granular Restore en el Job (config set job=<Nombre> GranularRestore=no rechaza .gr_open para los backups de ese job).
Capacidad y kill-switch del Storage: las directivas Granular / Gr* en el Storage Daemon (config set sd=<Storage> storage=<Nombre> GrMaxSessions=4 aplica en caliente).

Instant Recovery

Arranca una VM en backup directo desde el storage de backup vía NBD, iSCSI, NFS-Datastore o SMB-VHDX — la producción vuelve en segundos mientras el disco migra al storage definitivo en segundo plano (svMotion / qm migrate / virsh blockcopy), sin downtime.

V2V entre hipervisores

Restaura una VM en un hipervisor diferente del que se respaldó — Proxmox, Hyper-V, KVM, vSphere, CloudStack, Nutanix — con conversión automática de formato de disco (qcow2 / raw / vmdk / VHDX) y generación nativa de la config de la VM. Consulta las páginas de cada plugin para los parámetros exactos de restauración.

Archivos bootstrap

Para restauraciones automatizadas o de disaster recovery, NGBackup puede dirigir el Storage Daemon desde un archivo bootstrap que apunta los volúmenes y registros exactos — la ruta de recuperación más rápida posible.