ProxMenux/web/messages/es/docs/backup-restore/restoring.json

{
  "meta": {
    "title": "Restaurar un backup — flujos Completo y Personalizado | ProxMenux",
    "description": "El flujo completo de restauración. Documenta las tres acciones disponibles sobre cualquier backup (ver, descargar, restaurar), la comprobación de compatibilidad y sus resultados, los modos Completo y Personalizado, la clasificación de rutas que decide qué se aplica en vivo y qué espera al siguiente arranque, el dispatcher de arranque y la pasada de reinstalación post-arranque de componentes.",
    "ogTitle": "ProxMenux Backup — restaurar",
    "ogDescription": "Flujos de restauración completo y personalizado con la comprobación de compatibilidad, la clasificación de rutas, el dispatcher post-arranque y la reinstalación de componentes.",
    "twitterTitle": "Restaurar un backup | ProxMenux",
    "twitterDescription": "Cómo se convierte un backup de host de ProxMenux en un host Proxmox operativo."
  },
  "header": {
    "title": "Restaurar un backup",
    "description": "El flujo completo de restauración: desde elegir un backup hasta un host operativo. Documenta la comprobación de compatibilidad, los dos modos de restauración, el dispatcher post-arranque, la pasada de reinstalación de componentes, y los mecanismos que hacen predecibles las restauraciones cross-host y cross-kernel.",
    "section": "Backup & Restore"
  },
  "intro": {
    "title": "La restauración reproduce el origen, no sólo los ficheros",
    "body": "Restaurar un backup de ProxMenux requiere más que extraer archivos. Antes de aplicar cambios, se consulta el manifiesto para detectar diferencias entre origen y destino, se filtran rutas que podrían impedir el arranque y se adapta la configuración del usuario que no puede copiarse literalmente. Tras el reinicio necesario, se intenta reinstalar los componentes compatibles registrados (controlador NVIDIA, Coral TPU y herramientas GPU) para el kernel que ejecuta el destino. Un único backup dirige la comprobación de compatibilidad, la clasificación de rutas y los procesos de arranque y posteriores. Revisa los resultados de cada componente y los logs para confirmar el resultado."
  },
  "threeActions": {
    "heading": "Tres acciones sobre un backup",
    "intro": "Seleccionar un backup de la lista abre un menú con tres acciones.",
    "actionRows": [
      {
        "action": "Ver",
        "detail": "Abre una vista de sólo lectura del archivo: contenido de manifest.json (hostname de origen, versión de PVE, kernel, hardware, componentes instalados), la lista de rutas dentro de <code>rootfs/</code>, y un diff de qué cambiaría en el host actual si se aplicara el backup."
      },
      {
        "action": "Descargar",
        "detail": "Exporta el archivo como un fichero portable <code>.tar.zst</code> (tar comprimido con zstd). Se puede extraer en cualquier sistema Linux con <code>tar --zstd -xf FILE.tar.zst</code>, o desde macOS/Windows con herramientas que soporten zstd (7-Zip, PeaZip, Keka…). El árbol extraído contiene <code>manifest.json</code>, <code>metadata/</code> y <code>rootfs/</code>, exactamente el mismo layout que consume la restauración. Es útil para inspección offline o para restaurar en un host que no tiene acceso al destino original (PBS, Borg)."
      },
      {
        "action": "Restaurar",
        "detail": "La ruta que escribe. Extrae el archivo en un directorio de staging, ejecuta la comprobación de compatibilidad y presenta el selector de modo (Completo o Personalizado)."
      }
    ]
  },
  "compatibilityCheck": {
    "heading": "La comprobación de compatibilidad",
    "intro": "Antes de escribir ningún fichero, <code>hb_compat_check</code> compara el estado descrito en el manifiesto contra el host de destino. La comprobación se ejecuta en sólo lectura y produce cuatro salidas independientes que dirigen el resto de la restauración.",
    "outputRows": [
      {
        "output": "Flag de dirección",
        "detail": "<code>HB_COMPAT_KERNEL_DIRECTION</code> — uno de <code>same</code>, <code>bk_newer</code> o <code>bk_older</code>. Compara la versión mayor del kernel del backup contra la del destino. Dirige el filtro cross-kernel de subconjunto seguro (sólo dispara en <code>bk_older</code>) y la pasada de hidratación documentada en la página cross-kernel."
      },
      {
        "output": "Lista de rutas a saltar",
        "detail": "<code>RS_SKIP_PATHS</code> — cada ruta que la restauración NO debe aplicar. Se pobla por dos mecanismos: drift de hardware (NIC ausente, ID de storage ausente, pool ZFS que no pertenece a este host) y — cuando la dirección es <code>bk_older</code> — la lista cross-kernel de rutas no seguras."
      },
      {
        "output": "Plan de remapeo de NICs",
        "detail": "Cuando una NIC del destino tiene la misma MAC que una del origen pero con nombre distinto (típico tras cambiar la placa base), la comprobación registra un plan de renombrado (<code>HB_NIC_REMAP</code>) que reescribirá <code>/etc/network/interfaces</code> durante la restauración."
      },
      {
        "output": "Plan de rollback",
        "detail": "Lo calcula <code>compute_rollback_plan.sh</code>. Lista las VMs, LXCs y componentes presentes en el destino pero ausentes del backup. La confirmación permite optar por eliminar los invitados adicionales antes del reinicio. Los componentes deben desinstalarse manualmente y la eliminación de invitados puede fallar; no garantiza que el destino coincida exactamente con el backup."
      }
    ],
    "reportBody": "La comprobación también emite un informe estructurado (<code>HB_COMPAT_RESULTS</code>) categorizado como PASS / INFO / WARN / FAIL. Las entradas WARN y FAIL aparecen en el panel previo a la restauración; la restauración se niega a continuar sólo cuando hay un FAIL que el usuario no puede resolver pulsando Continuar."
  },
  "twoModes": {
    "heading": "Restauración Completa vs Personalizada",
    "intro": "Una vez completada la comprobación de compatibilidad, aparece el menú de modo de restauración. La elección determina <em>qué</em> se aplica, no <em>cómo</em> — ambos modos comparten el mismo pipeline subyacente.",
    "modeRows": [
      {
        "mode": "Restauración Completa",
        "detail": "Aplica cada ruta del archivo que sobreviva a los filtros de drift y cross-kernel. También ejecuta la instalación de paquetes y la pasada de reinstalación de componentes. Es la elección por defecto y la recomendada — el objetivo es reproducir el origen, no elegir trozos."
      },
      {
        "mode": "Restauración Personalizada",
        "detail": "Abre un checklist mostrando cada ruta que lleva el archivo. El usuario marca un subconjunto. Las rutas bloqueadas por el filtro cross-kernel aparecen en gris y no pueden seleccionarse. La instalación de paquetes y la reinstalación de componentes se omiten por defecto en modo Personalizado — el usuario está señalando que desea una aplicación parcial, no una reproducción completa."
      }
    ]
  },
  "pathClassification": {
    "heading": "Cómo se clasifican las rutas",
    "intro": "Cada ruta seleccionada para la restauración se clasifica por <code>hb_classify_path</code> en una de tres categorías. La categoría determina el momento en que la ruta se aplica al sistema y por qué.",
    "rows": [
      {
        "class": "hot",
        "detail": "Rutas que se aplican <strong>de inmediato</strong> sobre el sistema en ejecución. El servicio que las consume detecta el cambio por sí mismo o al siguiente reload, sin necesidad de reiniciar. Son la mayoría del contenido de un backup: <code>/etc/ssh</code>, <code>/etc/apt</code>, <code>/etc/cron.*</code>, <code>/root</code>, <code>/usr/local/bin</code>, ficheros de configuración de servicios generales, etc."
      },
      {
        "class": "reboot",
        "detail": "Rutas que este flujo difiere al <strong>siguiente arranque</strong> en lugar de aplicar <strong>de inmediato</strong>. Afectan a la configuración de arranque: la generación del bootloader lee <code>/etc/default/grub</code>, los montajes usan <code>/etc/fstab</code> y la carga de módulos usa <code>/etc/modules</code>. Los archivos pendientes se aplican tras reiniciar y después se regeneran los artefactos de arranque necesarios. Ejemplos: <code>/etc/default/grub</code>, <code>/etc/kernel</code>, <code>/etc/modules</code>, <code>/etc/fstab</code>, <code>/etc/zfs</code>, <code>/etc/initramfs-tools</code>."
      },
      {
        "class": "dangerous",
        "detail": "Rutas que <strong>NO se aplican en el sistema en ejecución</strong> — la escritura viva podría corromper estado o cortar la conexión activa. Estas rutas se preparan en el conjunto pendiente y las escribe el dispatcher post-arranque después del reinicio, cuando el clúster está arriba pero antes de que el sistema esté completamente en uso. Ejemplos: <code>/etc/pve</code> (pmxcfs es un montaje FUSE con configuración activa del clúster), <code>/var/lib/pve-cluster</code> (datos vivos del clúster), <code>/etc/network</code> (podría reconfigurar la misma interfaz por la que el usuario está conectado por SSH y cortar la sesión)."
      }
    ]
  },
  "fullFlow": {
    "heading": "El flujo completo de restauración",
    "intro": "El pipeline completo desde la selección del archivo hasta un host restaurado y operativo. Cada etapa alimenta a la siguiente; el estado escrito por etapas anteriores lo consumen las posteriores.",
    "diagram": "┌─────────────────────────────────────────────────────────────────┐\n│  Archivo → staging_root/                                        │\n│    manifest.json   metadata/   rootfs/                          │\n└──────────────────────────────┬──────────────────────────────────┘\n                               │\n                               ▼\n   ┌─────────────────────────────────────────────────────────┐\n   │  1. hb_compat_check                                     │\n   │     · drift de hardware → RS_SKIP_PATHS                 │\n   │     · dirección kernel → same / bk_newer / bk_older     │\n   │     · plan de remapeo NIC                               │\n   │     · plan de hidratación (sólo bk_older)               │\n   │     · plan de rollback                                  │\n   └──────────────────────────────┬──────────────────────────┘\n                                  │\n                                  ▼\n   ┌─────────────────────────────────────────────────────────┐\n   │  2. Diálogo de confirmación                             │\n   │     Muestra: rutas hot, rutas pending, drift,           │\n   │     hidratación, remapeo NIC, nota cross-kernel,        │\n   │     preview de reinstalaciones                          │\n   └──────────────────────────────┬──────────────────────────┘\n                                  │ (aceptado)\n                                  ▼\n   ┌─────────────────────────────────────────────────────────┐\n   │  3. Aplicar rutas hot → EN VIVO                         │\n   │     _rs_apply rsyncea cada ruta hot                     │\n   │     desde staging_root/rootfs a /                       │\n   │     (salta rutas en RS_SKIP_PATHS)                      │\n   └──────────────────────────────┬──────────────────────────┘\n                                  │\n                                  ▼\n   ┌─────────────────────────────────────────────────────────┐\n   │  4. _rs_prepare_pending_restore                         │\n   │     /var/lib/proxmenux/pending-restore/                 │\n   │       ├── apply-on-boot.list                            │\n   │       ├── plan.env                                      │\n   │       ├── rs-skip-paths.txt                             │\n   │       └── rootfs/ (rutas diferidas)                     │\n   │     Habilita proxmenux-restore-onboot.service           │\n   └──────────────────────────────┬──────────────────────────┘\n                                  │\n                                  ▼\n   ┌─────────────────────────────────────────────────────────┐\n   │  4b. _rs_import_data_pools                              │\n   │      Importa pools ZFS no-raíz cuyos discos             │\n   │      están todos presentes; retry con -f en             │\n   │      foreign hostid; skip con warning si faltan discos. │\n   │      Log: /var/log/proxmenux/restore-datapools-*.log    │\n   └──────────────────────────────┬──────────────────────────┘\n                                  │\n                                  ▼\n   ┌─────────────────────────────────────────────────────────┐\n   │  5. _rs_run_complete_extras                             │\n   │     packages.manual.list                                │\n   │       → filtro cascade-safe                             │\n   │       → apt-get install                                 │\n   └──────────────────────────────┬──────────────────────────┘\n                                  │\n                                  ▼\n   ┌─────────────────────────────────────────────────────────┐\n   │  6. REINICIO                                            │\n   └──────────────────────────────┬──────────────────────────┘\n                                  │\n                                  ▼\n   ┌─────────────────────────────────────────────────────────┐\n   │  7. apply_pending_restore.sh (arranque temprano)        │\n   │     Lee plan.env                                        │\n   │     Aplica apply-on-boot.list (filtrado)                │\n   │     Instala la unit systemd de postboot                 │\n   └──────────────────────────────┬──────────────────────────┘\n                                  │\n                                  ▼\n   ┌─────────────────────────────────────────────────────────┐\n   │  8. apply_cluster_postboot.sh (~10 minutos)             │\n   │     Corre cuando pve-cluster está arriba                │\n   │     · Aplica entradas de /etc/pve a pmxcfs              │\n   │     · update-initramfs -u -k all                        │\n   │     · update-grub / proxmox-boot-tool refresh           │\n   │     · component --auto-reinstall (nvidia, coral, ...)   │\n   │     · Comprobación de sanidad de arranque               │\n   │     · Notificación: \"Host restore finished\"             │\n   └─────────────────────────────────────────────────────────┘"
  },
  "pendingMachinery": {
    "heading": "La maquinaria del pending-restore",
    "intro": "Las rutas clasificadas como <code>reboot</code> o <code>dangerous</code>, y las escrituras de hidratación, se preparan para el siguiente arranque en lugar de aplicarse en vivo. Esto se hace mediante un pequeño conjunto autocontenido de ficheros bajo <code>/var/lib/proxmenux/pending-restore/</code>:",
    "rows": [
      {
        "file": "apply-on-boot.list",
        "content": "Una ruta relativa por línea — el conjunto exacto de rutas que <code>apply_pending_restore.sh</code> aplicará desde el rootfs preparado. Consultar este fichero le dice al usuario exactamente qué cambiará en el siguiente arranque."
      },
      {
        "file": "plan.env",
        "content": "Variables de entorno que sourcea el script de arranque: ID de la restauración, flags de compatibilidad (<code>HB_COMPAT_CROSS_VERSION</code>, <code>HB_COMPAT_KERNEL_DIRECTION</code>, <code>HB_HYDRATION_APPLIED</code>), flag de opt-in de rollback, opciones de clúster."
      },
      {
        "file": "rs-skip-paths.txt",
        "content": "La lista final <code>RS_SKIP_PATHS</code>, persistida para que <code>apply_pending_restore.sh</code> aplique las mismas exclusiones tras el reinicio que las que se calcularon durante el paso interactivo. Evita que las rutas afectadas por drift o inseguras cross-kernel se restauren en el arranque."
      },
      {
        "file": "rootfs/",
        "content": "Los ficheros preparados en sí — los bytes exactos que se colocarán. Se mantienen en el mismo sistema de ficheros que <code>/</code> para que el rsync de arranque sea rápido y no dependa de almacenamiento externo alcanzable en el arranque."
      }
    ],
    "unitBody": "La unit systemd <code>proxmenux-restore-onboot.service</code> se habilita al final del paso interactivo. Es un servicio oneshot que dispara temprano en el siguiente arranque, invoca <code>apply_pending_restore.sh</code>, y después se autodeshabilita. La unit está protegida por la condición <code>ConditionPathExists=/var/lib/proxmenux/pending-restore/state</code>, por lo que en cualquier arranque sin restauración pendiente es un no-op."
  },
  "postbootDispatcher": {
    "heading": "El dispatcher post-arranque — apply_cluster_postboot.sh",
    "intro": "Donde termina el paso interactivo y donde ocurre la reproducción real del host. <code>apply_cluster_postboot.sh</code> se instala como una segunda unit systemd oneshot (<code>proxmenux-apply-cluster-postboot.service</code>) cuyos targets <code>After=</code>/<code>Wants=</code> aseguran que corre sólo después de que pve-cluster y network-online estén arriba. Aquí es donde aterrizan las acciones visibles de la restauración.",
    "tasks": [
      {
        "task": "Aplicar /etc/pve",
        "detail": "<code>/etc/pve</code> es un montaje FUSE de pmxcfs en vivo — no se puede escribir en él en el arranque temprano. El dispatcher copia ficheros desde el rootfs pendiente al <code>/etc/pve</code> vivo una vez el filesystem del clúster está arriba, fichero por fichero, sin reiniciar pve-cluster. La base <code>/var/lib/pve-cluster/config.db</code> del backup (o el <code>config.db.raw-fallback</code> promocionado) se materializa con el patrón <code>systemctl stop pve-cluster</code> → copia atómica del fichero → <code>systemctl start pve-cluster</code>, de modo que pmxcfs relee el estado restaurado al volver a arrancar."
      },
      {
        "task": "Regenerar initramfs y bootloader",
        "detail": "Ejecuta <code>update-initramfs -u -k all</code> en cada kernel instalado, después <code>update-grub</code> (instalaciones GRUB) o <code>proxmox-boot-tool refresh</code> (systemd-boot / ZFS). Se omite si el paso interactivo determinó que nada cambió en las rutas que afectan a estas herramientas."
      },
      {
        "task": "Reinstalación de componentes",
        "detail": "Lee el <code>components_status.json</code> restaurado y recorre los instaladores compatibles registrados (nvidia_driver, coral_driver, amdgpu_top e intel_gpu_tools). Cada uno se ejecuta en modo <code>--auto-reinstall</code>, lee su estado guardado y reinstala para el entorno del destino, recompilando módulos cuando corresponde. Se difiere hasta después del reinicio para utilizar el kernel que ejecute entonces el destino. Los fallos individuales se registran y no detienen el siguiente componente."
      },
      {
        "task": "Comprobación de sanidad del arranque",
        "detail": "Antes de emitir la notificación de finalización, verifica que <code>proxmox-boot-tool status</code> muestra un ESP configurado, que cada <code>/boot/vmlinuz-*</code> tiene su directorio <code>/lib/modules/&lt;ver&gt;</code> correspondiente, y que <code>/vmlinuz</code> resuelve. Cualquier inconsistencia aparece en la notificación en lugar de quedar oculta."
      },
      {
        "task": "Notificación de finalización",
        "detail": "Envía el evento <code>Host restore finished</code> a través de <code>hb_notify_lifecycle</code>. Incluye duración total, cuenta de rutas aplicadas, avisos de la comprobación de sanidad si los hay, y un enlace al log en <code>/var/log/proxmenux/proxmenux-cluster-postboot-*.log</code>. Si no hay notificaciones configuradas, el evento es silencioso — el log sigue registrando todo."
      }
    ]
  },
  "liveProgress": {
    "heading": "Progreso en vivo en la pestaña Backups del Monitor",
    "body": "Tras el reboot, la pestaña Backups del Monitor de ProxMenux muestra una tarjeta de progreso en vivo que refleja el estado de <code>proxmenux-apply-cluster-postboot.service</code> a medida que avanza. La tarjeta lee <code>/var/lib/proxmenux/restore-state.json</code>, que el dispatcher actualiza en cada hito (aplicar configuración del cluster, reconstruir initramfs, actualizar bootloader, reinstalación por componente, verificación de arranque, finalización).",
    "fields": [
      {
        "name": "Insignia de estado",
        "detail": "Una de estas tres: <em>Restauración en curso</em>, <em>Restauración completa</em> o <em>Restauración fallida</em>. Mientras se ejecuta, la tarjeta consulta el fichero de estado cada 2 segundos; una vez terminada, cada 30 segundos."
      },
      {
        "name": "Barra de progreso + contador de pasos",
        "detail": "Muestra <code>N/M steps</code> con la etiqueta del paso actual. Durante la ejecución se calcula un <em>tiempo estimado</em> restante a partir de los pasos completados y el tiempo transcurrido."
      },
      {
        "name": "Lista de componentes",
        "detail": "Una fila por cada driver reinstalado (NVIDIA, Intel GPU tools, AMD tools, Coral TPU) con estado <code>installing</code> / <code>ok</code> / <code>failed</code> y un enlace al log por componente en <code>/var/log/proxmenux/component-*.log</code>."
      },
      {
        "name": "Importación de pools de datos",
        "detail": "Bloque <code>data_pools_import</code> con cinco filas coloreadas — <em>Importados</em>, <em>Forzados</em> (importados con <code>-f</code> por hostid ajeno), <em>Omitidos parcial</em> (pools con solo parte de sus discos presente), <em>Omitidos ausentes</em> (sin ningún disco presente) y <em>Fallidos</em>. El estado se persiste en <code>/var/lib/proxmenux/restore-state.json</code> y el log crudo por ejecución vive en <code>/var/log/proxmenux/restore-datapools-&lt;timestamp&gt;.log</code>."
      },
      {
        "name": "Avisos de arranque",
        "detail": "El dispatcher verifica si falta <code>/lib/modules/&lt;kernel&gt;</code>, si no hay ESP configurada y si hay un symlink <code>/vmlinuz</code> colgado. Cualquier aviso aparece aquí en un banner coloreado."
      },
      {
        "name": "Delta de rollback",
        "detail": "Lista VMs, LXCs y componentes que existen en el destino pero no estaban en el backup restaurado — las mismas entradas que aparecen en el diálogo de rollback destructivo pre-restore. Cada fila incluye el comando de limpieza manual."
      },
      {
        "name": "Tail del log",
        "detail": "Las últimas 600 líneas de <code>proxmenux-cluster-postboot-&lt;ts&gt;.log</code>, con un filtro <em>Issues only</em> que deja solo las líneas con <code>error</code>, <code>warning</code>, <code>failed</code>, <code>✗</code> o <code>traceback</code>."
      }
    ],
    "dismissBody": "Cuando la restauración termina como <em>complete</em> o <em>failed</em>, el botón Dismiss colapsa la tarjeta. El fichero de estado se conserva y el botón History la reabre junto con cualquier restauración anterior (se archivan las últimas 20 en <code>/var/lib/proxmenux/restore-history/</code>).",
    "imageAlt": "Modal Details de progreso post-restauración del Monitor de ProxMenux abierto durante una restauración en curso, con la insignia azul Restore in progress, el paso actual (Rebuilding initramfs), el tiempo estimado restante, la barra de progreso parcialmente llena y el tail del log del postboot en vivo.",
    "imageCaption": "El modal Details mientras el post-boot dispatcher sigue en ejecución — insignia, paso actual, tiempo restante y tail del log en vivo.",
    "detailsImageAlt": "El mismo modal Details una vez terminada la restauración, con la insignia verde Restore complete, la duración total (0m53s), la barra de progreso al 6/6, la sección Rollback delta vacía y el log del postboot archivado.",
    "detailsImageCaption": "El mismo modal una vez finalizada la ejecución — insignia, duración total, barra al 100% y log del postboot archivado."
  },
  "postbootExample": {
    "heading": "Cómo se ve el post-boot en la consola",
    "body": "En la consola física del host, una ejecución del dispatcher que termina correctamente muestra <code>[ OK ] Finished proxmenux-apply-cluster-postboot.service</code>, a menudo junto a los <code>OK</code> de <code>multi-user.target</code> y <code>graphical.target</code>. Esto señala el final del proceso. Puede haber fallos individuales o avisos de arranque registrados; comprueba los estados de componentes y los logs del Monitor antes de dar el host por totalmente restaurado.",
    "imageAlt": "Consola física de Proxmox mostrando el mensaje '[ OK ] Finished proxmenux-apply-cluster-postboot.service - ProxMenux Apply Cluster Configs (post-boot).' seguido del OK de multi-user.target y graphical.target, con el prompt de login del host encima.",
    "imageCaption": "Consola física al terminar el proceso. 'Finished proxmenux-apply-cluster-postboot.service' señala su finalización, que también comunica 'Host restore finished' en el Monitor. Hay que revisar los resultados de componentes y los avisos."
  },
  "tenMinutes": {
    "heading": "Por qué importan los últimos diez minutos",
    "intro": "El reinicio en sí toma segundos, pero el dispatcher post-arranque tarda alrededor de diez minutos en terminar la restauración. Durante esta ventana el host es alcanzable y el login funciona, pero algunos servicios (principalmente los dependientes del driver GPU) todavía no están disponibles. Desglose de tiempos para un host Proxmox típico con NVIDIA + Coral instalados:",
    "rows": [
      {
        "stage": "Arranque + pve-cluster listo",
        "time": "~30 s",
        "detail": "Arranque estándar de Proxmox. SSH, UI web y login están disponibles al final de esta etapa."
      },
      {
        "stage": "Aplicar /etc/pve a pmxcfs",
        "time": "~10 s",
        "detail": "Rápido — ficheros pequeños de config copiados uno a uno al filesystem del clúster vivo."
      },
      {
        "stage": "Regenerar initramfs en cada kernel",
        "time": "3–5 min",
        "detail": "<code>update-initramfs -u -k all</code> reconstruye una imagen de initramfs por cada kernel instalado. El grueso de la espera."
      },
      {
        "stage": "Regenerar config del bootloader",
        "time": "10–30 s",
        "detail": "<code>update-grub</code> o <code>proxmox-boot-tool refresh</code>. Rápido incluso en ZFS."
      },
      {
        "stage": "Reinstalación del driver NVIDIA (si aplica)",
        "time": "5–10 min",
        "detail": "Descarga la versión registrada del driver, compila los módulos DKMS contra el kernel actual, aplica el parche de ProxMenux si el origen lo tenía. La tarea individual más larga."
      },
      {
        "stage": "Reinstalación de otros componentes",
        "time": "3–5 min",
        "detail": "Compilaciones DKMS de Coral, apt install para intel-gpu-tools, descarga + install del .deb para amdgpu_top."
      },
      {
        "stage": "Comprobación de sanidad + notificación",
        "time": "~2 s",
        "detail": "Barata. El usuario se entera de que la ejecución ha terminado en el momento en que dispara la notificación."
      }
    ],
    "outroBody": "Durante este intervalo puede que falten herramientas al iniciar sesión (<code>nvidia-smi</code> no encontrado, <code>coral</code> no detectado) porque la reinstalación sigue en segundo plano. La notificación marca el final del proceso; revisa los resultados de componentes, avisos y logs para distinguir los éxitos de los fallos individuales."
  },
  "destructiveRollback": {
    "heading": "El rollback destructivo opcional",
    "body": "La restauración es aditiva por defecto: se conservan las VMs, LXCs y componentes adicionales del destino. Si hay diferencias, la confirmación ofrece <em>¿Ejecutar el rollback destructivo?</em>, con No por defecto. Aceptar llama a <code>_rs_execute_rollback</code> antes del reinicio para intentar eliminar las VMs y LXCs adicionales indicados. Los componentes se señalan para desinstalación manual porque la automática no está implementada. Los fallos al eliminar invitados se registran y el proceso continúa; no se garantiza una coincidencia exacta con el backup. Revisa nombres y VMID/CTID antes de elegir esta opción destructiva."
  },
  "logs": {
    "heading": "Dónde viven los logs",
    "rows": [
      {
        "log": "/var/log/proxmenux/restore-YYYYMMDD_HHMMSS.log",
        "detail": "Lo escribe el paso interactivo. Contiene: resultados de compatibilidad, filtro de drift, plan de hidratación, salida de aplicación hot, salida de preparación pending, instalación de paquetes."
      },
      {
        "log": "/var/log/proxmenux/apply-pending-YYYYMMDD_HHMMSS.log",
        "detail": "Lo escribe <code>apply_pending_restore.sh</code> en el arranque temprano. Contiene: plan.env sourceado, iteración de apply-on-boot, filtrado por skip-paths."
      },
      {
        "log": "/var/log/proxmenux/proxmenux-cluster-postboot-YYYYMMDD_HHMMSS.log",
        "detail": "Lo escribe <code>apply_cluster_postboot.sh</code>. Contiene: aplicación de pve-cluster, salida de initramfs y bootloader, salida de cada instalador de componentes, comprobación de sanidad, payload de notificación."
      },
      {
        "log": "/var/log/proxmenux/component-<name>-YYYYMMDD_HHMMSS.log",
        "detail": "Un log por instalador de componente (nvidia, coral, etc.) que corrió en la pasada post-arranque. Útil cuando la reinstalación de un componente concreto ha fallado y el usuario necesita la salida de la propia herramienta."
      },
      {
        "log": "/var/log/proxmenux/restore-datapools-YYYYMMDD_HHMMSS.log",
        "detail": "Lo escribe <code>_rs_import_data_pools</code>. Contiene: enumeración de pools no-raíz del manifiesto, resultado por pool (importado limpio, importado con <code>-f</code> por hostid ajeno, omitido por disco faltante, o fallado) y la salida cruda de cada llamada a <code>zpool import</code>."
      }
    ]
  },
  "whereNext": {
    "heading": "A dónde seguir",
    "items": [
      {
        "label": "Restauración cross-kernel",
        "href": "/docs/backup-restore/cross-kernel",
        "tail": " — el filtro direccional de subconjunto seguro y la pasada de hidratación que se invocan cuando el kernel del destino difiere del del backup."
      },
      {
        "label": "Cómo funciona",
        "href": "/docs/backup-restore/how-it-works",
        "tail": " — el layout del archivo, el manifiesto y el inventario de aplicaciones que consume la restauración."
      },
      {
        "label": "Trabajos programados",
        "href": "/docs/backup-restore/scheduled-jobs",
        "tail": " — el flujo desatendido que produce los archivos que consume esta página."
      }
    ]
  }
}