Merge pull request #477 from jcastro/docs/review-backup-restore

docs: review backup and restore documentation in all seven translations

web/messages/es/docs/backup-restore/creating-backups.json

@@ -1,20 +1,20 @@
 {
   "meta": {
-    "title": "Crear copias — flujo interactivo de copia | ProxMenux",
-    "description": "El flujo interactivo de copia en ProxMenux. Dos puntos de entrada (menú TUI de Scripts y UI Web del Monitor), tres destinos, dos modos de perfil, un paso común de staging y un diálogo de confirmación. Documenta la matriz de seis opciones, los perfiles Default y Custom, y qué ve el usuario entre seleccionar una copia y ver el archivo aterrizando en el destino.",
-    "ogTitle": "ProxMenux Backup — crear copias",
-    "ogDescription": "El flujo interactivo de copia con tres destinos, dos perfiles y un paso común de staging.",
-    "twitterTitle": "Crear copias | ProxMenux",
-    "twitterDescription": "Flujo interactivo de copia con tres destinos y dos modos de perfil."
+    "title": "Crear backups — flujo interactivo de backup | ProxMenux",
+    "description": "El flujo interactivo de backup en ProxMenux. Dos puntos de entrada (menú TUI de Scripts y UI Web del Monitor), tres destinos, dos modos de perfil, un paso común de staging y un diálogo de confirmación. Documenta la matriz de seis opciones, los perfiles Default y Custom, y qué ve el usuario entre seleccionar un backup y ver el archivo aterrizando en el destino.",
+    "ogTitle": "ProxMenux Backup — crear backups",
+    "ogDescription": "El flujo interactivo de backup con tres destinos, dos perfiles y un paso común de staging.",
+    "twitterTitle": "Crear backups | ProxMenux",
+    "twitterDescription": "Flujo interactivo de backup con tres destinos y dos modos de perfil."
   },
   "header": {
-    "title": "Crear copias",
-    "description": "El flujo interactivo de copia: elegir un destino y un perfil, revisar el resumen de confirmación, y ver el archivo aterrizando. Dos puntos de entrada comparten el mismo backend y producen archivos idénticos.",
+    "title": "Crear backups",
+    "description": "El flujo interactivo de backup: elegir un destino y un perfil, revisar el resumen de confirmación, y ver el archivo aterrizando. Dos puntos de entrada comparten el mismo backend y producen archivos idénticos.",
     "section": "Backup & Restore"
   },
   "intro": {
     "title": "Dos puntos de entrada, funcionalidad idéntica",
-    "body": "El TUI de Scripts y la UI Web del Monitor exponen <strong>exactamente la misma funcionalidad</strong>. Cada copia — manual o programada — pasa por la misma matriz de elección (tres destinos × dos perfiles) e invoca la misma función backend por celda (<code>_bk_pbs</code>, <code>_bk_borg</code> o <code>_bk_local</code>). Los archivos producidos desde uno u otro punto de entrada son indistinguibles. Cuál usar es una cuestión de preferencia: el TUI es amigable por SSH y admite scripting; el Monitor ofrece click-y-elegir y convive con las vistas de notificaciones y de tail del log."
+    "body": "El TUI de Scripts y la UI Web del Monitor exponen <strong>exactamente la misma funcionalidad</strong>. Cada backup — manual o programado — pasa por la misma matriz de elección (tres destinos × dos perfiles) e invoca la misma función backend por celda (<code>_bk_pbs</code>, <code>_bk_borg</code> o <code>_bk_local</code>). Los archivos producidos desde uno u otro punto de entrada son indistinguibles. Cuál usar es una cuestión de preferencia: el TUI es amigable por SSH y admite scripting; el Monitor ofrece click-y-elegir y convive con las vistas de notificaciones y de tail del log."
   },
   "entryPoints": {
     "heading": "Los dos puntos de entrada",
@@ -32,11 +32,11 @@
     ]
   },
   "modes": {
-    "heading": "Copias manuales vs programadas",
-    "body": "Las copias se pueden producir en dos modos: <strong>manuales</strong> (el flujo interactivo que documenta esta página — el usuario elige un destino y un perfil desde un menú y ve el archivo aterrizando) o <strong>programadas</strong> (un trabajo desatendido que se ejecuta en un timer estilo cron y aplica la retención configurada en el trabajo). Ambos modos soportan los mismos tres destinos y los mismos dos perfiles, y ambos están disponibles desde los dos puntos de entrada — el menú TUI de Scripts y la pestaña Backups del Monitor. Los trabajos programados usan las mismas funciones backend que el flujo manual a través de <code>run_scheduled_backup.sh</code>; los archivos producidos son indistinguibles.",
+    "heading": "Backups manuales vs programados",
+    "body": "Los backups se pueden producir en dos modos: <strong>manuales</strong> (el flujo interactivo que documenta esta página — el usuario elige un destino y un perfil desde un menú y ve el archivo aterrizando) o <strong>programadas</strong> (un trabajo desatendido que se ejecuta en un timer estilo cron y aplica la retención configurada en el trabajo). Ambos modos soportan los mismos tres destinos y los mismos dos perfiles, y ambos están disponibles desde los dos puntos de entrada — el menú TUI de Scripts y la pestaña Backups del Monitor. Los trabajos programados usan las mismas funciones backend que el flujo manual a través de <code>run_scheduled_backup.sh</code>; los archivos producidos son indistinguibles.",
     "seeAlso": "La página de trabajos programados cubre el flujo completo, incluyendo cómo crear un trabajo, adjuntarlo a un timer vzdump de PVE existente, y configurar los valores de retención.",
     "monitorAlt": "Pestaña Backups del Monitor de ProxMenux mostrando el diálogo New scheduled backup con los campos de destino, perfil, horario y retención.",
-    "monitorCaption": "Copia programada — Monitor de ProxMenux. El mismo diálogo estilo asistente que crea una copia manual lleva los campos de horario y retención al final para la ruta desatendida."
+    "monitorCaption": "Backup programado — Monitor de ProxMenux. El mismo diálogo estilo asistente que crea un backup manual lleva los campos de horario y retención al final para la ruta desatendida."
   },
   "matrix": {
     "heading": "La matriz de seis opciones",
@@ -83,13 +83,13 @@
   "profiles": {
     "heading": "Perfil Default vs Custom",
     "defaultTitle": "Perfil Default",
-    "defaultBody": "El perfil por defecto es la lista curada de <code>hb_default_profile_paths</code> (documentada en <em>Cómo funciona</em> bajo <em>Categorías de rutas</em>) más cada entrada del fichero de extras persistentes <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code>. El usuario confirma el destino y las opciones de cifrado y la copia continúa sin más selección de rutas.",
+    "defaultBody": "El perfil por defecto es la lista curada de <code>hb_default_profile_paths</code> (documentada en <em>Cómo funciona</em> bajo <em>Categorías de rutas</em>) más cada entrada del fichero de extras persistentes <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code>. El usuario confirma el destino y las opciones de cifrado y el backup continúa sin más selección de rutas.",
     "customTitle": "Perfil Custom",
-    "customBody": "El perfil Custom abre un checklist mostrando cada ruta del perfil por defecto (sin marcar) y cada extra persistente (premarcado, prefijado con <code>[+]</code>). El usuario marca el conjunto para esa ejecución y puede pulsar <em>Add custom path</em> para añadir una nueva ruta absoluta. Cualquier ruta añadida en línea se persiste en <code>backup-extra-paths.txt</code> para que futuras copias la recojan automáticamente sin volver a añadirla. Quitar la marca a un extra persistente lo desmarca para esa ejecución pero no lo elimina del fichero — la eliminación es una acción <em>Manage custom paths</em> separada, fuera del flujo de copia.",
+    "customBody": "El perfil Custom abre un checklist mostrando cada ruta del perfil por defecto (sin marcar) y cada extra persistente (premarcado, prefijado con <code>[+]</code>). El usuario marca el conjunto para esa ejecución y puede pulsar <em>Add custom path</em> para añadir una nueva ruta absoluta. Cualquier ruta añadida en línea se persiste en <code>backup-extra-paths.txt</code> para que futuros backups la recojan automáticamente sin volver a añadirla. Quitar la marca a un extra persistente lo desmarca para esa ejecución pero no lo elimina del fichero — la eliminación es una acción <em>Manage custom paths</em> separada, fuera del flujo de backup.",
     "customPickerAlt": "Checklist del perfil Custom mostrando las rutas del perfil por defecto (sin marcar) y los extras persistentes (premarcados con prefijo [+]), más botones para añadir una ruta nueva o confirmar la selección.",
     "customPickerCaption": "Perfil Custom — el path picker. Las rutas del perfil por defecto aparecen sin marcar; los extras persistentes aparecen premarcados con prefijo [+]. El usuario marca el conjunto para esa ejecución.",
     "manageCustomAlt": "Menú Manage custom paths mostrando la lista de extras persistentes y opciones para añadirlos, eliminarlos o editarlos.",
-    "manageCustomCaption": "Manage custom paths — el punto de entrada donde se añaden o eliminan los extras persistentes. Cada ruta listada aquí se incluye automáticamente en las copias en modo Default sin necesidad de abrir el picker Custom."
+    "manageCustomCaption": "Manage custom paths — el punto de entrada donde se añaden o eliminan los extras persistentes. Cada ruta listada aquí se incluye automáticamente en los backups en modo Default sin necesidad de abrir el picker Custom."
   },
   "commonPipeline": {
     "heading": "Qué se ejecuta con independencia del destino",
@@ -98,7 +98,7 @@
       {
         "step": "1",
         "name": "Ensamblado del rootfs",
-        "detail": "Ejecuta <code>rsync -a</code> por cada ruta seleccionada hacia <code>staging_root/rootfs/</code>. La base pmxcfs en <code>/var/lib/pve-cluster/config.db</code> se captura aparte con <code>sqlite3 .backup</code> para obtener un snapshot consistente sin parar el clúster, y los sidecars <code>.db-wal</code> / <code>.db-shm</code> se excluyen del rsync; si <code>sqlite3</code> no está disponible, se deposita un <code>config.db.raw-fallback</code> que la restauración promociona al importar. Excluye subrutas volátiles (historial de bash, cachés, papelera) de <code>/root/</code>. Las rutas ausentes en el origen se registran en <code>metadata/missing_paths.txt</code> sin detener la copia."
+        "detail": "Ejecuta <code>rsync -a</code> por cada ruta seleccionada hacia <code>staging_root/rootfs/</code>. La base pmxcfs en <code>/var/lib/pve-cluster/config.db</code> se captura aparte con <code>sqlite3 .backup</code> para obtener un snapshot consistente sin parar el clúster, y los sidecars <code>.db-wal</code> / <code>.db-shm</code> se excluyen del rsync; si <code>sqlite3</code> no está disponible, se deposita un <code>config.db.raw-fallback</code> que la restauración promociona al importar. Excluye subrutas volátiles (historial de bash, cachés, papelera) de <code>/root/</code>. Las rutas ausentes en el origen se registran en <code>metadata/missing_paths.txt</code> sin detener el backup."
       },
       {
         "step": "2",
@@ -113,7 +113,7 @@
       {
         "step": "4",
         "name": "Info de la ejecución",
-        "detail": "<code>metadata/run_info.env</code> registra la identidad de la ejecución de copia — hostname, timestamp, versión del kernel — usada por el chequeo de compatibilidad de la restauración para determinar la dirección cross-kernel."
+        "detail": "<code>metadata/run_info.env</code> registra la identidad de la ejecución de backup — hostname, timestamp, versión del kernel — usada por el chequeo de compatibilidad de la restauración para determinar la dirección cross-kernel."
       },
       {
         "step": "5",
@@ -150,9 +150,9 @@
       "<code>ProxMenux-Monitor.AppImage*</code>, <code>install_proxmenux*.sh</code>"
     ],
     "notInProfileTitle": "Rutas fuera del perfil",
-    "notInProfileBody": "Todo lo que no esté listado en <code>hb_default_profile_paths</code> y no se haya añadido como ruta custom o extra persistente no forma parte de la copia. Ejemplos notables:",
+    "notInProfileBody": "Todo lo que no esté listado en <code>hb_default_profile_paths</code> y no se haya añadido como ruta custom o extra persistente no forma parte del backup. Ejemplos notables:",
     "notInProfileItems": [
-      "<strong>Discos de VMs y LXCs</strong> — los gestiona <code>vzdump</code>, no esta funcionalidad. Los ficheros de configuración de los invitados bajo <code>/etc/pve/nodes/*/qemu-server/*.conf</code> y <code>lxc/*.conf</code> sí se capturan (viven bajo <code>/etc/pve</code>) para que la restauración reproduzca el inventario; los discos se re-adjuntan desde una copia existente de vzdump/PBS.",
+      "<strong>Discos de VMs y LXCs</strong> — los gestiona <code>vzdump</code>, no esta funcionalidad. Los ficheros de configuración de los invitados bajo <code>/etc/pve/nodes/*/qemu-server/*.conf</code> y <code>lxc/*.conf</code> sí se capturan (viven bajo <code>/etc/pve</code>) para que la restauración reproduzca el inventario; los discos se re-adjuntan desde un backup existente de vzdump/PBS.",
       "<strong><code>/boot</code> y <code>/boot/efi</code></strong> — los binarios del kernel, el initramfs y la partición ESP UEFI los regenera el propio destino con <code>update-initramfs</code>, <code>update-grub</code> o <code>proxmox-boot-tool refresh</code> tras la restauración. El bootloader nunca se copia verbatim.",
       "<strong>Filesystems runtime del kernel y sistema</strong> — <code>/proc</code>, <code>/sys</code>, <code>/dev</code> y <code>/run</code> son pseudo-filesystems que produce el kernel y udev; no se persisten en ningún sitio.",
       "<strong>Binarios de paquetes bajo <code>/usr/bin</code>, <code>/usr/lib</code>, <code>/lib</code>, <code>/sbin</code></strong> — los reinstala el APT del destino a partir de <code>packages.manual.list</code>.",
@@ -160,7 +160,7 @@
       "<strong><code>/home/USER</code></strong> — no está en el perfil por defecto. Añadirlo como ruta custom cuando un sistema tenga directorios home de usuario que deban sobrevivir a una restauración."
     ],
     "customPathsTitle": "Cómo se tratan las rutas custom",
-    "customPathsBody": "Una ruta custom añadida en línea en modo Custom o persistida en <code>backup-extra-paths.txt</code> pasa por el mismo pipeline de <code>rsync</code> que las rutas del perfil por defecto. Se aplican las exclusiones globales. Si la ruta custom está bajo <code>/root/</code> o <code>/usr/local/share/proxmenux/</code>, siguen aplicando las exclusiones específicas de arriba. Cada ruta archivada — default o custom — queda registrada en <code>metadata/paths_archived.txt</code>. Las rutas que no existen en el origen se registran en <code>metadata/missing_paths.txt</code> sin detener la copia."
+    "customPathsBody": "Una ruta custom añadida en línea en modo Custom o persistida en <code>backup-extra-paths.txt</code> pasa por el mismo pipeline de <code>rsync</code> que las rutas del perfil por defecto. Se aplican las exclusiones globales. Si la ruta custom está bajo <code>/root/</code> o <code>/usr/local/share/proxmenux/</code>, siguen aplicando las exclusiones específicas de arriba. Cada ruta archivada — default o custom — queda registrada en <code>metadata/paths_archived.txt</code>. Las rutas que no existen en el origen se registran en <code>metadata/missing_paths.txt</code> sin detener el backup."
   },
   "archiveStructure": {
     "heading": "Estructura del archivo",
@@ -169,7 +169,7 @@
   },
   "confirmation": {
     "heading": "Resumen de confirmación",
-    "body": "Antes de que el backend escriba nada en el destino, ProxMenux muestra un diálogo resumen con el destino, el backup ID o nombre del archivo, el estado del cifrado y la lista de rutas que se copian. Cancelar aquí aborta la copia limpiamente — el directorio de staging se elimina por el hook <code>trap</code> definido en la función backend y ningún dato parcial llega al destino."
+    "body": "Antes de que el backend escriba nada en el destino, ProxMenux muestra un diálogo resumen con el destino, el backup ID o nombre del archivo, el estado del cifrado y la lista de rutas que se copian. Cancelar aquí aborta el backup limpiamente — el directorio de staging se elimina por el hook <code>trap</code> definido en la función backend y ningún dato parcial llega al destino."
   },
   "writing": {
     "heading": "Escritura en el destino",
@@ -181,7 +181,7 @@
       },
       {
         "topic": "Sidecar (sólo local)",
-        "detail": "<code>hb_write_archive_sidecar</code> deposita un <code>*.proxmenux.json</code> junto al archivo local para que el Monitor lo identifique como copia de host de ProxMenux incluso tras movimientos o renombrados."
+        "detail": "<code>hb_write_archive_sidecar</code> deposita un <code>*.proxmenux.json</code> junto al archivo local para que el Monitor lo identifique como backup de host de ProxMenux incluso tras movimientos o renombrados."
       },
       {
         "topic": "Notificación (complete/fail)",
@@ -190,12 +190,12 @@
     ]
   },
   "finishedScreens": {
-    "heading": "Cómo se ve una copia finalizada",
+    "heading": "Cómo se ve un backup finalizado",
     "intro": "El mismo evento de finalización lo exponen los dos puntos de entrada. El TUI escribe un bloque resumen en el terminal; la pestaña Backups del Monitor muestra la ejecución en la lista de archivos con badges de tamaño, duración y estado.",
-    "scriptsAlt": "TUI de ProxMenux Scripts mostrando una copia de host finalizada — destino, backup ID, ruta del snapshot, tamaño de datos, duración y estado de cifrado.",
-    "scriptsCaption": "Copia finalizada — ProxMenux Scripts (TUI). El bloque de finalización imprime el destino, backup ID, nombre del snapshot o archivo resultante, tamaño de datos, duración y estado de cifrado.",
-    "monitorAlt": "Pestaña Backups del Monitor de ProxMenux mostrando una entrada de copia de host finalizada con tamaño, duración, badge del método y indicador de cifrado.",
-    "monitorCaption": "Copia finalizada — pestaña Backups del Monitor de ProxMenux. La nueva copia aparece en la lista de archivos con el badge del método del destino, tamaño, duración y — cuando aplica — el indicador de cifrado."
+    "scriptsAlt": "TUI de ProxMenux Scripts mostrando un backup de host finalizado — destino, backup ID, ruta del snapshot, tamaño de datos, duración y estado de cifrado.",
+    "scriptsCaption": "Backup finalizado — ProxMenux Scripts (TUI). El bloque de finalización imprime el destino, backup ID, nombre del snapshot o archivo resultante, tamaño de datos, duración y estado de cifrado.",
+    "monitorAlt": "Pestaña Backups del Monitor de ProxMenux mostrando una entrada de backup de host finalizado con tamaño, duración, badge del método y indicador de cifrado.",
+    "monitorCaption": "Backup finalizado — pestaña Backups del Monitor de ProxMenux. El nuevo backup aparece en la lista de archivos con el badge del método del destino, tamaño, duración y — cuando aplica — el indicador de cifrado."
   },
   "whereNext": {
     "heading": "A dónde seguir",
@@ -208,7 +208,7 @@
       {
         "label": "Trabajos programados",
         "href": "/docs/backup-restore/scheduled-jobs",
-        "tail": " — ejecutar la misma copia desatendida en un horario en lugar de interactivamente."
+        "tail": " — ejecutar el mismo backup desatendido en un horario en lugar de interactivamente."
       },
       {
         "label": "Restauración",

web/messages/es/docs/backup-restore/cross-kernel.json

@@ -1,55 +1,102 @@
 {
   "meta": {
     "title": "Restauración cross-kernel — detección de dirección, filtro de subconjunto seguro, hidratación | ProxMenux",
-    "description": "Cómo restaura ProxMenux una copia de host sobre un destino con un kernel de versión mayor distinta. Documenta cómo se detecta la dirección del salto, el filtro de subconjunto seguro que salta rutas críticas del arranque cuando el destino corre un kernel más reciente que la copia, y la hidratación independiente del kernel de cuatro fases que reaplica la configuración del usuario como IOMMU, IDs VFIO y tokens custom del cmdline sin copiar verbatim los ficheros ligados al kernel.",
+    "description": "Cómo restaura ProxMenux un backup de host sobre un destino con un kernel de versión mayor distinta. Documenta cómo se detecta la dirección del salto, el filtro de subconjunto seguro que salta rutas críticas del arranque cuando el destino corre un kernel más reciente que el backup, y la hidratación independiente del kernel de cuatro fases que reaplica la configuración del usuario como IOMMU, IDs VFIO y tokens custom del cmdline sin copiar verbatim los ficheros ligados al kernel.",
     "ogTitle": "ProxMenux Backup — restauración cross-kernel e hidratación",
     "ogDescription": "Restauración cross-kernel direccional con filtro de subconjunto seguro e hidratación independiente del kernel.",
     "twitterTitle": "Restauración cross-kernel | ProxMenux",
-    "twitterDescription": "Cómo maneja ProxMenux una restauración cuando el kernel del destino difiere del de la copia."
+    "twitterDescription": "Cómo maneja ProxMenux una restauración cuando el kernel del destino difiere del del backup."
   },
   "header": {
     "title": "Restauración cross-kernel",
-    "description": "Cómo maneja ProxMenux una restauración cuando el kernel del host de destino es distinto al kernel que había en el momento de la copia — especialmente cuando el destino ejecuta un kernel más reciente. Documenta cómo se detecta la diferencia, cómo se filtran las rutas críticas del arranque que podrían romper el destino, y cómo se reaplica la configuración propia del usuario sin copiar verbatim los ficheros ligados al kernel.",
+    "description": "Cómo maneja ProxMenux una restauración cuando el kernel del host de destino es distinto al kernel que había en el momento del backup — especialmente cuando el destino ejecuta un kernel más reciente. Documenta cómo se detecta la diferencia, cómo se filtran las rutas críticas del arranque que podrían romper el destino, y cómo se reaplica la configuración propia del usuario sin copiar verbatim los ficheros ligados al kernel.",
     "section": "Backup & Restore"
   },
   "intro": {
     "title": "Cada salto de kernel se maneja de forma distinta",
-    "body": "El kernel de un host Proxmox se identifica mediante una versión como <code>6.17.13-2-pve</code>. Los dos primeros números (<strong>6.17</strong> en este ejemplo) definen la versión principal: cuando cambian, algunos archivos de configuración del kernel anterior podrían no ser válidos para el nuevo. Si la restauración detecta versiones principales distintas en la copia y en el destino, el proceso toma un camino u otro según la dirección del salto: si el kernel de la copia es anterior o posterior al del destino. Los dos casos presentan riesgos opuestos. Las copias con un kernel más reciente que el del destino se restauran tal cual, sin problemas según las pruebas realizadas con varios saltos de kernel. Las copias con un kernel anterior al del destino necesitan un filtro para evitar que una configuración del kernel antiguo impida arrancar el sistema de destino."
+    "body": "El kernel de un host Proxmox se identifica con una cadena de versión como <code>6.17.13-2-pve</code>. Los dos primeros números (<strong>6.17</strong> en este ejemplo) definen la versión mayor: cuando cambian, algunos ficheros de configuración escritos para el kernel anterior pueden no ser válidos en el nuevo. Cuando la restauración detecta que el backup y el destino tienen versiones mayores de kernel distintas, el flujo se ramifica según la dirección del salto —si el backup es más antiguo o más reciente que el destino— porque los dos casos tienen modos de fallo opuestos. Los backups más recientes que el destino se restauran limpiamente tal cual (verificado en banco de pruebas con varios saltos de kernel). Los backups más antiguos que el destino necesitan un filtro para no romper el arranque del destino con configuración escrita para un kernel que desde entonces ha cambiado."
   },
   "directionCheck": {
     "heading": "La comprobación de dirección",
-    "intro": "Durante la comprobación de compatibilidad, <code>hb_compat_check</code> compara el kernel registrado en el manifiesto de la copia contra el kernel actual del destino (<code>uname -r</code>) y clasifica la restauración en uno de tres casos, guardado en la variable interna <code>HB_COMPAT_KERNEL_DIRECTION</code>:",
+    "intro": "Durante la comprobación de compatibilidad, <code>hb_compat_check</code> compara el kernel registrado en el manifiesto del backup contra el kernel actual del destino (<code>uname -r</code>) y clasifica la restauración en uno de tres casos, guardado en la variable interna <code>HB_COMPAT_KERNEL_DIRECTION</code>:",
     "rows": [
-      { "direction": "same", "condition": "La versión mayor del kernel coincide entre la copia y el destino.", "behavior": "El flujo de restauración completo corre sin cambios. Sin filtro adicional, sin hidratación, sin aviso especial en la interfaz." },
-      { "direction": "bk_newer", "condition": "El kernel de la copia es más RECIENTE que el del destino (por ejemplo: la copia se hizo con kernel 7.0 y el destino corre kernel 6.17).", "behavior": "El flujo de restauración completo corre sin cambios, exactamente igual que en <code>same</code>. No se aplica ningún filtro. Verificado empíricamente: los controladores se reinstalan contra el kernel del destino, la configuración IOMMU se aplica limpia, las VMs con passthrough GPU arrancan sin problemas." },
-      { "direction": "bk_older", "condition": "El kernel de la copia es más ANTIGUO que el del destino (por ejemplo: la copia se hizo con kernel 6.17 y el destino corre kernel 7.0).", "behavior": "Se activan el filtro de subconjunto seguro y la hidratación de cuatro fases descritos más abajo. La restauración procede — el destino reproduce el origen, pero los ficheros críticos del arranque no se copian verbatim." }
+      {
+        "direction": "same",
+        "condition": "La versión mayor del kernel coincide entre el backup y el destino.",
+        "behavior": "El flujo de restauración completo corre sin cambios. Sin filtro adicional, sin hidratación, sin aviso especial en la interfaz."
+      },
+      {
+        "direction": "bk_newer",
+        "condition": "El kernel del backup es más RECIENTE que el del destino (por ejemplo: el backup se hizo con kernel 7.0 y el destino corre kernel 6.17).",
+        "behavior": "El flujo de restauración completo corre sin cambios, exactamente igual que en <code>same</code>. No se aplica ningún filtro. Verificado empíricamente: los controladores se reinstalan contra el kernel del destino, la configuración IOMMU se aplica limpia, las VMs con passthrough GPU arrancan sin problemas."
+      },
+      {
+        "direction": "bk_older",
+        "condition": "El kernel del backup es más ANTIGUO que el del destino (por ejemplo: el backup se hizo con kernel 6.17 y el destino corre kernel 7.0).",
+        "behavior": "Se activan el filtro de subconjunto seguro y la hidratación de cuatro fases descritos más abajo. La restauración procede — el destino reproduce el origen, pero los ficheros críticos del arranque no se copian verbatim."
+      }
     ]
   },
   "whyBkNewerIsSafe": {
-    "heading": "Por qué una copia con kernel más reciente que el destino se restaura sin cambios",
-    "body": "Cuando la restauración corre contra un destino con un kernel <em>más antiguo</em> que el registrado en la copia, todos los mecanismos de los que depende la restauración son independientes de la versión del kernel. Los instaladores de controladores de GPU y otros dispositivos PCI detectan el kernel en ejecución con <code>uname -r</code> y compilan DKMS contra lo que tenga el destino. La instalación de paquetes por APT trae binarios construidos para la distribución del destino. Los tokens IOMMU del cmdline como <code>intel_iommu=on</code> son estables entre versiones mayores de kernel. La copia lleva rutas escritas bajo un kernel más reciente, pero esas rutas (blacklists de módulos, defaults de GRUB, configuración de initramfs) siguen siendo sintaxis válida en el más antiguo — los kernels ignoran los tokens que no reconocen en lugar de fallar. Este caso es equivalente en la práctica a una restauración con el mismo kernel, y ProxMenux lo trata como tal."
+    "heading": "Por qué un backup con kernel más reciente que el destino se restaura sin cambios",
+    "body": "Cuando la restauración corre contra un destino con un kernel <em>más antiguo</em> que el registrado en el backup, todos los mecanismos de los que depende la restauración son independientes de la versión del kernel. Los instaladores de controladores de GPU y otros dispositivos PCI detectan el kernel en ejecución con <code>uname -r</code> y compilan DKMS contra lo que tenga el destino. La instalación de paquetes por APT trae binarios construidos para la distribución del destino. Los tokens IOMMU del cmdline como <code>intel_iommu=on</code> son estables entre versiones mayores de kernel. El backup lleva rutas escritas bajo un kernel más reciente, pero esas rutas (blacklists de módulos, defaults de GRUB, configuración de initramfs) siguen siendo sintaxis válida en el más antiguo — los kernels ignoran los tokens que no reconocen en lugar de fallar. Este caso es equivalente en la práctica a una restauración con el mismo kernel, y ProxMenux lo trata como tal."
   },
   "safeSubsetFilter": {
     "heading": "El filtro de subconjunto seguro (sólo cuando el kernel del destino es más reciente)",
-    "intro": "Cuando el kernel del destino es más reciente que el de la copia, la comprobación de compatibilidad añade 16 rutas críticas del arranque de <code>hb_unsafe_paths_cross_version</code> a <code>RS_SKIP_PATHS</code>. Estas rutas se excluyen de la restauración porque escribir una versión suya de un kernel más antiguo sobre un destino que corre uno más reciente ha causado kernel panics en pruebas de banco. Las rutas cubren cuatro categorías:",
+    "intro": "Cuando el kernel del destino es más reciente que el del backup, la comprobación de compatibilidad añade 16 rutas críticas del arranque de <code>hb_unsafe_paths_cross_version</code> a <code>RS_SKIP_PATHS</code>. Estas rutas se excluyen de la restauración porque escribir una versión suya de un kernel más antiguo sobre un destino que corre uno más reciente ha causado kernel panics en pruebas de banco. Las rutas cubren cinco categorías:",
     "categoryRows": [
-      { "category": "Bootloader", "paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>", "reason": "Defaults de GRUB atados al orden previo de kernels, y estado de proxmox-boot-tool (cmdline, UUIDs de ESP, hooks) que referencia rutas e identificadores de la instalación más antigua." },
-      { "category": "Módulos del kernel y artefactos de arranque", "paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>", "reason": "Listas de autocarga que pueden referenciar módulos renombrados entre majors del kernel, opciones de módulo que pueden no aplicar, hooks de initramfs escritos para el kernel más antiguo." },
-      { "category": "Stack de almacenamiento e identidad de filesystem", "paths": "<code>/etc/fstab</code>, <code>/etc/multipath</code>, <code>/etc/iscsi</code>, <code>/etc/udev/rules.d</code>, <code>/etc/zfs</code>", "reason": "UUIDs que pueden no existir en esta instalación, drivers de multipath que cambian entre kernels, parámetros iSCSI que evolucionan, reglas udev que pueden atarse a subsistemas inexistentes, estado ZFS (<code>zpool.cache</code> + <code>hostid</code>) que puede bloquear el pool como si no perteneciera al host." },
-      { "category": "Fuentes APT", "paths": "<code>/etc/apt</code>", "reason": "Las suites de fuentes APT pueden disparar un downgrade de paquetes críticos en la próxima actualización." },
-      { "category": "systemd", "paths": "<code>/etc/systemd/system</code>, <code>/etc/systemd/journald.conf</code>, <code>/etc/systemd/logind.conf</code>, <code>/etc/systemd/system.conf</code>, <code>/etc/systemd/user.conf</code>", "reason": "Overrides de unit y .wants ligados al major de systemd más antiguo; claves de configuración que pueden no parsearse en un systemd más reciente." }
+      {
+        "category": "Bootloader",
+        "paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
+        "reason": "Defaults de GRUB atados al orden previo de kernels, y estado de proxmox-boot-tool (cmdline, UUIDs de ESP, hooks) que referencia rutas e identificadores de la instalación más antigua."
+      },
+      {
+        "category": "Módulos del kernel y artefactos de arranque",
+        "paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
+        "reason": "Listas de autocarga que pueden referenciar módulos renombrados entre majors del kernel, opciones de módulo que pueden no aplicar, hooks de initramfs escritos para el kernel más antiguo."
+      },
+      {
+        "category": "Stack de almacenamiento e identidad de filesystem",
+        "paths": "<code>/etc/fstab</code>, <code>/etc/multipath</code>, <code>/etc/iscsi</code>, <code>/etc/udev/rules.d</code>, <code>/etc/zfs</code>",
+        "reason": "UUIDs que pueden no existir en esta instalación, drivers de multipath que cambian entre kernels, parámetros iSCSI que evolucionan, reglas udev que pueden atarse a subsistemas inexistentes, estado ZFS (<code>zpool.cache</code> + <code>hostid</code>) que puede bloquear el pool como si no perteneciera al host."
+      },
+      {
+        "category": "Fuentes APT",
+        "paths": "<code>/etc/apt</code>",
+        "reason": "Las suites de fuentes APT pueden disparar un downgrade de paquetes críticos en la próxima actualización."
+      },
+      {
+        "category": "systemd",
+        "paths": "<code>/etc/systemd/system</code>, <code>/etc/systemd/journald.conf</code>, <code>/etc/systemd/logind.conf</code>, <code>/etc/systemd/system.conf</code>, <code>/etc/systemd/user.conf</code>",
+        "reason": "Overrides de unit y .wants ligados al major de systemd más antiguo; claves de configuración que pueden no parsearse en un systemd más reciente."
+      }
     ],
-    "outroBody": "El filtro corre ANTES del diálogo de confirmación para que el usuario vea la lista exacta de rutas que se saltarán, categorizadas por motivo. La restauración procede igualmente — todo lo demás (VMs, LXCs, red, /etc/pve, usuarios, cron, estado de ProxMenux, paquetes, drivers, /root) se restaura con normalidad."
+    "outroBody": "El filtro corre ANTES del diálogo de confirmación para que el usuario vea la lista exacta de rutas que se saltarán, categorizadas por motivo. La restauración procede igualmente — todo lo demás (configuración de VM/LXC, red, /etc/pve, usuarios, cron, estado de ProxMenux, paquetes, drivers, /root) se restaura con normalidad."
   },
   "hydration": {
     "heading": "Hidratación independiente del kernel",
-    "intro": "El filtro de subconjunto seguro por sí solo dejaría al destino sin la configuración que el usuario había puesto dentro de esos ficheros críticos del arranque: cmdline IOMMU para passthrough GPU, IDs de dispositivo VFIO, <code>GRUB_TIMEOUT</code> custom, blacklists de nvidia. La pasada de hidratación reaplica esas piezas de forma independiente de la versión del kernel. Corren cuatro fases cuando el kernel del destino es más reciente que el de la copia, cada una aditiva (nunca sobrescribe un valor que el destino ya lleva) e idempotente (correr dos veces es un no-op).",
+    "intro": "El filtro omite archivos críticos del arranque; la hidratación reaplica ajustes seleccionados: cmdline IOMMU, IDs VFIO, <code>GRUB_TIMEOUT</code> personalizado y listas de bloqueo nvidia. Se ejecuta con un kernel destino más reciente. La fusión de cmdline conserva las claves del destino y añade módulos que faltan. Los valores GRUB y archivos permitidos pueden reemplazar contenido distinto del destino. Repetir la misma entrada es idempotente.",
     "phaseRows": [
-      { "phase": "1a — Ruta GRUB", "detail": "Para hosts que usan GRUB (instalaciones ext4/lvm). <code>_rs_hyd_grub</code> mergea cada token de <code>manifest.kernel_params.cmdline_extra</code> de la copia en el <code>GRUB_CMDLINE_LINUX_DEFAULT</code> vivo del destino, saltando los tokens cuya clave el destino ya lleva. Después mergea claves whitelisted <code>GRUB_*</code> (<code>GRUB_TIMEOUT</code>, <code>GRUB_TIMEOUT_STYLE</code>, <code>GRUB_DEFAULT</code>, <code>GRUB_TERMINAL</code>, <code>GRUB_DISABLE_OS_PROBER</code>, <code>GRUB_SERIAL_COMMAND</code>, <code>GRUB_GFXMODE</code>, <code>GRUB_GFXPAYLOAD_LINUX</code>) del <code>/etc/default/grub</code> de la copia si difieren de las del destino." },
-      { "phase": "1b — Ruta systemd-boot / ZFS", "detail": "Para hosts que usan systemd-boot (típicamente ZFS-on-root). <code>_rs_hyd_kernel_cmdline</code> mergea los tokens del usuario de <code>cmdline_extra</code> en el <code>/etc/kernel/cmdline</code> del destino, manteniendo intacto el boilerplate propio del destino: <code>root=</code>, <code>boot=</code> y <code>rootflags=</code>." },
-      { "phase": "2 — Merge en /etc/modules", "detail": "<code>_rs_hyd_modules</code> añade los módulos de <code>manifest.kernel_params.modules_loaded_at_boot</code> que estén en la whitelist (<code>vfio</code>, <code>vfio_pci</code>, <code>vfio_iommu_type1</code>, <code>vfio_virqfd</code>, <code>kvm</code>, <code>kvm_intel</code>, <code>kvm_amd</code>, <code>nvidia</code>, <code>nvidia_drm</code>, <code>nvidia_modeset</code>, <code>nvidia_uvm</code>, <code>i915</code>, <code>xe</code>) Y que aún no estén presentes en <code>/etc/modules</code> del destino." },
-      { "phase": "3 — Copia de ficheros whitelisted", "detail": "<code>_rs_hyd_files</code> copia ficheros escritos por el usuario del staging rootfs al destino en vivo cuando el contenido difiere. La whitelist cubre ficheros VFIO/nvidia/blacklist bajo <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code>, y la regla VFIO bind + reglas udev de nvidia de ProxMenux bajo <code>/etc/udev/rules.d</code>. Los ficheros propiedad de la distro (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) se excluyen intencionadamente — sus contenidos evolucionan entre releases." },
-      { "phase": "4 — Forzar reflows post-arranque", "detail": "Las cuatro fases escriben directamente en el destino vivo FUERA del pipeline normal de restauración. Para que los tokens/módulos/ficheros mergeados tengan efecto en el siguiente arranque, <code>HB_HYDRATION_APPLIED=1</code> se propaga a través de <code>plan.env</code> a <code>apply_pending_restore.sh</code>, que fuerza <code>NEEDS_INITRAMFS=1</code> y <code>NEEDS_GRUB=1</code> con independencia de lo que hubiera en la lista de apply. El dispatcher post-arranque después regenera el initramfs y refresca el bootloader." }
+      {
+        "phase": "1a — Ruta GRUB",
+        "detail": "Para hosts que usan GRUB (instalaciones ext4/lvm). <code>_rs_hyd_grub</code> mergea cada token de <code>manifest.kernel_params.cmdline_extra</code> del backup en el <code>GRUB_CMDLINE_LINUX_DEFAULT</code> vivo del destino, saltando los tokens cuya clave el destino ya lleva. Después mergea claves whitelisted <code>GRUB_*</code> (<code>GRUB_TIMEOUT</code>, <code>GRUB_TIMEOUT_STYLE</code>, <code>GRUB_DEFAULT</code>, <code>GRUB_TERMINAL</code>, <code>GRUB_DISABLE_OS_PROBER</code>, <code>GRUB_SERIAL_COMMAND</code>, <code>GRUB_GFXMODE</code>, <code>GRUB_GFXPAYLOAD_LINUX</code>) del <code>/etc/default/grub</code> del backup si difieren de las del destino."
+      },
+      {
+        "phase": "1b — Ruta systemd-boot / ZFS",
+        "detail": "Para hosts que usan systemd-boot (típicamente ZFS-on-root). <code>_rs_hyd_kernel_cmdline</code> mergea los tokens del usuario de <code>cmdline_extra</code> en el <code>/etc/kernel/cmdline</code> del destino, manteniendo intacto el boilerplate propio del destino: <code>root=</code>, <code>boot=</code> y <code>rootflags=</code>."
+      },
+      {
+        "phase": "2 — Merge en /etc/modules",
+        "detail": "<code>_rs_hyd_modules</code> añade los módulos de <code>manifest.kernel_params.modules_loaded_at_boot</code> que estén en la whitelist (<code>vfio</code>, <code>vfio_pci</code>, <code>vfio_iommu_type1</code>, <code>vfio_virqfd</code>, <code>kvm</code>, <code>kvm_intel</code>, <code>kvm_amd</code>, <code>nvidia</code>, <code>nvidia_drm</code>, <code>nvidia_modeset</code>, <code>nvidia_uvm</code>, <code>i915</code>, <code>xe</code>) Y que aún no estén presentes en <code>/etc/modules</code> del destino."
+      },
+      {
+        "phase": "3 — Copia de ficheros whitelisted",
+        "detail": "<code>_rs_hyd_files</code> copia ficheros escritos por el usuario del staging rootfs al destino en vivo cuando el contenido difiere. La whitelist cubre ficheros VFIO/nvidia/blacklist bajo <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code>, y la regla VFIO bind + reglas udev de nvidia de ProxMenux bajo <code>/etc/udev/rules.d</code>. Los ficheros propiedad de la distro (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) se excluyen intencionadamente — sus contenidos evolucionan entre releases."
+      },
+      {
+        "phase": "4 — Forzar reflows post-arranque",
+        "detail": "Las cuatro fases escriben directamente en el destino vivo FUERA del pipeline normal de restauración. Para que los tokens/módulos/ficheros mergeados tengan efecto en el siguiente arranque, <code>HB_HYDRATION_APPLIED=1</code> se propaga a través de <code>plan.env</code> a <code>apply_pending_restore.sh</code>, que fuerza <code>NEEDS_INITRAMFS=1</code> y <code>NEEDS_GRUB=1</code> con independencia de lo que hubiera en la lista de apply. El dispatcher post-arranque después regenera el initramfs y refresca el bootloader."
+      }
     ]
   },
   "planCommit": {
@@ -57,7 +104,7 @@
     "body": "La hidratación corre en dos modos. Antes del diálogo de confirmación, ProxMenux ejecuta <code>_rs_apply_bk_older_hydration</code> en modo <code>plan</code>: calcula exactamente lo que se mergearía, rellena <code>RS_HYDRATION_SUMMARY</code> con un bloque verde que lista cada acción, y retorna sin escribir nada. El diálogo de confirmación muestra ese bloque verde junto a la lista ámbar de rutas saltadas por el subconjunto seguro, para que el usuario vea POR ADELANTADO qué se reaplicará automáticamente. Tras la confirmación del usuario, ProxMenux vuelve a ejecutar el mismo helper en modo <code>commit</code> — mismas fases, misma lógica, pero esta vez cada fase escribe en el destino vivo. Cancelar el diálogo de confirmación deja el destino intacto."
   },
   "flowDiagram": {
-    "heading": "El flujo cuando el kernel del destino es más reciente que el de la copia",
+    "heading": "El flujo cuando el kernel del destino es más reciente que el del backup",
     "intro": "Los pasos específicos que se añaden cuando el kernel del destino es más reciente se insertan dentro del flujo normal de restauración. Todo lo demás — hot apply, prepare pending, instalación de paquetes, dispatcher post-arranque — corre idéntico a una restauración con el mismo kernel.",
     "diagram": "  ┌────────────────────────────────────────────────────────────┐\n  │ hb_compat_check                                             │\n  │   HB_COMPAT_KERNEL_DIRECTION = bk_older                     │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ Añade 16 rutas críticas del arranque a RS_SKIP_PATHS        │\n  │   /etc/default/grub, /etc/kernel, /etc/modules-load.d, ...  │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ _rs_apply_bk_older_hydration \"plan\"                         │\n  │   Calcula qué se mergearía                                  │\n  │   Rellena RS_HYDRATION_SUMMARY (bloque verde)               │\n  │   Sin escrituras                                            │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ Diálogo de confirmación                                     │\n  │   Ámbar: rutas saltadas por el filtro de subconjunto seguro │\n  │   Verde: tokens/ficheros reaplicados por la hidratación     │\n  │   El usuario acepta o cancela                               │\n  └───────────────────────────┬────────────────────────────────┘\n                              │ (aceptado)\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ _rs_apply_bk_older_hydration \"commit\"                       │\n  │   Fase 1a/1b: mergea tokens del cmdline + claves GRUB       │\n  │   Fase 2: añade módulos a /etc/modules                      │\n  │   Fase 3: copia ficheros whitelisted vfio/nvidia            │\n  │   Fija HB_HYDRATION_APPLIED=1                               │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ El resto de la restauración corre normalmente               │\n  │   _rs_apply hot (salta RS_SKIP_PATHS)                       │\n  │   _rs_prepare_pending_restore (escribe plan.env con         │\n  │     HB_HYDRATION_APPLIED=1)                                 │\n  │   packages.manual.list install                              │\n  │   Reinicio                                                  │\n  │   apply_pending_restore.sh (fuerza NEEDS_INITRAMFS=1,       │\n  │     NEEDS_GRUB=1 por el flag de hidratación)                │\n  │   apply_cluster_postboot.sh                                 │\n  │     update-initramfs -u -k all                              │\n  │     update-grub / proxmox-boot-tool refresh                 │\n  │     component --auto-reinstall                              │\n  └────────────────────────────────────────────────────────────┘"
   },
@@ -65,30 +112,59 @@
     "heading": "Ejemplos concretos",
     "intro": "La pasada de hidratación no es abstracta — produce resultados observables y correctos en escenarios habituales. Dos ejemplos que la hidratación resuelve automáticamente:",
     "rows": [
-      { "scenario": "GPU passthrough (VFIO)", "detail": "El origen tenía <code>intel_iommu=on iommu=pt</code> en el cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> en <code>/etc/modules</code>, un <code>/etc/modprobe.d/vfio.conf</code> con <code>options vfio-pci ids=10de:2216</code>, y un <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. La hidratación mergea los tokens del cmdline en el GRUB o kernel cmdline del destino, añade los módulos vfio a <code>/etc/modules</code>, y copia los dos ficheros modprobe escritos por el usuario. En el siguiente arranque, IOMMU está activo, los módulos VFIO cargan, la GPU queda ligada a vfio-pci y la VM arranca con el passthrough funcionando." },
-      { "scenario": "Defaults custom de GRUB", "detail": "El origen tenía <code>GRUB_TIMEOUT=1</code> y <code>GRUB_DISABLE_OS_PROBER=true</code>. La hidratación lee ambas claves del <code>/etc/default/grub</code> de la copia, ve que difieren de los defaults de la instalación fresca, y reescribe esas dos líneas en el fichero del destino (dejando todo lo demás, incluido <code>GRUB_DISTRIBUTOR</code>, intacto)." }
+      {
+        "scenario": "GPU passthrough (VFIO)",
+        "detail": "El origen tenía <code>intel_iommu=on iommu=pt</code> en el cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> en <code>/etc/modules</code>, un <code>/etc/modprobe.d/vfio.conf</code> con <code>options vfio-pci ids=10de:2216</code>, y un <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. La hidratación mergea los tokens del cmdline en el GRUB o kernel cmdline del destino, añade los módulos vfio a <code>/etc/modules</code>, y copia los dos ficheros modprobe escritos por el usuario. En el siguiente arranque, IOMMU está activo, los módulos VFIO cargan, la GPU queda ligada a vfio-pci y la VM arranca con el passthrough funcionando."
+      },
+      {
+        "scenario": "Defaults custom de GRUB",
+        "detail": "El origen tenía <code>GRUB_TIMEOUT=1</code> y <code>GRUB_DISABLE_OS_PROBER=true</code>. La hidratación lee ambas claves del <code>/etc/default/grub</code> del backup, ve que difieren de los defaults de la instalación fresca, y reescribe esas dos líneas en el fichero del destino (dejando todo lo demás, incluido <code>GRUB_DISTRIBUTOR</code>, intacto)."
+      }
     ]
   },
   "callout": {
     "warningTitle": "Qué no reaplica la hidratación cuando el kernel del destino es más reciente",
-    "warningBody": "La hidratación reaplica sólo la configuración que ProxMenux sabe que es segura entre versiones del kernel: tokens IOMMU, IDs VFIO, claves whitelisted de GRUB y módulos de una lista fija (<code>vfio*</code>, <code>nvidia*</code>, <code>i915</code>, <code>xe</code>, <code>kvm*</code>). Todo lo que quede fuera de ese conjunto — hooks custom de initramfs bajo <code>/etc/initramfs-tools/hooks/</code>, ficheros no whitelisted bajo <code>/etc/modprobe.d/</code>, overrides de unit de systemd escritos por el usuario — permanece excluido. El motivo es concreto: esos ficheros pueden invocar interfaces internas del kernel (APIs de módulos, layout de <code>/sys</code>, hooks de <code>udev</code>) que cambian entre versiones mayores, y aplicarlos verbatim sobre el kernel más reciente puede impedir que el destino arranque. Cuando se necesita reproducción exacta de la cadena de arranque, la restauración debe correr sobre un host con la misma versión mayor de kernel que la copia."
+    "warningBody": "La hidratación reaplica sólo la configuración que ProxMenux sabe que es segura entre versiones del kernel: tokens IOMMU, IDs VFIO, claves whitelisted de GRUB y módulos de una lista fija (<code>vfio*</code>, <code>nvidia*</code>, <code>i915</code>, <code>xe</code>, <code>kvm*</code>). Todo lo que quede fuera de ese conjunto — hooks custom de initramfs bajo <code>/etc/initramfs-tools/hooks/</code>, ficheros no whitelisted bajo <code>/etc/modprobe.d/</code>, overrides de unit de systemd escritos por el usuario — permanece excluido. El motivo es concreto: esos ficheros pueden invocar interfaces internas del kernel (APIs de módulos, layout de <code>/sys</code>, hooks de <code>udev</code>) que cambian entre versiones mayores, y aplicarlos verbatim sobre el kernel más reciente puede impedir que el destino arranque. Cuando se necesita reproducción exacta de la cadena de arranque, la restauración debe correr sobre un host con la misma versión mayor de kernel que el backup."
   },
   "codeReference": {
     "heading": "Dónde viven los mecanismos",
     "intro": "Para desarrolladores que quieran trazar o extender el comportamiento cross-kernel:",
     "rows": [
-      { "component": "Detección de dirección", "location": "<code>hb_compat_check</code> en <code>lib_host_backup_common.sh</code>. Fija <code>HB_COMPAT_KERNEL_DIRECTION</code>." },
-      { "component": "Lista de rutas del subconjunto seguro", "location": "<code>hb_unsafe_paths_cross_version</code> en <code>lib_host_backup_common.sh</code>. Emite líneas <code>path\\treason</code> usadas tanto por el filtro CLI como por el endpoint Web <code>/api/host-backups/restore/prepare</code>." },
-      { "component": "Fases de hidratación", "location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> en <code>backup_host.sh</code>. Orquestados por <code>_rs_apply_bk_older_hydration</code>." },
-      { "component": "Forzado de reflow post-arranque", "location": "<code>apply_pending_restore.sh</code> lee <code>HB_HYDRATION_APPLIED</code> de <code>plan.env</code> y fuerza <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>." },
-      { "component": "Preview Web", "location": "<code>/api/host-backups/restore/prepare</code> en <code>flask_server.py</code>. Fuentea la librería helper, ejecuta <code>_rs_apply_bk_older_hydration</code> en modo plan, devuelve las acciones al modal Web." }
+      {
+        "component": "Detección de dirección",
+        "location": "<code>hb_compat_check</code> en <code>lib_host_backup_common.sh</code>. Fija <code>HB_COMPAT_KERNEL_DIRECTION</code>."
+      },
+      {
+        "component": "Lista de rutas del subconjunto seguro",
+        "location": "<code>hb_unsafe_paths_cross_version</code> en <code>lib_host_backup_common.sh</code>. Emite líneas <code>path\\treason</code> usadas tanto por el filtro CLI como por el endpoint Web <code>/api/host-backups/restore/prepare</code>."
+      },
+      {
+        "component": "Fases de hidratación",
+        "location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> en <code>backup_host.sh</code>. Orquestados por <code>_rs_apply_bk_older_hydration</code>."
+      },
+      {
+        "component": "Forzado de reflow post-arranque",
+        "location": "<code>apply_pending_restore.sh</code> lee <code>HB_HYDRATION_APPLIED</code> de <code>plan.env</code> y fuerza <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>."
+      },
+      {
+        "component": "Preview Web",
+        "location": "<code>/api/host-backups/restore/prepare</code> en <code>flask_server.py</code>. Fuentea la librería helper, ejecuta <code>_rs_apply_bk_older_hydration</code> en modo plan, devuelve las acciones al modal Web."
+      }
     ]
   },
   "whereNext": {
     "heading": "A dónde seguir",
     "items": [
-      { "label": "Restaurar", "href": "/docs/backup-restore/restoring", "tail": " — el pipeline completo de restauración en el que se enchufan los mecanismos de esta página." },
-      { "label": "Cómo funciona", "href": "/docs/backup-restore/how-it-works", "tail": " — el manifiesto y los colectores que producen el bloque <code>kernel_params</code> del que lee la hidratación." }
+      {
+        "label": "Restaurar",
+        "href": "/docs/backup-restore/restoring",
+        "tail": " — el pipeline completo de restauración en el que se enchufan los mecanismos de esta página."
+      },
+      {
+        "label": "Cómo funciona",
+        "href": "/docs/backup-restore/how-it-works",
+        "tail": " — el manifiesto y los colectores que producen el bloque <code>kernel_params</code> del que lee la hidratación."
+      }
     ]
   }
 }

web/messages/es/docs/backup-restore/destinations/borg.json

@@ -1,28 +1,28 @@
 {
   "meta": {
     "title": "Destino Borg — tipos de repositorio, autenticación SSH, cifrado | ProxMenux",
-    "description": "El destino Borg escribe las copias de host de ProxMenux en un repositorio Borg — local, en un disco externo montado, o en un servidor remoto accedido por SSH. Cubre la cadena de resolución del binario borg, las cuatro estrategias de clave SSH, el cifrado repokey, la configuración de destinos guardados y la retención por trabajo programado.",
+    "description": "El destino Borg escribe los backups de host de ProxMenux en un repositorio Borg — local, en un disco externo montado, o en un servidor remoto accedido por SSH. Cubre la cadena de resolución del binario borg, las cuatro estrategias de clave SSH, el cifrado repokey, la configuración de destinos guardados y la retención por trabajo programado.",
     "ogTitle": "ProxMenux Backup — destino Borg",
-    "ogDescription": "Cómo escribe ProxMenux las copias de host en repositorios Borg, con estrategias de autenticación SSH y cifrado repokey.",
-    "twitterTitle": "Destino Borg de copia | ProxMenux",
-    "twitterDescription": "Repositorios Borg local, USB y servidos por SSH para copias del host."
+    "ogDescription": "Cómo escribe ProxMenux los backups de host en repositorios Borg, con estrategias de autenticación SSH y cifrado repokey.",
+    "twitterTitle": "Destino Borg de backup | ProxMenux",
+    "twitterDescription": "Repositorios Borg local, USB y servidos por SSH para backups del host."
   },
   "header": {
     "title": "Borg",
-    "description": "El destino Borg escribe las copias del host en un repositorio Borg. Se soportan tres tipos de repositorio: ruta local de sistema de ficheros, disco externo montado o servidor remoto vía SSH. Deduplicación a nivel de chunk entre todos los archivos del repositorio y cifrado opcional repokey.",
+    "description": "El destino Borg escribe los backups del host en un repositorio Borg. Se soportan tres tipos de repositorio: ruta local de sistema de ficheros, disco externo montado o servidor remoto vía SSH. Deduplicación a nivel de chunk entre todos los archivos del repositorio y cifrado opcional repokey.",
     "section": "Backup & Restore"
   },
   "aboutBorg": {
     "heading": "Qué es Borg",
-    "body": "Borg (también escrito BorgBackup) es una herramienta de copia de seguridad open-source con deduplicación, mantenida por la comunidad Borg Backup. Almacena cada archivo como un conjunto de chunks de longitud variable dentro de un repositorio; los chunks se comparten entre archivos, por lo que volver a copiar datos que no han cambiado tiene un coste de almacenamiento prácticamente nulo. Borg no está atado a Proxmox — es una herramienta de copia de uso general utilizada en muchos entornos. ProxMenux la usa como uno de los tres destinos para copias del host; cada mecanismo específico de Borg descrito en esta página (tipos de repositorio, borg-serve por SSH, cifrado repokey, prune) es comportamiento estándar de Borg."
+    "body": "Borg (también escrito BorgBackup) es una herramienta de backup open-source con deduplicación, mantenida por la comunidad Borg Backup. Almacena cada archivo como un conjunto de chunks de longitud variable dentro de un repositorio; los chunks se comparten entre archivos, por lo que volver a copiar datos que no han cambiado tiene un coste de almacenamiento prácticamente nulo. Borg no está atado a Proxmox — es una herramienta de backup de uso general utilizada en muchos entornos. ProxMenux la usa como uno de los tres destinos para backups del host; cada mecanismo específico de Borg descrito en esta página (tipos de repositorio, borg-serve por SSH, cifrado repokey, prune) es comportamiento estándar de Borg."
   },
   "intro": {
     "title": "Deduplicación por chunks con repositorios locales o servidos por SSH",
-    "body": "Un repositorio Borg almacena chunks que se comparten entre cada archivo que contiene, por lo que volver a copiar un fichero que no ha cambiado no transfiere ni almacena nada nuevo. ProxMenux invoca <code>borg create</code> contra el repositorio en el momento de la copia y <code>borg extract</code> en la restauración. El repositorio puede vivir en el mismo sistema de ficheros que el origen, en un disco externo montado, o en un host remoto accedido por SSH."
+    "body": "Un repositorio Borg almacena chunks que se comparten entre cada archivo que contiene, por lo que volver a copiar un fichero que no ha cambiado no transfiere ni almacena nada nuevo. ProxMenux invoca <code>borg create</code> contra el repositorio en el momento del backup y <code>borg extract</code> en la restauración. El repositorio puede vivir en el mismo sistema de ficheros que el origen, en un disco externo montado, o en un host remoto accedido por SSH."
   },
   "binarySourcing": {
     "heading": "El binario borg",
-    "intro": "Borg no es una dependencia base del instalador de ProxMenux. Cuando se ejecuta una copia, <code>hb_ensure_borg</code> resuelve el binario desde cuatro fuentes por orden y devuelve la primera que funciona:",
+    "intro": "Borg no es una dependencia base del instalador de ProxMenux. Cuando se ejecuta un backup, <code>hb_ensure_borg</code> resuelve el binario desde cuatro fuentes por orden y devuelve la primera que funciona:",
     "rows": [
       {
         "priority": "1",
@@ -42,7 +42,7 @@
       {
         "priority": "4",
         "source": "Descarga desde GitHub",
-        "detail": "<code>wget</code> contra la URL fijada de <code>borg-linux64</code> bajo <code>github.com/borgbackup/borg/releases/</code>, verificado contra un SHA-256 constante en <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). Si el checksum no coincide, el binario se descarta y la copia se aborta. El fichero descargado se cachea en el state-dir para que las copias posteriores usen el camino 2."
+        "detail": "<code>wget</code> contra la URL fijada de <code>borg-linux64</code> bajo <code>github.com/borgbackup/borg/releases/</code>, verificado contra un SHA-256 constante en <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). Si el checksum no coincide, el binario se descarta y el backup se aborta. El fichero descargado se cachea en el state-dir para que los backups posteriores usen el camino 2."
       }
     ]
   },
@@ -74,11 +74,11 @@
     "hostChoicesBody": "Cualquier host Linux con acceso SSH cumple. Setups habituales:",
     "hostChoicesItems": [
       "Un NAS dedicado o caja de backup (Debian, Ubuntu, TrueNAS SCALE con shell).",
-      "Un contenedor LXC dentro de un nodo Proxmox. Huella pequeña, aislado del host que ejecuta las copias.",
+      "Un contenedor LXC dentro de un nodo Proxmox. Huella pequeña, aislado del host que ejecuta los backups.",
       "Otro host Proxmox en la misma LAN, o una VM en cualquier lugar alcanzable por SSH."
     ],
     "lxcWarningTitle": "LXC como servidor Borg",
-    "lxcWarningBody": "Si el servidor Borg se ejecuta dentro de un LXC, el contenedor debe tener una cuenta de usuario con contraseña.",
+    "lxcWarningBody": "Si el servidor Borg está en un LXC, generate-auto necesita una cuenta que acepte autenticación SSH por contraseña durante la instalación de la clave. Si no está disponible, utiliza la instalación manual de la clave o la alternativa generate-pct a través del host PVE.",
     "requirementsTitle": "Requisitos en el servidor",
     "requirementsRows": [
       {
@@ -101,18 +101,18 @@
     "minimalSetupTitle": "Setup mínimo del servidor",
     "minimalSetupBody": "En un servidor Borg Debian o Ubuntu, un baseline funcional son cuatro comandos como root:",
     "minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
-    "minimalSetupNote": "Tras esto, el modo <code>generate-auto</code> de ProxMenux puede conectarse usando la contraseña del usuario borg una vez, instalar su propia clave SSH, y cada copia posterior usa esa clave. No hace falta más configuración en el servidor — la clave se restringe a sí misma a <code>borg serve</code> sobre esa ruta."
+    "minimalSetupNote": "Con el servidor preparado y la autenticación SSH por contraseña disponible, <code>generate-auto</code> instala la clave mediante una cuenta que pueda escribir en authorized_keys del usuario borg. Los backups posteriores usan esa clave, restringida a <code>borg serve</code> en la ruta configurada. Si no hay acceso por contraseña, instala la clave manualmente o usa la alternativa a través del host PVE."
   },
   "sshAuth": {
     "heading": "Autenticación SSH (lado cliente)",
     "intro": "Los repositorios Borg remotos se acceden vía SSH. La conexión va desde el host ProxMenux a una cuenta de usuario en el servidor Borg que ejecuta <code>borg serve</code>. Ese usuario se llama típicamente <code>borg</code>, NO el usuario admin/root del servidor — la línea de comando de borg-serve bloquea la conexión a esa ruta concreta del repositorio (ver las estrategias de clave más abajo).",
-    "strategiesTitle": "Las cuatro estrategias de clave",
-    "strategiesIntro": "Al añadir un destino remoto, ProxMenux pregunta por el usuario SSH, host y ruta remota, y a continuación pregunta cómo autenticar. Cuatro modos:",
+    "strategiesTitle": "Estrategias de clave SSH",
+    "strategiesIntro": "Al añadir un destino remoto, ProxMenux pide el usuario SSH, el host, el puerto y la ruta remota, y ofrece cuatro opciones de autenticación. Si se rechaza la autenticación por contraseña, también ofrece generate-pct. Los modos se describen a continuación:",
     "strategyRows": [
       {
         "mode": "generate-auto",
         "label": "Recomendado",
-        "detail": "ProxMenux genera una nueva keypair ed25519 en <code>~/.ssh/borg_proxmenux_HOST_ed25519</code>, y a continuación usa <code>sshpass</code> para hacer login UNA VEZ en el servidor con la contraseña de admin y añadir la clave pública a <code>~borg/.ssh/authorized_keys</code>. La contraseña de admin se usa sólo para esa única llamada — nunca se almacena."
+        "detail": "ProxMenux genera o reutiliza un par de claves ed25519 en <code>~/.ssh/borg_proxmenux_HOST_ed25519</code> y usa <code>sshpass</code> para probar el acceso e instalar la clave pública en <code>~borg/.ssh/authorized_keys</code>. La contraseña es de una cuenta que pueda escribir ese archivo, normalmente root o el usuario borg. Se utiliza durante la configuración y no se guarda."
       },
       {
         "mode": "generate-manual",
@@ -153,11 +153,11 @@
         "content": "Passphrase del destino con el NAME dado arriba (<code>chmod 600</code>). Sólo está presente si el usuario eligió cifrado repokey."
       }
     ],
-    "outro": "Guardar es opcional — el usuario puede rechazar el prompt de guardado para una copia puntual que no deje credenciales en el host."
+    "outro": "Guardar el destino es opcional. Si se rechaza, no se guarda la configuración del destino con nombre, pero no se elimina una clave SSH generada. Si se activa repokey sin guardar el destino, ProxMenux guarda igualmente la frase de contraseña en el archivo heredado borg-pass.txt."
   },
   "encryption": {
     "heading": "Cifrado",
-    "body": "Los repositorios se inicializan con un modo de cifrado vía <code>hb_borg_init_if_needed</code>: <code>borg repo-create -e MODE</code> en versiones modernas, o el legacy <code>borg init --encryption=MODE</code>. ProxMenux expone dos modos: <code>repokey</code> (por defecto) y <code>none</code>. En modo <code>repokey</code>, Borg almacena la clave de cifrado dentro del propio repositorio; el acceso requiere una passphrase, que ProxMenux pregunta dos veces con validación de coincidencia y guarda en <code>borg-pass-NAME.txt</code>. Un diálogo de reconocimiento obligatorio se muestra tras guardar la passphrase: la passphrase es la única manera de acceder a los archivos cifrados, y perderla hace irrecuperable todo archivo del repositorio."
+    "body": "Los repositorios se inicializan con un modo de cifrado vía <code>hb_borg_init_if_needed</code>: <code>borg repo-create -e MODE</code> en versiones modernas, o el legacy <code>borg init --encryption=MODE</code>. ProxMenux expone dos modos: <code>repokey</code> (por defecto) y <code>none</code>. En modo <code>repokey</code>, Borg almacena la clave de cifrado dentro del propio repositorio; el acceso requiere una passphrase, que ProxMenux pregunta dos veces con validación de coincidencia y guarda en <code>borg-pass-NAME.txt</code> para destinos guardados, o en el archivo heredado descrito antes. Un diálogo de reconocimiento obligatorio se muestra tras guardar la passphrase: la passphrase es la única manera de acceder a los archivos cifrados, y perderla hace irrecuperable todo archivo del repositorio."
   },
   "runtimeEnv": {
     "heading": "Entorno de ejecución",
@@ -165,8 +165,8 @@
     "rows": [
       {
         "var": "BORG_RSH",
-        "value": "ssh -i SSH_KEY_PATH -o StrictHostKeyChecking=accept-new",
-        "purpose": "El comando de shell remoto que Borg usa para repositorios servidos por SSH. Se fija sólo cuando se seleccionó una clave personalizada; en caso contrario queda sin definir para que Borg use la configuración SSH por defecto."
+        "value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
+        "purpose": "Comando de shell remoto que Borg utiliza para repositorios SSH. Elegir una clave añade las opciones de identidad. Al añadir un destino con un puerto distinto del predeterminado, ProxMenux añade además -p PORT; los destinos guardados, los trabajos programados y el Monitor usan el puerto de la URL ssh://. Sin clave personalizada, y en un destino nuevo con el puerto predeterminado, la variable queda sin definir y Borg usa la configuración SSH del host."
       },
       {
         "var": "BORG_PASSPHRASE",
@@ -192,9 +192,9 @@
   },
   "archiveFormat": {
     "heading": "Nombrado de archivos y retención",
-    "intro": "Cada copia crea un archivo nuevo dentro del repositorio.",
+    "intro": "Cada backup crea un archivo nuevo dentro del repositorio.",
     "namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS",
-    "retentionBody": "Para trabajos programados, <code>run_scheduled_backup.sh</code> ejecuta <code>borg prune</code> contra el repositorio tras cada copia exitosa con los valores de retención configurados en el trabajo (<code>--keep-last</code>, <code>--keep-daily</code>, <code>--keep-weekly</code>). Las copias interactivas no aplican poda."
+    "retentionBody": "Para trabajos programados, <code>run_scheduled_backup.sh</code> ejecuta <code>borg prune</code> contra el repositorio tras cada backup exitoso con los valores de retención configurados en el trabajo (<code>--keep-last</code>, <code>--keep-daily</code>, <code>--keep-weekly</code>). Los backups interactivos no aplican poda."
   },
   "restoreAccess": {
     "heading": "Recuperación del lado de la restauración",
@@ -212,7 +212,7 @@
       {
         "label": "borg create",
         "href": "https://borgbackup.readthedocs.io/en/stable/usage/create.html",
-        "tail": " — el comando que ProxMenux invoca en cada copia, con todas las flags soportadas."
+        "tail": " — el comando que ProxMenux invoca en cada backup, con todas las flags soportadas."
       },
       {
         "label": "Cifrado del repositorio",

web/messages/es/docs/backup-restore/destinations/index.json

@@ -1,11 +1,11 @@
 {
   "meta": {
-    "title": "Destinos de copia — Local, Proxmox Backup Server, Borg | ProxMenux",
-    "description": "Tres backends de almacenamiento reciben el mismo contenido de una copia de ProxMenux: un archivo local .tar.zst en cualquier sistema de ficheros escribible, un backup en un datastore de Proxmox Backup Server o un archivo en un repositorio local o remoto de Borg. Cada backend tiene sus propias características de compresión, deduplicación, cifrado y red.",
+    "title": "Destinos de backup — Local, Proxmox Backup Server, Borg | ProxMenux",
+    "description": "Tres backends de almacenamiento reciben el mismo contenido de un backup de ProxMenux: un archivo local .tar.zst en cualquier sistema de ficheros escribible, un backup en un datastore de Proxmox Backup Server o un archivo en un repositorio local o remoto de Borg. Cada backend tiene sus propias características de compresión, deduplicación, cifrado y red.",
     "ogTitle": "Destinos de ProxMenux Backup",
-    "ogDescription": "Local, Proxmox Backup Server y Borg — tres backends de almacenamiento para el mismo contenido de copia del host.",
+    "ogDescription": "Local, Proxmox Backup Server y Borg — tres backends de almacenamiento para el mismo contenido de backup del host.",
     "twitterTitle": "Destinos de ProxMenux Backup | ProxMenux",
-    "twitterDescription": "Archivo local, Proxmox Backup Server y Borg como backends para copias del host."
+    "twitterDescription": "Archivo local, Proxmox Backup Server y Borg como backends para backups del host."
   },
   "header": {
     "title": "Destinos",
@@ -14,7 +14,7 @@
   },
   "intro": {
     "title": "El mismo contenido, tres backends",
-    "body": "Cada copia produce los mismos tres bloques (rootfs, manifiesto, aplicaciones). Lo que cambia entre destinos es cómo se almacenan esos bloques y cómo el usuario los recupera para una restauración. Cada backend está implementado como una función independiente en <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — pero los tres comparten el mismo paso de staging (<code>hb_prepare_staging</code>) y el mismo camino de restauración. La elección del destino sólo afecta a la escritura y la recuperación; no cambia lo que hace una restauración ni cómo consume el archivo."
+    "body": "Cada backup produce los mismos tres bloques (rootfs, manifiesto, aplicaciones). Lo que cambia entre destinos es cómo se almacenan esos bloques y cómo el usuario los recupera para una restauración. Cada backend está implementado como una función independiente en <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — pero los tres comparten el mismo paso de staging (<code>hb_prepare_staging</code>) y el mismo camino de restauración. La elección del destino sólo afecta a la escritura y la recuperación; no cambia lo que hace una restauración ni cómo consume el archivo."
   },
   "comparison": {
     "heading": "Comparativa de características",
@@ -29,12 +29,12 @@
       {
         "feature": "Compresión",
         "local": "zstd (nivel por defecto) mediante <code>tar --zstd</code>. Fallback a gzip.",
-        "pbs": "Gestionada por PBS. El cliente envía sin comprimir; el servidor chunkiza + comprime.",
-        "borg": "La integrada de Borg (lz4 por defecto). Configurable al inicializar el repo."
+        "pbs": "La gestiona proxmox-backup-client. ProxMenux no modifica las opciones de compresión.",
+        "borg": "La compresión integrada de Borg. ProxMenux ejecuta borg create sin modificar las opciones de compresión."
       },
       {
         "feature": "Deduplicación",
-        "local": "Ninguna. Cada copia es un archivo completo independiente.",
+        "local": "Ninguna. Cada backup es un archivo completo independiente.",
         "pbs": "Deduplicación completa a nivel de chunk entre todas las backups del datastore.",
         "borg": "Deduplicación completa a nivel de chunk entre todos los archivos del repositorio."
       },
@@ -46,9 +46,9 @@
       },
       {
         "feature": "Retención / poda",
-        "local": "Aplicada por trabajo programado vía <code>KEEP_LAST</code>. Los archivos antiguos (y sus sidecars + logs del runner) se eliminan de forma simétrica. Las copias interactivas no aplican poda.",
-        "pbs": "Aplicada por trabajo programado vía <code>proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly</code>. Las copias interactivas no aplican poda.",
-        "borg": "Aplicada por trabajo programado vía <code>borg prune --keep-last / --keep-daily / --keep-weekly</code>. Las copias interactivas no aplican poda."
+        "local": "Aplicada por trabajo programado vía <code>KEEP_LAST</code>. Los archivos antiguos (y sus sidecars + logs del runner) se eliminan de forma simétrica. Los backups interactivos no aplican poda.",
+        "pbs": "Aplicada por trabajo programado vía <code>proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly</code>. Los backups interactivos no aplican poda.",
+        "borg": "Aplicada por trabajo programado vía <code>borg prune --keep-last / --keep-daily / --keep-weekly</code>. Los backups interactivos no aplican poda."
       },
       {
         "feature": "Red",
@@ -75,11 +75,11 @@
     "captionBorg": "Borg"
   },
   "sameArchive": {
-    "heading": "El contenido interno de la copia es el mismo en cualquier destino",
+    "heading": "El contenido interno del backup es el mismo en cualquier destino",
     "body": "Los tres destinos contienen la misma estructura <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> descrita en <em>Cómo funciona</em>. Extraer un <code>.tar.zst</code> de un archivo local, restaurar un <code>.pxar</code> desde PBS o extraer un archivo de Borg con <code>borg extract</code> produce el mismo árbol de directorios. El proceso de restauración (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) lee los mismos tres componentes sin necesitar saber de qué destino proceden."
   },
   "extractStandalone": {
-    "heading": "Extraer una copia fuera de ProxMenux",
+    "heading": "Extraer un backup fuera de ProxMenux",
     "intro": "Cualquiera de los tres formatos de archivo se puede leer con herramientas estándar sin tener ProxMenux instalado en el host de lectura. Los comandos siguientes producen el mismo árbol de directorios que consume internamente una restauración.",
     "localCmd": "# Desde un archivo local .tar.zst:\ntar --zstd -xf hostcfg-HOST-TIMESTAMP.tar.zst\n\n# Desde el fallback .tar.gz:\ntar -xzf hostcfg-HOST-TIMESTAMP.tar.gz",
     "pbsCmd": "# Desde un backup PBS (requiere proxmox-backup-client):\nproxmox-backup-client restore \\\n    --repository USER@REALM@HOST:DATASTORE \\\n    host/hostcfg-HOST/BACKUP-TIME \\\n    hostcfg.pxar /tmp/hostcfg\n\n# Añadir --keyfile KEY-PATH cuando el backup está cifrado.",

web/messages/es/docs/backup-restore/destinations/local.json

@@ -1,11 +1,11 @@
 {
   "meta": {
     "title": "Destino de archivo local — tar.zst en filesystem o unidad USB | ProxMenux",
-    "description": "El destino local de la copia escribe un único archivo .tar.zst en cualquier directorio escribible: un disco interno, un punto de montaje de Proxmox, un share NFS o una unidad USB. Documenta el flujo de configuración, la lógica de detección y montaje USB, el chequeo de seguridad contra escribir el archivo dentro de una ruta que se está copiando, y el sidecar JSON que identifica el fichero.",
+    "description": "El destino local del backup escribe un único archivo .tar.zst en cualquier directorio escribible: un disco interno, un punto de montaje de Proxmox, un share NFS o una unidad USB. Documenta el flujo de configuración, la lógica de detección y montaje USB, el chequeo de seguridad contra escribir el archivo dentro de una ruta que se está copiando, y el sidecar JSON que identifica el fichero.",
     "ogTitle": "ProxMenux Backup — Destino local",
-    "ogDescription": "Cómo escribe ProxMenux las copias locales como archivos .tar.zst y cómo configurar el directorio de destino o la unidad USB.",
-    "twitterTitle": "Destino local de copia | ProxMenux",
-    "twitterDescription": "Cómo escribe ProxMenux las copias locales como archivos .tar.zst en filesystem o USB."
+    "ogDescription": "Cómo escribe ProxMenux los backups locales como archivos .tar.zst y cómo configurar el directorio de destino o la unidad USB.",
+    "twitterTitle": "Destino local de backup | ProxMenux",
+    "twitterDescription": "Cómo escribe ProxMenux los backups locales como archivos .tar.zst en filesystem o USB."
   },
   "header": {
     "title": "Archivo local",
@@ -14,11 +14,11 @@
   },
   "intro": {
     "title": "Un solo fichero, autocontenido",
-    "body": "Una copia local produce un único fichero <code>hostcfg-HOST-TIMESTAMP.tar.zst</code> (o <code>.tar.gz</code> cuando <code>zstd</code> no está presente). El fichero contiene el árbol completo del archivo — <code>manifest.json</code>, <code>metadata/</code> y <code>rootfs/</code> — y puede restaurarse en cualquier host Proxmox con el flujo de restauración de ProxMenux, o extraerse a mano con <code>tar --zstd -xf</code> en cualquier sistema Linux. Sin servidor, sin inicialización de repositorio, sin dependencia externa. Es el destino con el camino de recuperación más corto cuando ni PBS ni Borg están disponibles."
+    "body": "Un backup local produce un único fichero <code>hostcfg-HOST-TIMESTAMP.tar.zst</code> (o <code>.tar.gz</code> cuando <code>zstd</code> no está presente). El fichero contiene el árbol completo del archivo — <code>manifest.json</code>, <code>metadata/</code> y <code>rootfs/</code> — y puede restaurarse en cualquier host Proxmox con el flujo de restauración de ProxMenux, o extraerse a mano con <code>tar --zstd -xf</code> en cualquier sistema Linux. Sin servidor, sin inicialización de repositorio, sin dependencia externa. Es el destino con el camino de recuperación más corto cuando ni PBS ni Borg están disponibles."
   },
   "targetConfig": {
     "heading": "Configurar el directorio de destino",
-    "intro": "El destino local es un <strong>único directorio de destino persistido</strong> — no una lista. ProxMenux guarda la elección del usuario en <code>/usr/local/share/proxmenux/local-target.conf</code> y la lee en cada copia. Cuando no hay ningún destino configurado, se usa el valor por defecto <code>HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump</code> (el mismo directorio que Proxmox utiliza para las salidas de <code>vzdump</code>). El destino se configura desde <em>Configure backup destinations → Local destinations</em>:",
+    "intro": "El destino local es un <strong>único directorio de destino persistido</strong> — no una lista. ProxMenux guarda la elección del usuario en <code>/usr/local/share/proxmenux/local-target.conf</code> y la lee en cada backup. Cuando no hay ningún destino configurado, se usa el valor por defecto <code>HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump</code> (el mismo directorio que Proxmox utiliza para las salidas de <code>vzdump</code>). El destino se configura desde <em>Configure backup destinations → Local destinations</em>:",
     "options": [
       "<strong>Usar el valor por defecto (<code>/var/lib/vz/dump</code>).</strong> El almacenamiento local de Proxmox. Está presente en cualquier instalación de Proxmox; el archivo queda junto a las salidas de vzdump y lo detecta automáticamente la pestaña Backups del Monitor.",
       "<strong>Introducir una ruta personalizada.</strong> Cualquier ruta absoluta del sistema de ficheros vale: un montaje NFS, un share SMB montado por <code>fstab</code>, un dataset ZFS dedicado, un segundo disco interno. ProxMenux valida que la ruta existe y es un directorio antes de persistirla.",
@@ -32,7 +32,7 @@
     "stateRows": [
       {
         "state": "mounted",
-        "shown": "Tamaño · label · [fstype] · → /punto/de/montaje",
+        "shown": "Tamaño · label · [fstype] · → /mount/point",
         "action": "La partición ya está montada en algún sitio. Seleccionarla persiste ese punto de montaje como destino local. No se realiza ningún montaje."
       },
       {
@@ -50,11 +50,11 @@
   },
   "safetyCheck": {
     "heading": "Chequeo de seguridad — destino dentro de una ruta copiada",
-    "body": "Antes de escribir el archivo, <code>_bk_local</code> verifica que el directorio de destino <strong>no</strong> sea un subcamino de ninguno de los directorios que se están copiando. Un footgun habitual sería añadir <code>/root</code> al perfil y elegir <code>/root/backups</code> como destino — el archivo se incluiría a sí mismo, produciendo o bien un archivo corrupto o bien crecimiento sin límite hasta llenar el disco. El chequeo resuelve ambos caminos con <code>readlink -m</code>, los compara y, si hay conflicto, aborta la copia con un diálogo que nombra la ruta en conflicto y lista tres formas de resolverlo: elegir un destino fuera de la ruta en conflicto, eliminar la entrada personalizada que contiene el destino, o usar modo Custom para desmarcar la ruta en conflicto en esa ejecución."
+    "body": "Antes de escribir el archivo, <code>_bk_local</code> verifica que el directorio de destino <strong>no</strong> sea un subcamino de ninguno de los directorios que se están copiando. Un footgun habitual sería añadir <code>/root</code> al perfil y elegir <code>/root/backups</code> como destino — el archivo se incluiría a sí mismo, produciendo o bien un archivo corrupto o bien crecimiento sin límite hasta llenar el disco. El chequeo resuelve ambos caminos con <code>readlink -m</code>, los compara y, si hay conflicto, aborta el backup con un diálogo que nombra la ruta en conflicto y lista tres formas de resolverlo: elegir un destino fuera de la ruta en conflicto, eliminar la entrada personalizada que contiene el destino, o usar modo Custom para desmarcar la ruta en conflicto en esa ejecución."
   },
   "archiveFormat": {
     "heading": "Formato de archivo y compresión",
-    "intro": "El nombre del fichero de salida incorpora el hostname del origen y el timestamp de la copia para que un directorio con varios archivos se ordene cronológicamente y cada fichero se identifique por sí mismo.",
+    "intro": "El nombre del fichero de salida incorpora el hostname del origen y el timestamp del backup para que un directorio con varios archivos se ordene cronológicamente y cada fichero se identifique por sí mismo.",
     "namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS.tar.zst",
     "compressionTitle": "Compresión",
     "compressionBody": "El camino principal usa <code>tar --zstd -cf</code> — un pipeline de un solo comando que comprime al nivel por defecto de zstd. Cuando <code>zstd</code> no está presente en el origen (raro en Proxmox pero posible en instalaciones minimalistas), ProxMenux cae en <code>gzip</code>. En el camino de fallback, si <code>pv</code> está disponible, se añade una barra de progreso al pipeline para que el usuario vea crecer el tamaño del archivo en tiempo real; sin <code>pv</code>, se usa <code>tar -czf</code> plano en silencio.",
@@ -63,13 +63,13 @@
   },
   "sidecar": {
     "heading": "El sidecar JSON",
-    "intro": "Cada copia local con éxito produce un fichero compañero: <code>HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json</code>, escrito junto al archivo por <code>hb_write_archive_sidecar</code>. Este pequeño fichero JSON permite al Monitor de ProxMenux identificar el archivo como una copia de host de ProxMenux incluso si posteriormente se mueve, renombra o archiva en otro lugar.",
+    "intro": "Cada backup local con éxito produce un fichero compañero: <code>HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json</code>, escrito junto al archivo por <code>hb_write_archive_sidecar</code>. Este pequeño fichero JSON permite al Monitor de ProxMenux identificar el archivo como un backup de host de ProxMenux incluso si posteriormente se mueve, renombra o archiva en otro lugar.",
     "contentTitle": "Contenido del sidecar",
-    "contentBody": "El sidecar almacena la versión de schema, si la copia viene de una ejecución interactiva o de un trabajo programado (<code>kind</code>), el ID de trabajo para las ejecuciones programadas, el modo de perfil usado (<code>default</code> o <code>custom</code>), el hostname del origen, el basename original del archivo, un timestamp de creación en ISO-8601 y el tamaño del archivo en bytes.",
-    "whyBody": "La pestaña Backups del Monitor escanea los directorios locales configurados buscando sidecars <code>*.proxmenux.json</code> — no ficheros <code>*.tar.zst</code> — porque un <code>.tar.zst</code> sin sidecar podría no ser una copia de ProxMenux en absoluto. El escaneo es rápido (los JSON son diminutos) y el emparejamiento es estable frente a renombrados del archivo mientras el sidecar se renombre en paralelo."
+    "contentBody": "El sidecar almacena la versión de schema, si el backup viene de una ejecución interactiva o de un trabajo programado (<code>kind</code>), el ID de trabajo para las ejecuciones programadas, el modo de perfil usado (<code>default</code> o <code>custom</code>), el hostname del origen, el basename original del archivo, un timestamp de creación en ISO-8601 y el tamaño del archivo en bytes.",
+    "whyBody": "La pestaña Backups del Monitor escanea los directorios locales configurados buscando sidecars <code>*.proxmenux.json</code> — no ficheros <code>*.tar.zst</code> — porque un <code>.tar.zst</code> sin sidecar podría no ser un backup de ProxMenux en absoluto. El escaneo es rápido (los JSON son diminutos) y el emparejamiento es estable frente a renombrados del archivo mientras el sidecar se renombre en paralelo."
   },
   "restoreAccess": {
     "heading": "Restaurar desde un archivo local",
-    "body": "El flujo de restauración de ProxMenux descubre los archivos locales escaneando el destino local configurado buscando sidecars y mostrándolos en la lista de copias disponibles. Seleccionar uno dispara <code>_rs_check_layout</code>, que extrae el tarball en un directorio de staging y confirma el layout de tres bloques antes de continuar. Para una extracción manual fuera de ProxMenux, <code>tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg</code> produce el mismo árbol que consume el código de restauración."
+    "body": "El flujo de restauración de ProxMenux descubre los archivos locales escaneando el destino local configurado buscando sidecars y mostrándolos en la lista de backups disponibles. Seleccionar uno dispara <code>_rs_check_layout</code>, que extrae el tarball en un directorio de staging y confirma el layout de tres bloques antes de continuar. Para una extracción manual fuera de ProxMenux, <code>tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg</code> produce el mismo árbol que consume el código de restauración."
   }
 }

web/messages/es/docs/backup-restore/destinations/pbs.json

@@ -1,10 +1,10 @@
 {
   "meta": {
     "title": "Destino Proxmox Backup Server — repositorio, cifrado, recuperación | ProxMenux",
-    "description": "El destino PBS escribe las copias de host de ProxMenux como backups PBS. Documenta la auto-detección del repositorio desde /etc/pve/storage.cfg, la configuración manual de PBS, el comando de subida .pxar, el modelo de cifrado por keyfile del lado del cliente, el blob de escrow con passphrase de recuperación, y la recuperación del keyfile desde PBS en instalaciones frescas.",
+    "description": "El destino PBS escribe los backups de host de ProxMenux como backups PBS. Documenta la auto-detección del repositorio desde /etc/pve/storage.cfg, la configuración manual de PBS, el comando de subida .pxar, el modelo de cifrado por keyfile del lado del cliente, el blob de escrow con passphrase de recuperación, y la recuperación del keyfile desde PBS en instalaciones frescas.",
     "ogTitle": "ProxMenux Backup — destino Proxmox Backup Server",
-    "ogDescription": "Cómo escribe ProxMenux las copias de host en Proxmox Backup Server con cifrado por keyfile del lado del cliente y escrow de recuperación.",
-    "twitterTitle": "Destino PBS de copia | ProxMenux",
+    "ogDescription": "Cómo escribe ProxMenux los backups de host en Proxmox Backup Server con cifrado por keyfile del lado del cliente y escrow de recuperación.",
+    "twitterTitle": "Destino PBS de backup | ProxMenux",
     "twitterDescription": "Destino Proxmox Backup Server con cifrado por keyfile y escrow de passphrase de recuperación."
   },
   "header": {
@@ -15,15 +15,15 @@
   "recommendedBadge": "Destino recomendado",
   "aboutPbs": {
     "heading": "Qué es Proxmox Backup Server",
-    "body": "Proxmox Backup Server (PBS) es el producto de servidor de copias propio de Proxmox, desarrollado y mantenido por el mismo equipo que autora Proxmox VE. Es un servidor dedicado diseñado para recibir copias desde hosts Proxmox VE (VMs, LXCs y — vía <code>proxmox-backup-client</code> — directorios arbitrarios del host) con deduplicación a nivel de chunk, cifrado del lado del cliente y políticas de retención aplicadas del lado del servidor. ProxMenux usa PBS como uno de los tres destinos para copias del host; cada mecanismo específico de PBS descrito en esta página (grupos de copia, archivos <code>.pxar</code>, <code>--backup-id</code>, cifrado por keyfile) es comportamiento estándar de PBS."
+    "body": "Proxmox Backup Server (PBS) es el producto de servidor de backups propio de Proxmox, desarrollado y mantenido por el mismo equipo que autora Proxmox VE. Es un servidor dedicado diseñado para recibir backups desde hosts Proxmox VE (VMs, LXCs y — vía <code>proxmox-backup-client</code> — directorios arbitrarios del host) con deduplicación a nivel de chunk, cifrado del lado del cliente y políticas de retención aplicadas del lado del servidor. ProxMenux usa PBS como uno de los tres destinos para backups del host; cada mecanismo específico de PBS descrito en esta página (grupos de backup, archivos <code>.pxar</code>, <code>--backup-id</code>, cifrado por keyfile) es comportamiento estándar de PBS."
   },
   "intro": {
     "title": "Un backup por ejecución, deduplicación a nivel de chunk",
-    "body": "Una copia PBS produce una única entrada en el datastore, agrupada bajo el backup ID <code>host/hostcfg-HOSTNAME/BACKUP-TIME</code>. El contenido es un archivo <code>.pxar</code> con el mismo layout de tres bloques descrito en <em>Cómo funciona</em>. PBS deduplica a nivel de chunk en todas las copias del datastore, por lo que las copias siguientes del mismo host transfieren y almacenan sólo los chunks que hayan cambiado. La retención la aplica el propio ProxMenux para los trabajos programados — <code>run_scheduled_backup.sh</code> ejecuta <code>proxmox-backup-client prune</code> con <code>--keep-last</code> / <code>--keep-daily</code> / <code>--keep-weekly</code> tras cada ejecución exitosa usando los valores configurados en el trabajo."
+    "body": "Un backup PBS produce una única entrada en el datastore, agrupada bajo el backup ID <code>host/hostcfg-HOSTNAME/BACKUP-TIME</code>. El contenido es un archivo <code>.pxar</code> con el mismo layout de tres bloques descrito en <em>Cómo funciona</em>. PBS deduplica a nivel de chunk en todos los backups del datastore, por lo que los backups siguientes del mismo host transfieren y almacenan sólo los chunks que hayan cambiado. La retención la aplica el propio ProxMenux para los trabajos programados — <code>run_scheduled_backup.sh</code> ejecuta <code>proxmox-backup-client prune</code> con <code>--keep-last</code> / <code>--keep-daily</code> / <code>--keep-weekly</code> tras cada ejecución exitosa usando los valores configurados en el trabajo."
   },
   "repoSelection": {
     "heading": "Selección del repositorio",
-    "intro": "ProxMenux descubre los repositorios de PBS a partir de dos fuentes en cada copia de seguridad. El usuario elige uno en un menú unificado; esa elección determina los valores de <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> y <code>HB_PBS_FINGERPRINT</code> para esa ejecución.",
+    "intro": "ProxMenux descubre los repositorios de PBS a partir de dos fuentes en cada backup. El usuario elige uno en un menú unificado; esa elección determina los valores de <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> y <code>HB_PBS_FINGERPRINT</code> para esa ejecución.",
     "sourceRows": [
       {
         "source": "storage.cfg de Proxmox (auto-descubierto)",
@@ -33,51 +33,51 @@
       {
         "source": "Configuración manual de ProxMenux",
         "path": "/usr/local/share/proxmenux/pbs-manual-configs.txt + pbs-pass-NAME.txt + pbs-fingerprint-NAME.txt",
-        "content": "Se añade desde <em>Configure backup destinations → PBS destinations → Add PBS</em>. Pregunta por un nombre, usuario (<code>root@pam</code> o <code>user@pbs!token</code>), host o IP, datastore y contraseña. La contraseña se re-pregunta ante entrada vacía — un guardado vacío persistiría silenciosamente y cada copia posterior fallaría con un error de autenticación opaco. Este camino se usa cuando el PBS objetivo no está registrado como storage de Proxmox."
+        "content": "Se añade desde <em>Configure backup destinations → PBS destinations → Add PBS</em>. Pregunta por un nombre, usuario (<code>root@pam</code> o <code>user@pbs!token</code>), host o IP, datastore y contraseña. La contraseña se re-pregunta ante entrada vacía — un guardado vacío persistiría silenciosamente y cada backup posterior fallaría con un error de autenticación opaco. Este camino se usa cuando el PBS objetivo no está registrado como storage de Proxmox."
       }
     ],
     "menuTitle": "Menú de selección",
-    "menuBody": "Ambas fuentes se muestran en un único menú, cada fila etiquetada con su origen (<code>[proxmox]</code> o <code>[manual]</code>). Las entradas cuya contraseña no se pudo resolver se marcan con un aviso <code>⚠ no password</code> — seleccionarlas dispara una re-introducción de contraseña antes de iniciar la copia. El fingerprint se pasa a <code>proxmox-backup-client</code> vía la variable de entorno <code>PBS_FINGERPRINT</code>; cuando no está presente, el cliente pide al usuario aceptar el certificado del servidor de forma interactiva en la primera copia."
+    "menuBody": "Ambas fuentes se muestran en un único menú, cada fila etiquetada con su origen (<code>[proxmox]</code> o <code>[manual]</code>). Las entradas cuya contraseña no se pudo resolver se marcan con un aviso <code>⚠ no password</code> — seleccionarlas dispara una re-introducción de contraseña antes de iniciar el backup. El fingerprint se pasa a <code>proxmox-backup-client</code> vía la variable de entorno <code>PBS_FINGERPRINT</code>; cuando no está presente, el cliente pide al usuario aceptar el certificado del servidor de forma interactiva en el primer backup."
   },
   "backupCommand": {
-    "heading": "El comando de copia",
-    "intro": "La subida es una única invocación de <code>proxmox-backup-client backup</code>. ProxMenux la ejecuta dentro de un envoltorio <code>env</code> para que las credenciales nunca aparezcan en la lista de argumentos del proceso.",
+    "heading": "El comando de backup",
+    "intro": "La subida se realiza con una única invocación de <code>proxmox-backup-client backup</code>. ProxMenux utiliza <code>env</code> para pasar al cliente la contraseña, la contraseña de cifrado y el fingerprint como variables de entorno.",
     "cmd": "env \\\n    PBS_PASSWORD=\"$HB_PBS_SECRET\" \\\n    PBS_ENCRYPTION_PASSWORD=\"$HB_PBS_ENC_PASS\" \\\n    PBS_FINGERPRINT=\"$HB_PBS_FINGERPRINT\" \\\n    proxmox-backup-client backup \\\n        hostcfg.pxar:$staging_root \\\n        --repository USER@REALM@HOST:DATASTORE \\\n        --backup-type host \\\n        --backup-id  hostcfg-HOSTNAME \\\n        --backup-time BACKUP-EPOCH \\\n        [--keyfile /usr/local/share/proxmenux/pbs-key.conf]",
     "backupIdTitle": "Nombrado del backup ID",
-    "backupIdBody": "El backup ID por defecto es <code>hostcfg-HOSTNAME</code>. Se pide al usuario que lo confirme o edite antes de la subida; cualquier carácter fuera de <code>[A-Za-z0-9_-]</code> se elimina y los guiones finales se recortan. Reutilizar el mismo ID entre ejecuciones es intencional — PBS trata el ID como un <em>grupo</em>, y cada copia posterior aparece como un nuevo backup dentro de ese grupo, compartiendo dedup con las ejecuciones previas.",
+    "backupIdBody": "El backup ID por defecto es <code>hostcfg-HOSTNAME</code>. Se pide al usuario que lo confirme o edite antes de la subida; cualquier carácter fuera de <code>[A-Za-z0-9_-]</code> se elimina y los guiones finales se recortan. Reutilizar el mismo ID entre ejecuciones es intencional — PBS trata el ID como un <em>grupo</em>, y cada backup posterior aparece como un nuevo backup dentro de ese grupo, compartiendo dedup con las ejecuciones previas.",
     "pxarTitle": "Qué se incluye dentro del archivo .pxar",
-    "pxarBody": "El origen del <code>.pxar</code> es todo el directorio <code>staging_root</code>, con <code>rootfs/</code>, <code>metadata/</code> y <code>manifest.json</code> juntos. Las versiones anteriores utilizaban <code>$staging_root/rootfs</code> como origen; esto dejaba <code>metadata/</code> fuera del archivo y la comprobación de compatibilidad de la restauración no tenía datos que leer, por lo que mostraba advertencias de restauración entre hosts incluso al restaurar en el mismo host. Las copias antiguas creadas solo a partir de rootfs siguen restaurándose correctamente mediante la rama del caso 3 de <code>_rs_check_layout</code>, que vuelve a colocar el árbol plano <code>etc/var/root/usr</code> dentro de una estructura <code>rootfs/</code>."
+    "pxarBody": "El origen del <code>.pxar</code> es todo el directorio <code>staging_root</code>, con <code>rootfs/</code>, <code>metadata/</code> y <code>manifest.json</code> juntos. Las versiones anteriores utilizaban <code>$staging_root/rootfs</code> como origen; esto dejaba <code>metadata/</code> fuera del archivo y la comprobación de compatibilidad de la restauración no tenía datos que leer, por lo que mostraba advertencias de restauración entre hosts incluso al restaurar en el mismo host. Los backups antiguos creados solo a partir de rootfs siguen restaurándose correctamente mediante la rama del caso 3 de <code>_rs_check_layout</code>, que vuelve a colocar el árbol plano <code>etc/var/root/usr</code> dentro de una estructura <code>rootfs/</code>."
   },
   "encryption": {
     "heading": "Cifrado del lado del cliente",
     "glossaryHint": "En esta sección aparecen los términos <em>clave</em>, <em>passphrase</em> y <em>sobre de recuperación</em>. El <glosarioLink>glosario</glosarioLink> resume las diferencias en una frase por término.",
-    "intro": "PBS puede cifrar las copias con una clave que vive solo en el host. Los datos se cifran en el host antes de subirse; en PBS llegan ya cifrados. En ProxMenux este cifrado es opcional. Al activarlo, el usuario decide aparte, con una pregunta sí/no, si quiere subir a PBS también una copia de esa clave envuelta con una passphrase (el sobre de recuperación) como red de seguridad. La respuesta se puede cambiar después desde el Monitor. La clave siempre queda en una única ruta del host — <code>/usr/local/share/proxmenux/pbs-key.conf</code> — y se reutiliza sin volver a preguntar en las copias siguientes.",
+    "intro": "PBS puede cifrar los backups con una clave que vive solo en el host. Los datos se cifran en el host antes de subirse; en PBS llegan ya cifrados. En ProxMenux este cifrado es opcional. Al activarlo, el usuario decide aparte, con una pregunta sí/no, si quiere subir a PBS también una copia de esa clave envuelta con una passphrase (el sobre de recuperación) como red de seguridad. La respuesta se puede cambiar después desde el Monitor. La clave siempre queda en una única ruta del host — <code>/usr/local/share/proxmenux/pbs-key.conf</code> — y se reutiliza sin volver a preguntar en los backups siguientes.",
     "keyfileTitle": "Configuración inicial de la clave",
-    "keyfileBody": "El diálogo aparece en la primera copia cifrada del host y hace dos preguntas. Primero, si se quiere cifrar la copia: <em>No</em> sigue sin cifrado; <em>Sí</em> pasa al segundo paso. Segundo, qué clave usar. Si ya hay una instalada en <code>/usr/local/share/proxmenux/pbs-key.conf</code>, se reutiliza sin preguntar más y las copias posteriores tampoco vuelven a preguntar. Si no la hay, aparecen dos opciones: <em>Generar una clave nueva</em> crea una con <code>proxmox-backup-client key create --kdf none</code>. <em>Usar una clave existente</em> busca primero una gestionada por PVE: si el repositorio PBS elegido tiene una en <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, ese fichero se copia solo a la ruta canónica. Si no hay ninguna que coincida, el diálogo pide la ruta absoluta donde el usuario ha dejado la clave en este host. En cualquier caso, el fichero termina en la ruta canónica con <code>chmod 600</code>.",
+    "keyfileBody": "El diálogo aparece en el primer backup cifrado del host y hace dos preguntas. Primero, si se quiere cifrar el backup: <em>No</em> sigue sin cifrado; <em>Sí</em> pasa al segundo paso. Segundo, qué clave usar. Si ya hay una instalada en <code>/usr/local/share/proxmenux/pbs-key.conf</code>, se reutiliza sin preguntar más y los backups posteriores tampoco vuelven a preguntar. Si no la hay, aparecen dos opciones: <em>Generar una clave nueva</em> crea una con <code>proxmox-backup-client key create --kdf none</code>. <em>Usar una clave existente</em> busca primero una gestionada por PVE: si el repositorio PBS elegido tiene una en <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, ese fichero se copia solo a la ruta canónica. Si no hay ninguna que coincida, el diálogo pide la ruta absoluta donde el usuario ha dejado la clave en este host. En cualquier caso, el fichero termina en la ruta canónica con <code>chmod 600</code>.",
     "modesTitle": "Clave por host o compartida",
     "modesIntro": "Los dos modos están soportados y ninguno se impone — el usuario elige según cómo tenga organizados sus hosts.",
     "modesPerHostTitle": "Clave por host (por defecto)",
-    "modesPerHostBody": "Cada host genera su propia clave la primera vez que se activa el cifrado. Es el modo con mayor aislamiento: si la clave de un host se ve comprometida, no afecta a las copias de ningún otro. Recomendado para entornos de producción y para escenarios donde cada host tiene su propio responsable o requisitos distintos.",
+    "modesPerHostBody": "Cada host genera su propia clave la primera vez que se activa el cifrado. Es el modo con mayor aislamiento: si la clave de un host se ve comprometida, no afecta a los backups de ningún otro. Recomendado para entornos de producción y para escenarios donde cada host tiene su propio responsable o requisitos distintos.",
     "modesSharedTitle": "Clave compartida (importar la misma en cada host)",
-    "modesSharedBody": "Se genera una única clave y se importa en todos los hosts mediante la opción <em>Usar una clave existente</em>. La gestión es más sencilla: hay un solo secreto que proteger, y cualquier host puede leer las copias de cualquier otro (útil para verificación centralizada, ejercicios de restauración cruzada o consolidación). A cambio, si la clave compartida se filtra queda expuesto todo el conjunto de hosts a la vez. Recomendado para laboratorios personales y entornos donde todos los hosts pertenecen al mismo responsable y comparten el mismo nivel de confianza.",
+    "modesSharedBody": "Se genera una única clave y se importa en todos los hosts mediante la opción <em>Usar una clave existente</em>. La gestión es más sencilla: hay un solo secreto que proteger, y cualquier host puede leer los backups de cualquier otro (útil para verificación centralizada, ejercicios de restauración cruzada o consolidación). A cambio, si la clave compartida se filtra queda expuesto todo el conjunto de hosts a la vez. Recomendado para laboratorios personales y entornos donde todos los hosts pertenecen al mismo responsable y comparten el mismo nivel de confianza.",
     "recoveryTitle": "¿Subir la clave a PBS? — el usuario decide",
-    "recoveryBody": "Justo después de elegir la clave, ProxMenux hace una única pregunta explícita — <em>¿Subir clave a PBS?</em> — con dos respuestas. <strong>No se sube nada a PBS hasta que el usuario responde Sí.</strong> La opción por defecto es <em>No, mantener solo local</em>: la clave se queda solo en su ruta local, ProxMenux no toca PBS con nada relacionado con la recuperación y el usuario gestiona por su cuenta la copia externa (desde el Monitor, el botón <em>Descargar archivo clave</em> de la fila del destino PBS la exporta en el acto). Al elegir <em>Sí, subir</em> se pide una passphrase de recuperación —dos veces, para comprobar que coincidan— y ProxMenux envuelve la clave con esa passphrase usando AES-256-CBC y PBKDF2 (600 000 iteraciones, sal aleatoria) en un fichero <code>pbs-key.recovery.enc</code>. A partir de ese momento, cada backup cifrado sube también ese fichero envuelto a PBS como un grupo de backup asociado. Ni la passphrase ni la clave en claro salen del host. La respuesta se puede cambiar después desde el Monitor en cualquier momento: el interruptor de la fila del destino PBS cambia entre Sí y No y se aplica al momento (empezar a subir, dejar de subir o cambiar la passphrase, según el estado).",
+    "recoveryBody": "Justo después de elegir la clave, ProxMenux pregunta <em>¿Subir clave a PBS?</em>, con dos respuestas. <strong>No se sube ningún artefacto de recuperación a PBS hasta que el usuario responde Sí.</strong> Por defecto se elige <em>No, mantener solo local</em>: la clave queda en su ruta canónica, ProxMenux no sube artefactos de recuperación a PBS y el usuario se encarga de guardarla fuera del host. El botón <em>Descargar archivo clave</em> del Monitor, en la fila del destino PBS, permite obtenerla cuando se necesite. Al elegir <em>Sí, subir</em>, se pide dos veces una frase de contraseña de recuperación y se comprueba que coincidan. ProxMenux protege la clave con AES-256-CBC y PBKDF2 (600.000 iteraciones y sal aleatoria) para generar <code>pbs-key.recovery.enc</code>. Cada backup cifrado posterior sube esa envoltura a PBS como un grupo de backup asociado. En estas subidas no se envían a PBS ni la frase de contraseña ni la clave en texto claro. La elección puede cambiarse en cualquier momento desde el Monitor: el control de custodia de la fila del destino permite elegir Sí o No y aplicar inmediatamente Iniciar subida, Detener subida o Actualizar frase de contraseña, según el estado.",
     "blobUploadTitle": "Grupo emparejado en PBS",
-    "blobUploadBody1": "Cuando la custodia está configurada como <em>Sí, subir</em>, ProxMenux sube el archivo de recuperación protegido a PBS después de cada copia cifrada. Lo guarda en un segundo grupo de copia asociado, con el mismo nombre que el grupo del host y el sufijo <code>-keyrecovery</code>. Los dos grupos aparecen juntos en la lista del almacén de datos: uno para las copias del host y otro para los archivos de recuperación. <strong>El archivo de recuperación nunca sale del host en texto plano</strong>: se cifra en el propio host con AES-256-CBC y PBKDF2 antes de enviar ningún dato (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS solo recibe el archivo ya cifrado.",
+    "blobUploadBody1": "Cuando la respuesta es <em>Sí, subir</em>, ProxMenux sube el sobre de recuperación a PBS después de cada backup cifrado como un segundo grupo emparejado, con el mismo nombre que el del host pero terminado en <code>-keyrecovery</code>. Los dos grupos aparecen juntos en el listado del datastore: uno con los backups del host, otro con los sobres de recuperación. <strong>El sobre nunca sale del host en claro</strong>: se cifra en el propio host con AES-256-CBC y PBKDF2 antes de enviar un solo byte (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS solo recibe el sobre ya cifrado.",
     "envelopeSecurityTitle": "¿No es un riesgo subir el archivo keyrecovery a PBS?",
     "envelopeSecurityBody": "El sobre viaja y se guarda cifrado en todo momento. La passphrase de recuperación no sale nunca del host: el cifrado ocurre en local antes de la subida y PBS solo recibe el resultado ya cifrado. Un administrador de PBS —o cualquiera con acceso al datastore— puede descargar el sobre, pero sin la passphrase no puede leer la clave que contiene: son solo bytes cifrados. Para reconstruir la clave hacen falta las dos cosas a la vez, el sobre y la passphrase, y solo el usuario tiene ambas.",
     "blobUploadConstraintTitle": "Por qué dos grupos y no uno solo cifrado",
-    "blobUploadConstraintBody": "Cada subida de <code>proxmox-backup-client backup</code> cifra todos sus archivos con la misma clave —o ninguno—. No hay opción intermedia. La copia del host tiene que ir cifrada con la clave. El sobre de recuperación no puede viajar en esa misma subida: quedaría cifrado con la clave que precisamente contiene, y en un equipo recién reinstalado no habría manera de abrirlo (haría falta la clave para descifrar la clave). Por eso salen dos subidas independientes y aparecen dos grupos separados: la copia del host la cifra PBS con la clave, y el sobre lo cifra ProxMenux con la passphrase antes de subirlo. Dos capas de cifrado distintas para dos cosas distintas.",
+    "blobUploadConstraintBody": "Una invocación de <code>proxmox-backup-client backup</code> cifra todos sus archivos con la misma clave o no cifra ninguno; no permite mezclar ambos casos. El backup del host se cifra con su archivo de clave, pero la envoltura de recuperación no puede acompañarla en la misma subida porque acabaría cifrada con la propia clave que contiene. En un host recién reinstalado sería imposible abrirla: haría falta la clave para descifrar esa misma clave. Por eso los dos artefactos se suben por separado y aparecen en dos grupos: el cliente PBS cifra el backup del host con el archivo de clave y ProxMenux cifra la envoltura con la frase de contraseña antes de subirla. Dos capas de cifrado distintas protegen dos elementos diferentes.",
     "blobUploadImageAlt": "Interfaz de PBS mostrando los grupos hostcfg-HOSTNAME y hostcfg-HOSTNAME-keyrecovery adyacentes en el listado del datastore.",
-    "blobUploadImageCaption": "Interfaz de PBS — los grupos de copia emparejados. El grupo principal contiene las copias del host; el grupo -keyrecovery contiene la clave envuelta con la passphrase.",
+    "blobUploadImageCaption": "Interfaz de PBS — los grupos de backup emparejados. El grupo principal contiene los backups del host; el grupo -keyrecovery contiene la clave envuelta con la passphrase.",
     "recoverTitle": "Recuperación en un equipo recién instalado",
-    "recoverBody": "Cuando la clave no está en su sitio —tras reinstalar el host desde cero o después de eliminarla a propósito— el flujo de restauración prueba tres fuentes en orden y se queda con la primera que produce una clave usable. Primero, si el repositorio PBS elegido tiene una clave gestionada por PVE en <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, se copia sola a la ruta canónica. Segundo, si en PBS hay un grupo <code>-keyrecovery</code>, se descarga la copia más reciente y se pide la passphrase de recuperación para abrirla. Tercero, si ninguna de las dos anteriores funciona o el usuario las descarta, el diálogo pide la ruta absoluta donde ha dejado la clave en este host, y se copia a la ruta canónica. El Monitor expone el mismo flujo dentro del modal de la copia. Si al Restaurar, Descargar o Ver contenido falta la clave, aparece un panel ámbar arriba del modal con las mismas tres vías de importación. Si la clave está instalada pero no es la correcta para esa copia, PBS devuelve un error de tipo <code>wrong key — manifest's key XX does not match provided key YY</code> y el modal muestra un panel estructurado con el fingerprint que PBS espera (el que quedó grabado en el manifest de la copia), para que el usuario sepa qué clave concreta necesita importar.",
+    "recoverBody": "Cuando la clave no está en su sitio —tras reinstalar el host desde cero o después de eliminarla a propósito— el flujo de restauración prueba tres fuentes en orden y se queda con la primera que produce una clave usable. Primero, si el repositorio PBS elegido tiene una clave gestionada por PVE en <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, se copia sola a la ruta canónica. Segundo, si en PBS hay un grupo <code>-keyrecovery</code>, se descarga el backup más reciente y se pide la passphrase de recuperación para abrirla. Tercero, si ninguna de las dos anteriores funciona o el usuario las descarta, el diálogo pide la ruta absoluta donde ha dejado la clave en este host, y se copia a la ruta canónica. El Monitor expone el mismo flujo dentro del modal del backup. Si al Restaurar, Descargar o Ver contenido falta la clave, aparece un panel ámbar arriba del modal con las mismas tres vías de importación. Si la clave está instalada pero no es la correcta para ese backup, PBS devuelve un error de tipo <code>wrong key — manifest's key XX does not match provided key YY</code> y el modal muestra un panel estructurado con el fingerprint que PBS espera (el que quedó grabado en el manifest del backup), para que el usuario sepa qué clave concreta necesita importar.",
     "monitorManagementTitle": "Gestionar la clave desde el Monitor",
-    "monitorManagementBody": "El Monitor muestra los controles del archivo de clave en cada fila de destino PBS de la página de configuración de copias. Hay tres acciones: <em>Descargar</em> envía el archivo de clave actual al navegador del usuario; <em>Subir</em> sustituye el archivo de clave instalado por uno proporcionado por el usuario (el anterior solo se sobrescribe cuando el nuevo se ha guardado correctamente en la ruta canónica); y <em>Eliminar</em> borra el archivo de clave del host. Junto a estas acciones hay un único control de custodia para la recuperación: las opciones Sí y No de <em>¿Subir la clave a PBS?</em>, un campo para la frase de contraseña al elegir Sí y un botón contextual para aplicar el cambio, con el texto <em>Iniciar subida</em>, <em>Detener subida</em> o <em>Actualizar frase de contraseña</em> según el estado actual. Todas las acciones utilizan los mismos endpoints de Flask que el menú de terminal, por lo que el resultado en disco y el estado en PBS son idénticos desde ambas interfaces."
+    "monitorManagementBody": "En la página de configuración de backups, la fila de cada destino PBS incluye los controles de la clave. Tiene tres acciones: <em>Descargar</em> exporta la clave actual al navegador del usuario, <em>Subir</em> reemplaza la clave instalada por otra que aporta el usuario (la anterior solo se sobrescribe cuando la nueva ha llegado correctamente a su ruta) y <em>Eliminar</em> retira la clave del host. Justo al lado está el interruptor del sobre de recuperación: un Sí/No para <em>¿Subir clave a PBS?</em>, un campo de passphrase que aparece al elegir Sí y un botón que se adapta al estado actual: <em>Empezar a subir</em>, <em>Dejar de subir</em> o <em>Actualizar passphrase</em>. Los controles del Monitor y el diálogo del shell hacen lo mismo por dentro, así que el resultado en disco y en PBS es idéntico se use el que se use."
   },
   "restoreAccess": {
     "heading": "Recuperación del lado de la restauración",
-    "body": "El flujo de restauración descubre las copias de host de ProxMenux en PBS listando los grupos de backups bajo el repositorio configurado y filtrando por patrón de backup ID. La pestaña Backups del Monitor renderiza la misma lista. Seleccionar un backup dispara <code>proxmox-backup-client restore</code> con el mismo repositorio + contraseña + fingerprint (y <code>--keyfile</code> cuando el backup iba cifrado), extrayendo el <code>.pxar</code> a un directorio de staging que <code>_rs_check_layout</code> alimenta al pipeline estándar de restauración. Para recuperación manual fuera de ProxMenux, el mismo comando extrae el archivo a cualquier ruta — el árbol resultante puede inspeccionarse o alimentar una restauración a mano."
+    "body": "El flujo de restauración descubre los backups de host de ProxMenux en PBS listando los grupos de backups bajo el repositorio configurado y filtrando por patrón de backup ID. La pestaña Backups del Monitor renderiza la misma lista. Seleccionar un backup dispara <code>proxmox-backup-client restore</code> con el mismo repositorio + contraseña + fingerprint (y <code>--keyfile</code> cuando el backup iba cifrado), extrayendo el <code>.pxar</code> a un directorio de staging que <code>_rs_check_layout</code> alimenta al pipeline estándar de restauración. Para recuperación manual fuera de ProxMenux, el mismo comando extrae el archivo a cualquier ruta — el árbol resultante puede inspeccionarse o alimentar una restauración a mano."
   },
   "references": {
     "heading": "Referencias",
@@ -91,7 +91,7 @@
       {
         "label": "proxmox-backup-client",
         "href": "https://pbs.proxmox.com/docs/backup-client.html",
-        "tail": " — la herramienta de línea de comandos que ProxMenux invoca en cada copia y restauración. Cubre backup IDs, tipos de backup, archivos, sintaxis del repositorio y variables de entorno."
+        "tail": " — la herramienta de línea de comandos que ProxMenux invoca en cada backup y restauración. Cubre backup IDs, tipos de backup, archivos, sintaxis del repositorio y variables de entorno."
       },
       {
         "label": "Cifrado del lado del cliente",
@@ -101,7 +101,7 @@
       {
         "label": "Gestión de datastores",
         "href": "https://pbs.proxmox.com/docs/storage.html",
-        "tail": " — creación y administración de los datastores que reciben las copias de host, incluyendo el layout del chunk-store y permisos."
+        "tail": " — creación y administración de los datastores que reciben los backups de host, incluyendo el layout del chunk-store y permisos."
       },
       {
         "label": "Poda y recolección de basura",

web/messages/es/docs/backup-restore/glossary.json

@@ -1,15 +1,15 @@
 {
   "meta": {
     "title": "Glosario de términos — Backup & Restore | ProxMenux",
-    "description": "Glosario de términos y definiciones en español para el sistema de copia y restauración de ProxMenux: cifrado, clave, passphrase, sobre de recuperación, PBS, chunks, rootfs, manifiesto, runner y hidratación cross-kernel.",
+    "description": "Glosario de términos y definiciones en español para el sistema de backup y restauración de ProxMenux: cifrado, clave, passphrase, sobre de recuperación, PBS, chunks, rootfs, manifiesto, runner y hidratación cross-kernel.",
     "ogTitle": "Glosario de Backup & Restore | ProxMenux",
-    "ogDescription": "Definiciones claras en español para los términos que aparecen en la documentación de copia y restauración de ProxMenux.",
+    "ogDescription": "Definiciones claras en español para los términos que aparecen en la documentación de backup y restauración de ProxMenux.",
     "twitterTitle": "Glosario Backup & Restore | ProxMenux",
     "twitterDescription": "Passphrase, keyfile, sobre de recuperación, rootfs, manifiesto, PBS, chunks — todo definido en español."
   },
   "header": {
     "title": "Glosario",
-    "description": "Términos que aparecen a lo largo de la documentación de copia y restauración, con su definición.",
+    "description": "Términos que aparecen a lo largo de la documentación de backup y restauración, con su definición.",
     "section": "Backup & Restore"
   },
   "intro": {
@@ -18,49 +18,42 @@
   "groups": [
     {
       "title": "Cifrado y recuperación de clave",
-      "intro": "Terminología del bloque de cifrado de copias en PBS. Incluye dos secretos distintos: una clave binaria y una passphrase escrita.",
+      "intro": "Terminología del bloque de cifrado de backups en PBS. Incluye dos secretos distintos: una clave binaria y una passphrase escrita.",
       "entries": [
         {
           "id": "passphrase-recuperacion",
           "term": "Passphrase de recuperación",
-          "also": "recovery passphrase",
-          "def": "Contraseña de texto que elige el usuario para proteger el <a href=\"#sobre-recuperacion\">sobre de recuperación</a>. Se pide dos veces con validación de coincidencia y solo se usa para cifrar el sobre y para descifrarlo si algún día hay que recuperar la clave. <strong>No sirve para desbloquear la clave del keyfile</strong> ni se envía nunca a PBS. Nunca sale del host durante una copia normal."
+          "def": "Contraseña de texto que elige el usuario para proteger el <a href=\"#sobre-recuperacion\">sobre de recuperación</a>. Se pide dos veces con validación de coincidencia y solo se usa para cifrar el sobre y para descifrarlo si algún día hay que recuperar la clave. <strong>No sirve para desbloquear la clave del keyfile</strong> ni se envía nunca a PBS. Nunca sale del host durante un backup normal."
         },
         {
           "id": "clave-cifrado",
           "term": "Clave de cifrado (keyfile)",
-          "also": "keyfile, PBS encryption key",
-          "def": "Fichero binario que Proxmox Backup Server utiliza para cifrar los <a href=\"#chunk\">chunks</a> de la copia antes de subirlos. Sin ese fichero, ninguna copia cifrada puede leerse. ProxMenux lo guarda en <code>/usr/local/share/proxmenux/pbs-key.conf</code> con permisos <code>600</code>. Es el activo que hay que proteger; el <a href=\"#sobre-recuperacion\">sobre de recuperación</a> existe precisamente para poder rescatar este fichero si se pierde."
+          "def": "Archivo de clave que proxmox-backup-client usa para cifrar los <a href=\"#chunk\">chunks</a> antes de subirlos a PBS. Sin la clave correspondiente no se leen los datos cifrados. ProxMenux lo guarda en <code>/usr/local/share/proxmenux/pbs-key.conf</code> con modo <code>600</code>. Protégelo: el <a href=\"#sobre-recuperacion\">sobre de recuperación</a> permite recuperarlo si se pierde."
         },
         {
           "id": "contrasena-keyfile",
           "term": "Contraseña de la clave (KDF passphrase)",
-          "also": "keyfile passphrase, scrypt passphrase",
-          "def": "Contraseña opcional que puede llevar la propia clave, distinta de la <a href=\"#passphrase-recuperacion\">passphrase de recuperación</a>. Solo aparece si la clave se creó con <code>--kdf scrypt</code> (una clave importada de otro sitio, por ejemplo). Sin ella, la clave no se puede desbloquear en cada uso. ProxMenux la persiste cifrada en el host para que las copias programadas puedan ejecutarse sin diálogo interactivo."
+          "def": "Contraseña opcional que puede llevar la propia clave, distinta de la <a href=\"#passphrase-recuperacion\">passphrase de recuperación</a>. Solo aparece si la clave se creó con <code>--kdf scrypt</code> (una clave importada de otro sitio, por ejemplo). Sin ella, la clave no se puede desbloquear en cada uso. ProxMenux la persiste cifrada en el host para que los backups programados puedan ejecutarse sin diálogo interactivo."
         },
         {
           "id": "sobre-recuperacion",
           "term": "Sobre de recuperación",
-          "also": "recovery envelope, escrow blob, pbs-key.recovery.enc",
           "def": "La propia <a href=\"#clave-cifrado\">clave de cifrado</a> envuelta en una capa adicional: se cifra con la <a href=\"#passphrase-recuperacion\">passphrase de recuperación</a> mediante <a href=\"#aes-256-cbc\">AES-256-CBC</a> y <a href=\"#pbkdf2\">PBKDF2</a> antes de salir del host. Es lo que se sube a PBS en el grupo <code>-keyrecovery</code>. Sin la passphrase, el sobre es opaco: descargarlo desde PBS no revela la clave."
         },
         {
           "id": "cifrado-cliente",
           "term": "Cifrado del lado del cliente",
-          "also": "client-side encryption",
           "def": "Modelo en el que los datos se cifran en el host de origen antes de subirse. PBS solo recibe y almacena datos cifrados; ni siquiera un administrador de PBS con acceso al datastore puede leerlos sin la clave. ProxMenux se apoya en este modelo y añade el <a href=\"#sobre-recuperacion\">sobre de recuperación</a> encima."
         },
         {
           "id": "kdf-none",
           "term": "--kdf none",
-          "also": "clave sin contraseña",
           "def": "Opción de <code>proxmox-backup-client key create</code> que genera una clave sin contraseña asociada. La clave se puede usar directamente sin ningún diálogo, lo que es imprescindible para que los trabajos programados corran de forma desatendida. Es lo que ProxMenux usa por defecto al generar una clave nueva."
         },
         {
           "id": "kdf-scrypt",
           "term": "--kdf scrypt",
-          "also": "clave con contraseña",
-          "def": "Opción de <code>proxmox-backup-client key create</code> que genera una clave protegida con una <a href=\"#contrasena-keyfile\">contraseña de la clave</a>. Cada vez que se usa la clave hay que desbloquearla con esa contraseña. ProxMenux acepta este tipo de claves al importarlas y guarda la contraseña cifrada para que las copias programadas puedan correr sin intervención."
+          "def": "Opción de <code>proxmox-backup-client key create</code> que genera una clave protegida con una <a href=\"#contrasena-keyfile\">contraseña de la clave</a>. Cada vez que se usa la clave hay que desbloquearla con esa contraseña. ProxMenux acepta este tipo de claves al importarlas y guarda la contraseña cifrada para que los backups programados puedan correr sin intervención."
         },
         {
           "id": "aes-256-cbc",
@@ -75,8 +68,8 @@
       ]
     },
     {
-      "title": "Estructura de la copia",
-      "intro": "Términos que describen lo que hay dentro de una copia, sea cual sea el destino.",
+      "title": "Estructura del backup",
+      "intro": "Términos que describen lo que hay dentro de un backup, sea cual sea el destino.",
       "entries": [
         {
           "id": "rootfs",
@@ -86,17 +79,17 @@
         {
           "id": "manifiesto",
           "term": "Manifiesto (manifest.json)",
-          "def": "Documento JSON estructurado que describe el host de origen en el momento de la copia: hardware, almacenamiento, kernel, componentes instalados por ProxMenux e inventario de VMs y LXCs. Lo genera ProxMenux con seis colectores independientes. La restauración lo utiliza para comparar origen y destino."
+          "def": "Documento JSON estructurado que describe el host de origen en el momento del backup: hardware, almacenamiento, kernel, componentes instalados por ProxMenux e inventario de VMs y LXCs. Lo genera ProxMenux con seis colectores independientes. La restauración lo utiliza para comparar origen y destino."
         },
         {
           "id": "staging",
           "term": "Directorio de staging",
-          "def": "Directorio temporal donde ProxMenux ensambla los tres bloques (rootfs, metadata y manifiesto) antes de empaquetarlos y subirlos al destino. Se elimina automáticamente al terminar la copia, incluso si se aborta."
+          "def": "Directorio temporal donde ProxMenux ensambla los tres bloques (rootfs, metadata y manifiesto) antes de empaquetarlos y subirlos al destino. Se elimina automáticamente al terminar el backup, incluso si se aborta."
         },
         {
           "id": "perfil-defecto",
           "term": "Perfil por defecto",
-          "def": "Conjunto curado de rutas que ProxMenux copia por defecto en toda copia. Cubre configuración de PVE, red, SSH, kernel, apt, herramientas ProxMenux y otras. Está definido en el código y se documenta en la página <em>Cómo funciona</em>."
+          "def": "Conjunto curado de rutas que ProxMenux copia por defecto en todo backup. Cubre configuración de PVE, red, SSH, kernel, apt, herramientas ProxMenux y otras. Está definido en el código y se documenta en la página <em>Cómo funciona</em>."
         },
         {
           "id": "rutas-personalizadas",
@@ -107,22 +100,22 @@
     },
     {
       "title": "Destinos y almacenamiento",
-      "intro": "Términos ligados al lugar donde acaba la copia — servidor PBS, archivo local o repositorio Borg — y a la forma en que PBS organiza los datos.",
+      "intro": "Términos ligados al lugar donde acaba el backup — servidor PBS, archivo local o repositorio Borg — y a la forma en que PBS organiza los datos.",
       "entries": [
         {
           "id": "repositorio-pbs",
           "term": "Repositorio PBS",
-          "def": "Combinación de servidor Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + usuario al que se suben las copias. Se identifica con el formato <code>user@realm@host:datastore</code>. Un mismo servidor PBS puede alojar varios repositorios."
+          "def": "Combinación de servidor Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + usuario al que se suben los backups. Se identifica con el formato <code>user@realm@host:datastore</code>. Un mismo servidor PBS puede alojar varios repositorios."
         },
         {
           "id": "datastore",
           "term": "Datastore",
-          "def": "Almacén concreto dentro de un servidor PBS donde se guardan las copias y sus chunks. Cada datastore vive sobre un sistema de ficheros del servidor PBS y tiene sus propios permisos y políticas."
+          "def": "Almacén concreto dentro de un servidor PBS donde se guardan los backups y sus chunks. Cada datastore vive sobre un sistema de ficheros del servidor PBS y tiene sus propios permisos y políticas."
         },
         {
           "id": "chunk",
           "term": "Chunk / deduplicación por chunks",
-          "def": "PBS divide cada copia en trozos (chunks) de tamaño variable, identifica cada trozo por su hash y solo guarda cada trozo una vez, aunque aparezca en muchas copias distintas. Esto hace que copias sucesivas del mismo host o entre hosts similares consuman muy poco espacio adicional."
+          "def": "PBS divide cada backup en trozos (chunks) de tamaño variable, identifica cada trozo por su hash y solo guarda cada trozo una vez, aunque aparezca en muchos backups distintos. Esto hace que backups sucesivos del mismo host o entre hosts similares consuman muy poco espacio adicional."
         },
         {
           "id": "fingerprint",
@@ -131,13 +124,13 @@
         },
         {
           "id": "grupo-copia",
-          "term": "Grupo de copia (backup group)",
-          "def": "Contenedor lógico dentro de PBS bajo el cual se acumulan todas las copias sucesivas del mismo activo. Cada nueva copia comparte deduplicación con las anteriores del mismo grupo. ProxMenux utiliza dos grupos por host cuando hay cifrado: uno para la copia del host y otro con sufijo <code>-keyrecovery</code> para el <a href=\"#sobre-recuperacion\">sobre de recuperación</a>."
+          "term": "Grupo de backup (backup group)",
+          "def": "Contenedor lógico dentro de PBS bajo el cual se acumulan todos los backups sucesivos del mismo activo. Cada nuevo backup comparte deduplicación con los anteriores del mismo grupo. ProxMenux utiliza dos grupos por host cuando hay cifrado: uno para el backup del host y otro con sufijo <code>-keyrecovery</code> para el <a href=\"#sobre-recuperacion\">sobre de recuperación</a>."
         },
         {
           "id": "backup-id",
           "term": "Backup ID",
-          "def": "Nombre del <a href=\"#grupo-copia\">grupo de copia</a>. ProxMenux propone por defecto <code>hostcfg-HOSTNAME</code> y permite editarlo antes de la subida; los caracteres no admitidos se limpian automáticamente."
+          "def": "Nombre del <a href=\"#grupo-copia\">grupo de backup</a>. ProxMenux propone por defecto <code>hostcfg-HOSTNAME</code> y permite editarlo antes de la subida; los caracteres no admitidos se limpian automáticamente."
         },
         {
           "id": "pxar",
@@ -153,17 +146,17 @@
         {
           "id": "runner",
           "term": "Runner",
-          "def": "Script <code>run_scheduled_backup.sh</code> que ejecuta una copia programada. Lee la configuración del trabajo, lanza el backend correspondiente (Local, PBS o Borg), aplica la retención al terminar y envía las notificaciones configuradas."
+          "def": "Script <code>run_scheduled_backup.sh</code> que ejecuta un backup programado. Lee la configuración del trabajo, lanza el backend correspondiente (Local, PBS o Borg), aplica la retención al terminar y envía las notificaciones configuradas."
         },
         {
           "id": "trabajo-programado",
           "term": "Trabajo programado",
-          "def": "Configuración persistida de una copia recurrente. Incluye destino, credenciales, cifrado, horario y retención. Se guarda en <code>/var/lib/proxmenux/backup-jobs/&lt;id&gt;.env</code>."
+          "def": "Configuración persistida de un backup recurrente. Incluye destino, credenciales, cifrado, horario y retención. Se guarda en <code>/var/lib/proxmenux/backup-jobs/&lt;id&gt;.env</code>."
         },
         {
           "id": "modo-adjunto",
           "term": "Modo adjunto (attach mode)",
-          "def": "Trabajo programado que no lleva horario propio; se dispara automáticamente cada vez que una tarea <code>vzdump</code> de PVE existente se ejecuta. Hereda el horario y la retención de esa tarea padre. Solo compatible con destinos Local y PBS."
+          "def": "Trabajo sin timer propio. Un hook job-end de <code>vzdump</code> lo ejecuta después de los backups de invitados cuando coincide el almacenamiento. El padre seleccionado aporta el destino y la retención, que se vuelve a leer de la tarea padre en cada ejecución, pero el hook compara almacenamiento, no ID de tarea padre; otra tarea con el mismo destino también puede activarlo. Solo para Local y PBS."
         },
         {
           "id": "timer-systemd",
@@ -173,7 +166,7 @@
         {
           "id": "retencion",
           "term": "Retención (keep-last, keep-daily…)",
-          "def": "Política que decide qué copias antiguas se conservan y cuáles se eliminan. Se define por trabajo con parámetros como <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. El runner la aplica después de cada copia exitosa."
+          "def": "Política que decide qué backups antiguos se conservan y cuáles se eliminan. Se define por trabajo con parámetros como <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. El runner la aplica después de cada backup exitoso."
         }
       ]
     },
@@ -189,7 +182,7 @@
         {
           "id": "hidratacion",
           "term": "Hidratación (cross-kernel)",
-          "def": "Pasada de restauración que funde la configuración propia del usuario del origen (tokens IOMMU, IDs de dispositivos VFIO, quirks personalizadas, claves de GRUB) sobre la configuración de arranque fresca del destino, sin copiar verbatim los ficheros ligados al kernel del origen. Se ejecuta cuando el kernel del destino es más reciente que el de la copia."
+          "def": "Pasada de restauración que funde la configuración propia del usuario del origen (tokens IOMMU, IDs de dispositivos VFIO, quirks personalizadas, claves de GRUB) sobre la configuración de arranque fresca del destino, sin copiar verbatim los ficheros ligados al kernel del origen. Se ejecuta cuando el kernel del destino es más reciente que el del backup."
         },
         {
           "id": "cross-kernel",
@@ -209,8 +202,7 @@
         {
           "id": "equipo-recien-instalado",
           "term": "Equipo recién instalado",
-          "also": "fresh install",
-          "def": "Host acabado de reinstalar desde cero, sin la <a href=\"#clave-cifrado\">clave de cifrado</a> local. Para restaurar copias cifradas hace falta primero recuperar la clave desde el <a href=\"#sobre-recuperacion\">sobre</a> almacenado en PBS, con la <a href=\"#passphrase-recuperacion\">passphrase de recuperación</a>."
+          "def": "Host acabado de reinstalar desde cero, sin la <a href=\"#clave-cifrado\">clave de cifrado</a> local. Para restaurar backups cifrados hace falta primero recuperar la clave desde el <a href=\"#sobre-recuperacion\">sobre</a> almacenado en PBS, con la <a href=\"#passphrase-recuperacion\">passphrase de recuperación</a>."
         }
       ]
     }
@@ -221,7 +213,7 @@
       {
         "label": "Cómo funciona",
         "href": "/docs/backup-restore/how-it-works",
-        "tail": " — dónde encajan el rootfs, el manifiesto y el inventario de aplicaciones en cada copia."
+        "tail": " — dónde encajan el rootfs, el manifiesto y el inventario de aplicaciones en cada backup."
       },
       {
         "label": "Destino Proxmox Backup Server",

web/messages/es/docs/backup-restore/how-it-works.json

@@ -1,38 +1,38 @@
 {
   "meta": {
     "title": "Cómo funciona ProxMenux Backup por dentro — rootfs, manifiesto, aplicaciones",
-    "description": "Desglose detallado del contenido de una copia de ProxMenux: el rootfs producido por rsync del perfil de rutas por defecto, el manifiesto estructurado construido por seis colectores independientes, y el inventario de aplicaciones que dirige la reinstalación automática de paquetes y componentes tras una restauración.",
+    "description": "Desglose detallado del contenido de un backup de ProxMenux: el rootfs producido por rsync del perfil de rutas por defecto, el manifiesto estructurado construido por seis colectores independientes, y el inventario de aplicaciones que dirige la reinstalación automática de paquetes y componentes tras una restauración.",
     "ogTitle": "Cómo funciona ProxMenux Backup por dentro",
-    "ogDescription": "Los tres bloques de una copia de ProxMenux explicados: rootfs, manifiesto y aplicaciones.",
+    "ogDescription": "Los tres bloques de un backup de ProxMenux explicados: rootfs, manifiesto y aplicaciones.",
     "twitterTitle": "Cómo funciona ProxMenux Backup | ProxMenux",
-    "twitterDescription": "Los tres bloques de una copia de ProxMenux y cómo la restauración reproduce el host de origen a partir de ellos."
+    "twitterDescription": "Los tres bloques de un backup de ProxMenux y cómo la restauración reproduce el host de origen a partir de ellos."
   },
   "header": {
     "title": "Cómo funciona",
-    "description": "Desglose interno de una copia de seguridad creada con ProxMenux — sistema de ficheros, manifiesto e inventario de aplicaciones — y cómo la restauración consume los tres para reproducir el host de origen sobre un destino que puede no compartir el mismo kernel.",
+    "description": "Desglose interno de un backup creado con ProxMenux — sistema de ficheros, manifiesto e inventario de aplicaciones — y cómo la restauración consume los tres para reproducir el host de origen sobre un destino que puede no compartir el mismo kernel.",
     "section": "Backup & Restore"
   },
   "intro": {
     "title": "Un archivo, tres bloques",
-    "body": "Cada copia produce un layout de directorio con tres bloques bien definidos bajo una única raíz de staging. El archivo que se sube al destino (archivo local <code>.tar.zst</code>, backup PBS o archivo Borg) contiene ese layout exacto. La restauración lee los tres bloques de forma independiente, en un orden concreto que garantiza la corrección: primero se copia el <strong>rootfs</strong> —el sistema de archivos raíz del host— para colocar la configuración, después se consulta <strong>el manifiesto</strong> para detectar drift y decidir qué omitir, y finalmente <strong>el inventario de aplicaciones</strong> dirige la pasada de reinstalación post-arranque. No hay dependencias entre bloques — cada uno puede inspeccionarse o extraerse de forma independiente."
+    "body": "Cada backup produce una estructura con tres bloques definidos bajo un único directorio de preparación. El archivo subido al destino (<code>.tar.zst</code> local, backup PBS o archivo Borg) contiene esa misma estructura. La restauración utiliza los tres: consulta <strong>el manifiesto</strong> antes de aplicar cambios para detectar diferencias y decidir qué omitir; <strong>rootfs</strong> aporta los archivos de configuración, que se aplican en vivo o tras el reinicio; y <strong>el inventario de aplicaciones</strong> dirige la instalación de paquetes y la reinstalación de componentes después del arranque. Cada bloque puede inspeccionarse o extraerse de forma independiente."
   },
   "layout": {
     "heading": "Layout del archivo",
-    "intro": "Cada archivo respeta el mismo layout con independencia del destino. El subdirectorio <code>metadata/</code> contiene los bloques estructurados; el subdirectorio <code>rootfs/</code> contiene la copia del sistema de ficheros.",
-    "treeCaption": "El directorio de staging generado durante una copia. Todos los destinos reciben el mismo árbol (adaptado a su formato nativo: tar para local, chunks PBS para PBS, segmentos borg para Borg).",
+    "intro": "Cada archivo respeta el mismo layout con independencia del destino. El subdirectorio <code>metadata/</code> contiene los bloques estructurados; el subdirectorio <code>rootfs/</code> contiene el backup del sistema de ficheros.",
+    "treeCaption": "El directorio de staging generado durante un backup. Todos los destinos reciben el mismo árbol (adaptado a su formato nativo: tar para local, chunks PBS para PBS, segmentos borg para Borg).",
     "tree": "backup-[timestamp]/\n├── manifest.json                  # estado estructurado del host\n├── metadata/\n│   ├── packages.manual.list       # apt-mark showmanual\n│   ├── run_info.env               # identidad de la ejecución + versión del kernel + método pmxcfs\n│   ├── paths_archived.txt         # lista exacta de rutas que llegaron a rootfs/\n│   └── missing_paths.txt          # rutas del perfil ausentes en el origen\n└── rootfs/\n    ├── etc/                       # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, …\n    ├── root/                      # /root (con subdirs volátiles excluidos)\n    ├── usr/local/                 # /usr/local/bin, /usr/local/share/proxmenux, …\n    └── var/                       # /var/lib/pve-cluster (config.db vía sqlite3 .backup), /var/spool/cron/…"
   },
   "rootfs": {
     "heading": "El bloque rootfs",
-    "intro": "El árbol <code>rootfs/</code> es una <strong>copia plana del sistema de ficheros</strong> producida por <code>rsync</code> desde el host de origen. Contiene un <strong>perfil por defecto</strong> curado de rutas que importan para una restauración de Proxmox, más cualquier <strong>ruta personalizada</strong> añadida por el usuario al trabajo de copia o a la sesión interactiva. El conjunto es intencionadamente estrecho: solamente rutas que <em>contienen configuración</em> o <em>contienen estado que Proxmox no puede regenerar por sí solo</em>.",
+    "intro": "El árbol <code>rootfs/</code> es una <strong>copia plana del sistema de ficheros</strong> producida por <code>rsync</code> desde el host de origen. Contiene un <strong>perfil por defecto</strong> curado de rutas que importan para una restauración de Proxmox, más cualquier <strong>ruta personalizada</strong> añadida por el usuario al trabajo de backup o a la sesión interactiva. El conjunto es intencionadamente estrecho: solamente rutas que <em>contienen configuración</em> o <em>contienen estado que Proxmox no puede regenerar por sí solo</em>.",
     "defaultProfileTitle": "El perfil por defecto",
-    "defaultProfileBody": "El perfil por defecto está definido por <code>hb_default_profile_paths</code> en <code>lib_host_backup_common.sh</code>. Cubre ocho categorías que en conjunto describen un host Proxmox operativo:",
+    "defaultProfileBody": "El perfil por defecto se define en <code>hb_default_profile_paths</code> de <code>lib_host_backup_common.sh</code>. Incluye ocho categorías fijas y, si corresponde, el estado ZFS, que juntas describen un host Proxmox operativo:",
     "categoriesTitle": "Categorías de rutas",
     "categoryRows": [
       {
         "category": "Núcleo PVE",
         "paths": "/etc/pve, /var/lib/pve-cluster, /etc/vzdump.conf",
-        "why": "Contenido del filesystem del clúster y valores por defecto de vzdump. La base pmxcfs (<code>config.db</code>) se captura con un snapshot consistente vía <code>sqlite3 .backup</code> sin parar el clúster, y los sidecars <code>.db-wal</code> y <code>.db-shm</code> quedan excluidos del rsync. Si <code>sqlite3</code> no está disponible, la copia deposita un <code>config.db.raw-fallback</code> que la restauración promociona automáticamente."
+        "why": "Contenido del filesystem del clúster y valores por defecto de vzdump. La base pmxcfs (<code>config.db</code>) se captura con un snapshot consistente vía <code>sqlite3 .backup</code> sin parar el clúster, y los sidecars <code>.db-wal</code> y <code>.db-shm</code> quedan excluidos del rsync. Si <code>sqlite3</code> no está disponible, el backup deposita un <code>config.db.raw-fallback</code> que la restauración promociona automáticamente."
       },
       {
         "category": "Identidad del host y red",
@@ -62,12 +62,12 @@
       {
         "category": "Estado ProxMenux y herramientas",
         "paths": "/etc/proxmenux, /etc/systemd/system, /etc/log2ram.conf, /etc/logrotate.conf, /etc/logrotate.d, /etc/lm-sensors, /etc/sensors3.conf, /etc/fail2ban, /etc/snmp, /etc/postfix, /etc/wireguard, /etc/openvpn, /etc/grafana, /etc/influxdb, /etc/prometheus, /etc/telegraf, /etc/zabbix",
-        "why": "Herramientas opcionales pero habituales de Proxmox. Las rutas ausentes se registran en <code>metadata/missing_paths.txt</code> sin detener la copia."
+        "why": "Herramientas opcionales pero habituales de Proxmox. Las rutas ausentes se registran en <code>metadata/missing_paths.txt</code> sin detener el backup."
       },
       {
         "category": "Binarios ProxMenux y root",
         "paths": "/usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux, /var/lib/proxmenux, /root (subdirs volátiles excluidos)",
-        "why": "Binarios instalados por ProxMenux y configuración por usuario bajo <code>/root</code>. Las rutas volátiles (<code>.bash_history</code>, <code>.cache/</code>, <code>tmp/</code>, <code>.local/share/Trash/</code>) quedan fuera de la copia. <code>/var/lib/proxmenux</code> guarda los trabajos de backup programados y el estado del host que mantiene ProxMenux; quedan fuera la preparación de una restauración, las copias de rollback y las marcas posteriores a la restauración, porque pertenecen al host que la ejecuta."
+        "why": "Binarios instalados por ProxMenux y configuración por usuario bajo <code>/root</code>. Las rutas volátiles (<code>.bash_history</code>, <code>.cache/</code>, <code>tmp/</code>, <code>.local/share/Trash/</code>) quedan fuera del backup. <code>/var/lib/proxmenux</code> guarda los trabajos de backup programados y el estado del host que mantiene ProxMenux; quedan fuera la preparación de una restauración, los backups de rollback y las marcas posteriores a la restauración, porque pertenecen al host que la ejecuta."
       },
       {
         "category": "Estado ZFS (condicional)",
@@ -76,18 +76,18 @@
       }
     ],
     "customTitle": "Ampliar el perfil con rutas propias",
-    "customBody": "Además del perfil por defecto, ProxMenux ofrece dos maneras de incluir rutas adicionales en una copia. Se combinan sin conflicto y ambas se aplican tanto a copias interactivas como a trabajos programados.",
+    "customBody": "Además del perfil por defecto, ProxMenux ofrece dos maneras de incluir rutas adicionales en un backup. Se combinan sin conflicto y ambas se aplican tanto a backups interactivos como a trabajos programados.",
     "customExtrasTitle": "1. Extras persistentes (fichero por-host)",
-    "customExtrasBody": "Un fichero de texto en <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code> guarda una lista de rutas absolutas que el usuario ha marcado como \"incluir siempre\" en este host. Cuando una copia se ejecuta en modo <strong>Default</strong>, ProxMenux añade automáticamente estas rutas al perfil por defecto sin preguntar. El fichero se edita desde la interfaz — no hay que tocarlo a mano — y persiste entre reinicios y actualizaciones. Cada línea es una ruta absoluta; se admiten comentarios con <code>#</code>.",
+    "customExtrasBody": "Un fichero de texto en <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code> guarda una lista de rutas absolutas que el usuario ha marcado como \"incluir siempre\" en este host. Cuando un backup se ejecuta en modo <strong>Default</strong>, ProxMenux añade automáticamente estas rutas al perfil por defecto sin preguntar. El fichero se edita desde la interfaz — no hay que tocarlo a mano — y persiste entre reinicios y actualizaciones. Cada línea es una ruta absoluta; se admiten comentarios con <code>#</code>.",
     "customModeTitle": "2. Modo Custom (por ejecución)",
-    "customModeBody": "Al lanzar una copia en modo <strong>Custom</strong>, en lugar de aplicar el perfil por defecto directamente, se muestra un checklist con todas las rutas: las del perfil por defecto y las de extras persistentes (estas últimas premarcadas con <code>[+]</code>). El usuario marca o desmarca lo que quiera para esa ejecución concreta, y puede además pulsar <em>Add custom path</em> para introducir una ruta nueva — que queda registrada en el fichero de extras persistentes para futuras copias.",
+    "customModeBody": "Al lanzar un backup en modo <strong>Custom</strong>, en lugar de aplicar el perfil por defecto directamente, se muestra un checklist con todas las rutas: las del perfil por defecto y las de extras persistentes (estas últimas premarcadas con <code>[+]</code>). El usuario marca o desmarca lo que quiera para esa ejecución concreta, y puede además pulsar <em>Add custom path</em> para introducir una ruta nueva — que queda registrada en el fichero de extras persistentes para futuros backups.",
     "customMissingTitle": "Rutas ausentes en el origen",
-    "customMissingBody": "Cualquier ruta del perfil (por defecto o añadida) que no exista en el host de origen se registra en <code>metadata/missing_paths.txt</code> dentro del archivo. La copia no falla ni interrumpe — el usuario ve el resumen de rutas archivadas y rutas ausentes al terminar. En la práctica esto ocurre con las rutas de herramientas opcionales como <code>/etc/wireguard</code> o <code>/etc/prometheus</code> cuando esas herramientas no están instaladas."
+    "customMissingBody": "Cualquier ruta del perfil (por defecto o añadida) que no exista en el host de origen se registra en <code>metadata/missing_paths.txt</code> dentro del archivo. El backup no falla ni interrumpe — el usuario ve el resumen de rutas archivadas y rutas ausentes al terminar. En la práctica esto ocurre con las rutas de herramientas opcionales como <code>/etc/wireguard</code> o <code>/etc/prometheus</code> cuando esas herramientas no están instaladas."
   },
   "manifest": {
     "heading": "El bloque manifiesto",
-    "intro": "<code>manifest.json</code> es un documento JSON estructurado que describe el host de origen en el momento de la copia. Se produce mediante <strong>seis colectores independientes</strong> orquestados por <code>build_manifest.sh</code>. Cada colector es de sólo lectura, produce un fragmento JSON bien definido y hace fallback a un valor vacío seguro si falla — el manifiesto sigue siendo utilizable aunque una sección quede incompleta.",
-    "orchestratorCaption": "Los seis colectores componen el manifiesto. Cada uno corre en su propio subproceso; un fallo en uno hace fallback al valor por defecto documentado y advierte, pero no aborta la copia.",
+    "intro": "<code>manifest.json</code> es un documento JSON estructurado que describe el host de origen en el momento del backup. Se produce mediante <strong>seis colectores independientes</strong> orquestados por <code>build_manifest.sh</code>. Cada colector es de sólo lectura, produce un fragmento JSON bien definido y hace fallback a un valor vacío seguro si falla — el manifiesto sigue siendo utilizable aunque una sección quede incompleta.",
+    "orchestratorCaption": "Los seis colectores componen el manifiesto. Cada uno corre en su propio subproceso; un fallo en uno hace fallback al valor por defecto documentado y advierte, pero no aborta el backup.",
     "collectorRows": [
       {
         "collector": "collect_source_host.sh",
@@ -117,7 +117,7 @@
       {
         "collector": "collect_guests.sh",
         "produces": "vms_lxcs_at_backup",
-        "content": "Enumera VMs (<code>qm list</code>) y LXCs (<code>pct list</code>) presentes en el momento de la copia — VMID, nombre, estado actual. Sólo el inventario: los datos reales del invitado son responsabilidad de <code>vzdump</code> / PBS."
+        "content": "Enumera VMs (<code>qm list</code>) y LXCs (<code>pct list</code>) presentes en el momento del backup — VMID, nombre, estado actual. Sólo el inventario: los datos reales del invitado son responsabilidad de <code>vzdump</code> / PBS."
       }
     ],
     "schemaTitle": "Validación por esquema",
@@ -125,7 +125,7 @@
   },
   "applications": {
     "heading": "El inventario de aplicaciones",
-    "intro": "Dos ficheros bajo <code>metadata/</code> catalogan todo lo instalado en el origen que no forma parte del conjunto de paquetes base de Proxmox VE. La restauración los utiliza para reproducir el conjunto exacto de software instalado por el usuario en el destino, usando APT o los instaladores propios de ProxMenux según cómo se instalara originalmente el software.",
+    "intro": "Dos inventarios registran el software añadido al conjunto base de Proxmox VE: la lista de paquetes en <code>metadata/</code> y el registro de componentes dentro de rootfs, detallados a continuación. La restauración los usa para reproducir el software del usuario con APT o los instaladores de ProxMenux, según cómo se instalara originalmente.",
     "packagesTitle": "packages.manual.list",
     "packagesBody": "Una lista de texto plano producida por <code>apt-mark showmanual</code>: todos los paquetes APT que fueron <em>instalados explícitamente</em> en el host de origen, ordenados alfabéticamente. Esto excluye los paquetes instalados como dependencias del ISO base de Proxmox VE (que APT del destino vuelve a traer automáticamente). Es leída por <code>_rs_run_complete_extras</code> durante la restauración, filtrada por un filtro <em>cascade-safe</em> de tres pases (<code>dpkg -s</code> para lo ya instalado, detección de sibling-major para librerías, <code>apt-get install --simulate</code> para riesgo de cascade-remove) y después instalada con <code>apt-get install -y</code>.",
     "componentsTitle": "components_status.json (parte del rootfs)",

web/messages/es/docs/backup-restore/index.json

@@ -1,20 +1,20 @@
 {
   "meta": {
-    "title": "ProxMenux Backup & Restore — Descripción general | Copia y restauración completa del host Proxmox VE",
-    "description": "ProxMenux Backup & Restore captura el estado completo de un host Proxmox — sistema de ficheros, manifiesto estructurado de configuración y paquetes/componentes instalados — y lo reproduce en el mismo host o en uno distinto. La copia y la restauración son autocontenidas: sin dependencias externas, y con soporte para restauraciones cross-kernel mediante un filtro direccional de subconjunto seguro y una hidratación kernel-agnóstica.",
+    "title": "ProxMenux Backup & Restore — Descripción general | Backup y restauración completa del host Proxmox VE",
+    "description": "ProxMenux Backup & Restore captura el estado completo de un host Proxmox — sistema de ficheros, manifiesto estructurado de configuración y paquetes/componentes instalados — y lo reproduce en el mismo host o en uno distinto. El backup y la restauración son autocontenidos: sin dependencias externas, y con soporte para restauraciones cross-kernel mediante un filtro direccional de subconjunto seguro y una hidratación kernel-agnóstica.",
     "ogTitle": "ProxMenux Backup & Restore — Descripción general",
-    "ogDescription": "Copia y restauración completa del host Proxmox VE con manifiesto estructurado, lista de paquetes y reinstaladores de componentes.",
+    "ogDescription": "Backup y restauración completa del host Proxmox VE con manifiesto estructurado, lista de paquetes y reinstaladores de componentes.",
     "twitterTitle": "ProxMenux Backup & Restore | ProxMenux",
-    "twitterDescription": "Copia y restauración completa del host Proxmox VE con manifiesto estructurado, lista de paquetes y reinstaladores de componentes."
+    "twitterDescription": "Backup y restauración completa del host Proxmox VE con manifiesto estructurado, lista de paquetes y reinstaladores de componentes."
   },
   "header": {
     "title": "Backup & Restore",
-    "description": "Copia y restauración a nivel de host para Proxmox VE. Captura el sistema de ficheros, la configuración y los componentes instalados en un único archivo y reproduce el host sobre la misma instalación de Proxmox o sobre una distinta, sin dependencias externas.",
+    "description": "Backup y restauración a nivel de host para Proxmox VE. Captura el sistema de ficheros, la configuración y los componentes instalados en un único archivo y reproduce el host sobre la misma instalación de Proxmox o sobre una distinta, sin dependencias externas.",
     "section": "Backup & Restore"
   },
   "intro": {
     "title": "Qué es, en un párrafo",
-    "body": "Una copia de ProxMenux captura el estado completo de un host Proxmox: <strong>el sistema de ficheros</strong> (directorios relevantes bajo <code>/etc</code>, <code>/root</code>, <code>/var/lib/pve-cluster</code>, más rutas personalizadas opcionales), <strong>un manifiesto estructurado</strong> (JSON con el hardware detectado, los parámetros del kernel, la topología de red, el estado de ZFS, los usuarios y las entradas de cron) y <strong>un inventario de aplicaciones</strong> (todos los paquetes marcados como instalados manualmente por APT, más la lista de componentes instalados por ProxMenux con sus versiones exactas). Cualquiera de los tres destinos soportados — archivo local, Proxmox Backup Server (recomendado) o Borg — recibe el mismo contenido autocontenido, y cualquiera de ellos puede hidratar el host de destino sin depender de que el origen esté accesible en el momento de la restauración."
+    "body": "Un backup de ProxMenux captura el estado completo de un host Proxmox: <strong>el sistema de ficheros</strong> (directorios relevantes bajo <code>/etc</code>, <code>/root</code>, <code>/var/lib/pve-cluster</code>, más rutas personalizadas opcionales), <strong>un manifiesto estructurado</strong> (JSON con el hardware detectado, los parámetros del kernel, la topología de red, el estado de ZFS, los usuarios y las entradas de cron) y <strong>un inventario de aplicaciones</strong> (todos los paquetes marcados como instalados manualmente por APT, más la lista de componentes instalados por ProxMenux con sus versiones exactas). Cualquiera de los tres destinos soportados — archivo local, Proxmox Backup Server (recomendado) o Borg — recibe el mismo contenido autocontenido, y cualquiera de ellos puede hidratar el host de destino sin depender de que el origen esté accesible en el momento de la restauración."
   },
   "video": {
     "heading": "Vídeo demostración",
@@ -24,17 +24,17 @@
   },
   "whatItIsNot": {
     "heading": "Qué no es",
-    "intro": "La sección cubre copia y restauración <strong>a nivel de host</strong>: la instalación de Proxmox en sí, no las cargas de trabajo que se ejecutan sobre ella.",
+    "intro": "La sección cubre backup y restauración <strong>a nivel de host</strong>: la instalación de Proxmox en sí, no las cargas de trabajo que se ejecutan sobre ella.",
     "items": [
-      "<strong>No es una herramienta de copia de VMs/CTs.</strong> Los discos de los invitados y su estado de RAM no se capturan en esta función; para eso está <code>vzdump</code>. Los <strong>ficheros de configuración</strong> de los invitados (<code>/etc/pve/nodes/&lt;node&gt;/qemu-server/*.conf</code> y <code>lxc/*.conf</code>) <strong>sí</strong> se capturan, de modo que tras la restauración el inventario de invitados reaparece y sus discos pueden re-adjuntarse desde una copia existente de PBS o local.",
+      "<strong>No es una herramienta de backup de VMs/CTs.</strong> Los discos de los invitados y su estado de RAM no se capturan en esta función; para eso está <code>vzdump</code>. Los <strong>ficheros de configuración</strong> de los invitados (<code>/etc/pve/nodes/&lt;node&gt;/qemu-server/*.conf</code> y <code>lxc/*.conf</code>) <strong>sí</strong> se capturan, de modo que tras la restauración el inventario de invitados reaparece y sus discos pueden re-adjuntarse desde un backup existente de PBS o local.",
       "<strong>No es una operación a nivel de clúster.</strong> Cada nodo se copia a sí mismo. La pertenencia al clúster se captura como parte de <code>/etc/pve</code> para que un nodo restaurado pueda re-incorporarse al clúster, pero restaurar un clúster completo requiere coordinación por nodo.",
       "<strong>No es una imagen completa del disco.</strong> Los binarios del kernel, el initramfs y la partición de arranque no se capturan. En la restauración, ProxMenux utiliza los artefactos de arranque propios del host de destino (regenerados automáticamente por <code>update-initramfs</code> y la herramienta de bootloader) e instala los controladores adecuados contra el kernel que el destino tenga en ejecución."
     ]
   },
   "threePillars": {
-    "heading": "Los tres pilares de una copia",
+    "heading": "Los tres pilares de un backup",
     "intro": "Un archivo de ProxMenux se estructura en torno a tres cargas útiles autocontenidas. La restauración utiliza las tres en conjunto para reproducir el host de origen sobre un destino que puede no tener siquiera el mismo kernel instalado.",
-    "diagramCaption": "Cada copia contiene los mismos tres bloques con independencia del destino. La restauración los consume todos: rootfs para colocar los ficheros, manifiesto para detectar drift y diferencias cross-kernel, e inventario de aplicaciones para reinstalar paquetes y componentes contra el kernel del propio destino.",
+    "diagramCaption": "Cada backup contiene los mismos tres bloques con independencia del destino. La restauración los consume todos: rootfs para colocar los ficheros, manifiesto para detectar drift y diferencias cross-kernel, e inventario de aplicaciones para reinstalar paquetes y componentes contra el kernel del propio destino.",
     "pillar1Label": "Sistema de ficheros",
     "pillar1Detail": "rootfs/\n(rsync de /etc,\n/etc/systemd/network,\n/root, más snapshot\nsqlite3 de\n/var/lib/pve-cluster,\n+ rutas opcionales)",
     "pillar2Label": "Manifiesto",
@@ -44,11 +44,11 @@
   },
   "restoreIsUniversal": {
     "heading": "La restauración reproduce el host de origen, no el archivo",
-    "body": "Restaurar una copia de seguridad no consiste solamente en extraer el sistema de ficheros. El flujo de restauración lee el manifiesto para detectar diferencias entre origen y destino (variaciones de hardware, renombrado de NICs, versión de kernel, identidad de la pool ZFS), reproduce el sistema de ficheros y lanza el instalador correspondiente a cada servicio que estuviera instalado en el origen (controlador NVIDIA, Coral TPU, herramientas AMD GPU, herramientas Intel GPU). Cada instalador se ejecuta contra el <strong>kernel actual del destino</strong>, por lo que el host restaurado no depende de que el kernel del origen esté presente. Cuando el kernel del destino es más reciente que el de la copia, una pasada de <strong>hidratación</strong> kernel-agnóstica funde la configuración propia del usuario (tokens IOMMU, IDs de dispositivos VFIO, quirks personalizadas, claves de GRUB) sobre la configuración de arranque fresca del destino, sin copiar verbatim los ficheros ligados al kernel."
+    "body": "Restaurar un backup no consiste solamente en extraer el sistema de ficheros. El flujo de restauración lee el manifiesto para detectar diferencias entre origen y destino (variaciones de hardware, renombrado de NICs, versión de kernel, identidad de la pool ZFS), reproduce el sistema de ficheros y lanza el instalador correspondiente a cada servicio que estuviera instalado en el origen (controlador NVIDIA, Coral TPU, herramientas AMD GPU, herramientas Intel GPU). Cada instalador se ejecuta contra el <strong>kernel actual del destino</strong>, por lo que el host restaurado no depende de que el kernel del origen esté presente. Cuando el kernel del destino es más reciente que el del backup, una pasada de <strong>hidratación</strong> kernel-agnóstica funde la configuración propia del usuario (tokens IOMMU, IDs de dispositivos VFIO, quirks personalizadas, claves de GRUB) sobre la configuración de arranque fresca del destino, sin copiar verbatim los ficheros ligados al kernel."
   },
   "twoInterfaces": {
     "heading": "Dos interfaces, un único backend",
-    "intro": "Cada paso del flujo de copia y restauración está disponible desde dos puntos de entrada. Ambos invocan la misma librería de shell, producen archivos idénticos y leen el mismo registro de trabajos.",
+    "intro": "Cada paso del flujo de backup y restauración está disponible desde dos puntos de entrada. Ambos invocan la misma librería de shell, producen archivos idénticos y leen el mismo registro de trabajos.",
     "cliLabel": "ProxMenux Scripts (TUI)",
     "cliDetail": "menu → Utilities →\nHost Backup / Restore\n\nFlujo basado en diálogos,\namigable por SSH, admite\nejecución desatendida\ndesde scripts.",
     "webLabel": "ProxMenux Monitor (Web UI)",
@@ -56,7 +56,7 @@
   },
   "whereNext": {
     "heading": "A dónde seguir desde aquí",
-    "intro": "Cada subsección posterior desarrolla en detalle un aspecto del flujo. Se recomienda empezar por <em>Cómo funciona</em> para entender qué contiene el archivo y por qué. Consultar <em>Destinos</em> para configurar el destino de la copia. Leer <em>Restauración</em> y <em>Restauración cross-kernel</em> para el lado de recuperación.",
+    "intro": "Cada subsección posterior desarrolla en detalle un aspecto del flujo. Se recomienda empezar por <em>Cómo funciona</em> para entender qué contiene el archivo y por qué. Consultar <em>Destinos</em> para configurar el destino del backup. Leer <em>Restauración</em> y <em>Restauración cross-kernel</em> para el lado de recuperación.",
     "items": [
       {
         "label": "Cómo funciona",
@@ -69,9 +69,9 @@
         "tail": " — comparativa entre archivo local, Proxmox Backup Server (recomendado) y Borg, y cómo configurar cada uno."
       },
       {
-        "label": "Crear copias",
+        "label": "Crear backups",
         "href": "/docs/backup-restore/creating-backups",
-        "tail": " — copias puntuales, perfil de rutas por defecto, adición de rutas personalizadas, cifrado en PBS."
+        "tail": " — backups puntuales, perfil de rutas por defecto, adición de rutas personalizadas, cifrado en PBS."
       },
       {
         "label": "Trabajos programados",
@@ -86,7 +86,7 @@
       {
         "label": "Restauración cross-kernel",
         "href": "/docs/backup-restore/cross-kernel",
-        "tail": " — comportamiento direccional cuando el kernel del destino difiere del de la copia, el filtro de subconjunto seguro y las cuatro fases de hidratación."
+        "tail": " — comportamiento direccional cuando el kernel del destino difiere del del backup, el filtro de subconjunto seguro y las cuatro fases de hidratación."
       }
     ]
   }

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

@@ -1,28 +1,28 @@
 {
   "meta": {
-    "title": "Restaurar una copia — flujos Completo y Personalizado | ProxMenux",
-    "description": "El flujo completo de restauración. Documenta las tres acciones disponibles sobre cualquier copia (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.",
+    "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 una copia | ProxMenux",
-    "twitterDescription": "Cómo se convierte una copia de host de ProxMenux en un host Proxmox operativo."
+    "twitterTitle": "Restaurar un backup | ProxMenux",
+    "twitterDescription": "Cómo se convierte un backup de host de ProxMenux en un host Proxmox operativo."
   },
   "header": {
-    "title": "Restaurar una copia",
-    "description": "El flujo completo de restauración: desde elegir una copia 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.",
+    "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 una copia de ProxMenux no es una extracción. Los ficheros son sólo el primer paso: una vez colocado el sistema de ficheros, la restauración lee el manifiesto para detectar diferencias entre origen y destino, filtra rutas que romperían el arranque del destino, hidrata configuración propia del usuario que no puede copiarse verbatim, y — tras el reinicio obligatorio — reinstala cada componente que tuviera el origen (controlador NVIDIA, Coral TPU, herramientas GPU) contra el kernel actual del destino. Lo que el usuario elige del menú es una única copia; lo que realmente sucede involucra a la comprobación de compatibilidad, la clasificación de rutas, el dispatcher post-arranque y la pasada de reinstalación trabajando juntos para producir un host que se comporta como el origen."
+    "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 una copia",
-    "intro": "Seleccionar una copia de la lista abre un menú con tres acciones.",
+    "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 la copia."
+        "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",
@@ -40,7 +40,7 @@
     "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 de la copia 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."
+        "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",
@@ -52,7 +52,7 @@
       },
       {
         "output": "Plan de rollback",
-        "detail": "Lo calcula <code>compute_rollback_plan.sh</code>. Lista las VMs, LXCs y componentes presentes en el destino pero no en la copia. El usuario puede optar durante el diálogo de confirmación por eliminarlos como parte de la restauración, de modo que el destino termine casando exactamente con la copia."
+        "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."
@@ -77,15 +77,15 @@
     "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 una copia: <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."
+        "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 se aplican <strong>de inmediato</strong> también, pero cuyo efecto real sólo se manifiesta en el <strong>siguiente arranque</strong>: el kernel sólo lee <code>/etc/default/grub</code> al iniciar el bootloader, <code>/etc/fstab</code> al montar los filesystems, <code>/etc/modules</code> al cargar módulos, etc. El fichero está en su sitio nada más aplicarse, pero el sistema tiene que reiniciar para consumirlo. 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>."
+        "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/modprobe.d</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 FUSE vivo; escribir directo en él lo saltea), <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)."
+        "detail": "Rutas que <strong>NO se aplican en el sistema en ejecución</strong>: escribirlas en caliente podría corromper el estado o cortar la conexión activa. Se preparan en el conjunto pendiente: <code>/etc/network</code> se escribe al principio del siguiente arranque, antes de que se levante la red, y <code>/etc/pve</code> lo escribe el dispatcher post-arranque cuando el sistema de archivos del clúster ya está activo. Ejemplos: <code>/etc/pve</code> (pmxcfs es un montaje FUSE con la configuración activa del clúster), <code>/var/lib/pve-cluster</code> (datos vivos del clúster; se guardan en el directorio de recuperación solo para recuperarlos a mano), <code>/etc/network</code> (podría reconfigurar la misma interfaz por la que el usuario está conectado por SSH y cortar la sesión)."
       }
     ]
   },
@@ -131,7 +131,7 @@
       },
       {
         "task": "Reinstalación de componentes",
-        "detail": "Lee el <code>components_status.json</code> restaurado e itera sobre los instaladores registrados (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Cada instalador corre en modo <code>--auto-reinstall</code>, lee su versión previamente registrada del state file, y recompila contra el kernel actual del destino. El flujo interactivo no hace esto — reinstalar drivers contra un kernel que aún no ha arrancado carece de sentido."
+        "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",
@@ -145,7 +145,7 @@
   },
   "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>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).",
+    "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",
@@ -184,9 +184,9 @@
   },
   "postbootExample": {
     "heading": "Cómo se ve el post-boot en la consola",
-    "body": "En la consola física del host la ejecución exitosa del dispatcher termina con una línea <code>[ OK ] Finished proxmenux-apply-cluster-postboot.service</code>. Cuando esa línea aparece — normalmente acompañada de los <code>OK</code> del <code>multi-user.target</code> y del <code>graphical.target</code> — la restauración ha terminado por completo: componentes reinstalados, boot artifacts regenerados, cluster reconciliado.",
+    "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 tras un post-boot exitoso. La línea 'Finished proxmenux-apply-cluster-postboot.service' es la señal de que el flujo de restauración ha terminado por completo — el mismo evento que la notificación 'Host restore finished' expone en el Monitor."
+    "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",
@@ -228,11 +228,11 @@
         "detail": "Barata. El usuario se entera de que la ejecución ha terminado en el momento en que dispara la notificación."
       }
     ],
-    "outroBody": "La ventana importa porque el usuario puede hacer login durante este tiempo y ver herramientas ausentes (<code>nvidia-smi</code> no encontrado, <code>coral</code> no detectado). Es esperado — la reinstalación sigue corriendo en background. La notificación de finalización señala cuando todo está listo."
+    "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": "Una restauración es aditiva por defecto: si el destino tiene VMs, LXCs o componentes que no están en la copia, sobreviven. Esto preserva el trabajo pero puede dejar entradas hostpci obsoletas, componentes huérfanos o VMs que el usuario ya no quiere. Cuando se detecta drift entre destino y copia, el diálogo de confirmación ofrece un segundo yes/no: <em>¿Ejecutar rollback destructivo?</em>. Aceptar dispara <code>_rs_execute_rollback</code>, que elimina las VMs, LXCs y componentes que existen en el destino pero no en la copia. El rollback corre ANTES del reinicio para que la maquinaria de pending-restore vea un estado limpio. Es opt-in — el default es No, y el usuario ve exactamente qué se eliminaría listado por nombre (VMID y CTID) antes de decidir."
+    "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",
@@ -265,7 +265,7 @@
       {
         "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 de la copia."
+        "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",

web/messages/es/docs/backup-restore/scheduled-jobs.json

@@ -1,15 +1,15 @@
 {
   "meta": {
     "title": "Trabajos programados — timers, modo adjunto, retención | ProxMenux",
-    "description": "Trabajos de copia de host programados en ProxMenux. Dos modos de creación (timer systemd propio o adjuntarse a un trabajo vzdump de PVE existente), valores de retención aplicados por trabajo vía proxmox-backup-client/borg/local prune, layout de almacenamiento bajo /var/lib/proxmenux/backup-jobs, y el script runner que produce archivos idénticos al flujo interactivo.",
+    "description": "Trabajos de backup de host programados en ProxMenux. Dos modos de creación (timer systemd propio o adjuntarse a un trabajo vzdump de PVE existente), valores de retención aplicados por trabajo vía proxmox-backup-client/borg/local prune, layout de almacenamiento bajo /var/lib/proxmenux/backup-jobs, y el script runner que produce archivos idénticos al flujo interactivo.",
     "ogTitle": "ProxMenux Backup — trabajos programados",
-    "ogDescription": "Copias de host desatendidas programadas con modo adjunto, retención, y los mismos tres destinos que el flujo interactivo.",
+    "ogDescription": "Backups de host desatendidos programados con modo adjunto, retención, y los mismos tres destinos que el flujo interactivo.",
     "twitterTitle": "Trabajos programados | ProxMenux",
-    "twitterDescription": "Trabajos de copia de host desatendidos con modo adjunto y retención."
+    "twitterDescription": "Trabajos de backup de host desatendidos con modo adjunto y retención."
   },
   "header": {
     "title": "Trabajos programados",
-    "description": "Trabajos de copia de host desatendidos. Dos modelos de creación: un trabajo nuevo e independiente con su propio horario, o un trabajo adjuntado a una tarea vzdump de PVE existente que hereda el horario y la retención de esa tarea. Ambos producen archivos idénticos al flujo interactivo.",
+    "description": "Trabajos de backup de host desatendidos. Dos modelos de creación: un trabajo nuevo e independiente con su propio horario, o un trabajo adjuntado a una tarea vzdump de PVE existente que hereda el horario y la retención de esa tarea. Ambos producen archivos idénticos al flujo interactivo.",
     "section": "Backup & Restore"
   },
   "intro": {
@@ -22,11 +22,11 @@
   },
   "attachBadge": {
     "title": "Modo adjunto — recomendado cuando ya existe una tarea vzdump de PVE",
-    "body": "Cuando ya hay una tarea de copia vzdump de PVE configurada para las VMs y los LXCs de este nodo, adjuntar la copia de host a esa tarea garantiza que la configuración del host se captura en la <strong>misma ventana</strong> que los invitados. En la restauración, las configuraciones de los invitados vienen de la copia de host (viven bajo <code>/etc/pve</code>), y los discos de los invitados vienen de la copia vzdump tomada al mismo tiempo — ambos conjuntos son consistentes entre sí, por lo que una recuperación completa del nodo puede reproducir el host y re-adjuntar cada invitado sin drift de versiones."
+    "body": "Si ya existe una tarea vzdump de PVE para las VM y los LXC de este nodo, adjuntar el backup del host hace que se ejecute después del backup de los invitados, en el <strong>mismo ciclo de backup</strong>. Al restaurar, las configuraciones de los invitados proceden del backup del host (bajo <code>/etc/pve</code>) y sus discos de los backups vzdump de ese ciclo. Esto facilita coordinar la recuperación de todo el nodo, pero no es un snapshot atómico: los cambios durante el ciclo pueden dejar diferencias entre la configuración del host y el estado de los discos de los invitados."
   },
   "frequencyBadge": {
     "title": "Frecuencia recomendada",
-    "body": "Para garantizar la máxima compatibilidad entre la copia y su posterior restauración se recomienda hacer copias de seguridad del host con frecuencia. Cuanto más reciente sea la copia respecto al estado actual del host, menor será la desviación de configuración, paquetes y componentes que la restauración tendrá que reconciliar."
+    "body": "Para garantizar la máxima compatibilidad entre el backup y su posterior restauración se recomienda hacer backups del host con frecuencia. Cuanto más reciente sea el backup respecto al estado actual del host, menor será la desviación de configuración, paquetes y componentes que la restauración tendrá que reconciliar."
   },
   "modes": {
     "heading": "Los dos modos",
@@ -35,7 +35,7 @@
         "mode": "Nuevo trabajo programado",
         "backends": "Local, PBS, Borg",
         "schedule": "Expresión <code>OnCalendar</code> propia (sintaxis de calendario systemd — por ejemplo <code>daily</code>, <code>Mon..Fri 03:00</code>).",
-        "retention": "Se pregunta por separado: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. La aplica el runner tras cada copia exitosa."
+        "retention": "Se pregunta por separado: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. La aplica el runner tras cada backup exitoso."
       },
       {
         "mode": "Adjuntar a un trabajo vzdump de PVE",
@@ -47,7 +47,7 @@
   },
   "attachDetail": {
     "heading": "Cómo funciona el modo adjunto",
-    "intro": "PVE escribe las tareas <code>vzdump</code> en <code>/etc/pve/jobs.cfg</code> — una entrada por tarea, cada una apuntando a un storage donde caen los dumps de VMs y LXCs. El modo adjunto requiere que ese storage sea un backend que ProxMenux entienda (Local o PBS); cuando la tarea dispara, ProxMenux se ejecuta al mismo tiempo.",
+    "intro": "PVE guarda las tareas <code>vzdump</code> en <code>/etc/pve/jobs.cfg</code>: una sección por tarea, con el almacenamiento de los backups de VM y LXC. El modo adjunto requiere un backend compatible con ProxMenux (Local o PBS). El backup del host se ejecuta desde el hook job-end cuando termina la tarea de backup de los invitados.",
     "steps": [
       {
         "step": "1",
@@ -59,14 +59,14 @@
       },
       {
         "step": "3",
-        "detail": "<code>hb_install_vzdump_hook</code> registra un script-hook en <code>/etc/vzdump.conf</code>. Cuando PVE ejecuta cualquier tarea vzdump, el script-hook dispara; si el <code>$STOREID</code> que se le pasa coincide con el <code>PVE_STORAGE</code> de un trabajo adjuntado, el runner se invoca para ese trabajo."
+        "detail": "<code>hb_install_vzdump_hook</code> registra un hook en <code>/etc/vzdump.conf</code>. En la fase job-end de cualquier tarea vzdump, compara el <code>$STOREID</code> recibido con el <code>PVE_STORAGE</code> de cada trabajo adjunto habilitado y ejecuta el script correspondiente si coincide. La asociación se basa en el almacenamiento, no en el ID de la tarea padre seleccionada."
       },
       {
         "step": "4",
         "detail": "El archivo aterriza en el mismo storage donde los dumps de vzdump acaban de escribirse: <code>path/dump/</code> para Local, o el repositorio PBS configurado en la entrada de storage de PVE."
       }
     ],
-    "outroBody": "El modo adjunto tiene una implicación operativa: desactivar o eliminar la tarea padre de PVE también desactiva la copia de host — no hay timer propio al que recurrir. La entrada del trabajo permanece en disco para poder re-adjuntarla más tarde."
+    "outroBody": "El modo adjunto no tiene temporizador propio. Desactivar o eliminar la tarea padre seleccionada detiene ese disparador, pero otra tarea vzdump con el mismo almacenamiento aún puede activar el backup del host. Para impedirlo, desactiva o elimina el propio trabajo de ProxMenux. Al desactivarlo, su entrada sigue en disco para poder reactivarla o volver a adjuntarla."
   },
   "storageLayout": {
     "heading": "Ficheros que componen un trabajo",
@@ -94,9 +94,9 @@
     "heading": "Qué hace un trabajo cuando se dispara",
     "intro": "Cada trabajo — sea del modelo nuevo o adjunto — ejecuta la misma secuencia de tres pasos:",
     "steps": [
-      "<strong>Preparar la copia.</strong> Lee la configuración del trabajo (destino, perfil, rutas) y ensambla el árbol de la copia siguiendo exactamente el mismo procedimiento que el flujo interactivo. El resultado es el mismo archivo que produciría una copia manual con esos ajustes.",
-      "<strong>Escribir en el destino.</strong> Sube o escribe la copia al destino configurado — un archivo local <code>.tar.zst</code>, un backup PBS o un archivo Borg — usando exactamente las mismas herramientas y credenciales que utilizaría una copia manual al mismo destino.",
-      "<strong>Aplicar retención.</strong> Elimina las copias antiguas del destino conservando los valores <code>keep-last</code> / <code>keep-daily</code> / <code>keep-weekly</code> configurados en el trabajo. La poda la realiza el propio destino: PBS mantiene la cuenta en su lado, Borg ejecuta <code>borg prune</code>, y en Local ProxMenux borra los archivos que quedan fuera del <code>keep-last</code>."
+      "<strong>Preparar el backup.</strong> Lee la configuración del trabajo (destino, perfil, rutas) y ensambla el árbol del backup siguiendo exactamente el mismo procedimiento que el flujo interactivo. El resultado es el mismo archivo que produciría un backup manual con esos ajustes.",
+      "<strong>Escribir en el destino.</strong> Sube o escribe el backup al destino configurado — un archivo local <code>.tar.zst</code>, un backup PBS o un archivo Borg — usando exactamente las mismas herramientas y credenciales que utilizaría un backup manual al mismo destino.",
+      "<strong>Aplicar retención.</strong> Elimina los backups antiguos del destino conservando los valores <code>keep-last</code> / <code>keep-daily</code> / <code>keep-weekly</code> configurados en el trabajo. La poda la realiza el propio destino: PBS mantiene la cuenta en su lado, Borg ejecuta <code>borg prune</code>, y en Local ProxMenux borra los archivos que quedan fuera del <code>keep-last</code>."
     ]
   },
   "management": {
@@ -127,13 +127,13 @@
   },
   "notifications": {
     "heading": "Notificaciones",
-    "body": "Cada ejecución programada dispara los mismos eventos <code>hb_notify_lifecycle</code> que el flujo interactivo (<code>start</code>, <code>complete</code>, <code>fail</code>). Si hay canales de notificación configurados en el Monitor, los trabajos desatendidos exponen sus resultados igual que las copias manuales — un usuario no necesita revisar el log para saber si un trabajo tuvo éxito."
+    "body": "Cada ejecución programada dispara los mismos eventos <code>hb_notify_lifecycle</code> que el flujo interactivo (<code>start</code>, <code>complete</code>, <code>fail</code>). Si hay canales de notificación configurados en el Monitor, los trabajos desatendidos exponen sus resultados igual que los backups manuales — un usuario no necesita revisar el log para saber si un trabajo tuvo éxito."
   },
   "whereNext": {
     "heading": "A dónde seguir",
     "items": [
       {
-        "label": "Crear copias",
+        "label": "Crear backups",
         "href": "/docs/backup-restore/creating-backups",
         "tail": " — el flujo interactivo que comparte backend con el scheduler."
       },