update documentation

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

@@ -75,8 +75,8 @@
     "captionBorg": "Borg"
   },
   "sameArchive": {
-    "heading": "El layout del archivo no cambia con el destino",
-    "body": "Dentro de cualquiera de los tres destinos está presente el mismo layout <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> descrito en <em>Cómo funciona</em>. Un <code>.tar.zst</code> extraído de un archivo local, un <code>.pxar</code> restaurado desde PBS y un archivo Borg extraído con <code>borg extract</code> producen todos un árbol de directorios idéntico. El camino de código de la restauración (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) lee los mismos tres bloques sin saber de qué destino vienen."
+    "heading": "El contenido interno de la copia es el mismo en cualquier destino",
+    "body": "Con independencia de dónde se guarde la copia, dentro siempre están los mismos tres bloques descritos en <em>Cómo funciona</em>: el sistema de ficheros (<code>rootfs/</code>), los metadatos (<code>metadata/</code>) y el manifiesto (<code>manifest.json</code>). Al extraer una copia local <code>.tar.zst</code>, restaurar un archivo <code>.pxar</code> desde PBS o descomprimir un archivo Borg, el árbol de directorios resultante es idéntico en los tres casos. Esto significa que el proceso de restauración lee siempre los mismos ficheros y no le importa desde qué destino provenga la copia."
   },
   "extractStandalone": {
     "heading": "Extraer una copia fuera de ProxMenux",

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

@@ -23,7 +23,7 @@
   },
   "repoSelection": {
     "heading": "Selección del repositorio",
-    "intro": "ProxMenux descubre repositorios PBS desde dos fuentes en cada copia. El usuario elige uno desde un menú unificado; la elección determina <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> y <code>HB_PBS_FINGERPRINT</code> para esa ejecución.",
+    "intro": "ProxMenux descubre repositorios PBS desde dos fuentes en cada copia. El usuario elige uno desde un menú unificado; esa elección determina, para esa ejecución concreta, contra qué servidor y datastore se envía la copia, con qué contraseña se autentica y con qué huella (<em>fingerprint</em>) valida el certificado.",
     "sourceRows": [
       {
         "source": "storage.cfg de Proxmox (auto-descubierto)",
@@ -45,30 +45,33 @@
     "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.",
-    "pxarTitle": "Por qué el origen es la raíz de staging completa",
-    "pxarBody": "El origen del <code>.pxar</code> es la <code>staging_root</code> entera — <code>rootfs/</code>, <code>metadata/</code> y <code>manifest.json</code> juntos. Versiones anteriores pasaban <code>$staging_root/rootfs</code> como origen; eso dejaba <code>metadata/</code> fuera del archivo y el chequeo de compatibilidad de la restauración no tenía nada que leer, degradándose a avisos cross-host incluso en restauraciones al mismo host. Los backups antiguos creados con el origen rootfs-only siguen restaurándose correctamente gracias a la rama caso-3 de <code>_rs_check_layout</code>, que envuelve un árbol plano <code>etc/var/root/usr</code> de vuelta en una jerarquía <code>rootfs/</code>."
+    "pxarTitle": "Qué se incluye dentro del archivo .pxar",
+    "pxarBody": "Al construir el archivo <code>.pxar</code> se empaqueta el directorio de trabajo completo: el sistema de ficheros del host (<code>rootfs/</code>), los metadatos (<code>metadata/</code>) y el manifiesto (<code>manifest.json</code>). Al restaurar, ProxMenux compara la información del manifiesto con la del host destino para detectar si son equivalentes, si cambia el hardware o si se trata de un equipo distinto, y ajustar el proceso en consecuencia. Las copias antiguas —hechas con versiones anteriores de ProxMenux que empaquetaban solo el sistema de ficheros— siguen restaurándose sin problema: el flujo de restauración detecta ese formato heredado y lo reorganiza automáticamente."
   },
   "encryption": {
     "heading": "Cifrado del lado del cliente",
-    "intro": "El cifrado por keyfile del lado del cliente de PBS cifra los chunks en el host de origen antes de la subida. ProxMenux habilita esta funcionalidad con una restricción añadida: la passphrase de recuperación es obligatoria cuando se activa el cifrado. La passphrase no protege el keyfile local; protege la copia de escrow del keyfile que ProxMenux sube a PBS para recuperación ante desastre.",
-    "keyfileTitle": "Keyfile",
-    "keyfileBody": "El diálogo de cifrado sigue un flujo yes/no en dos pasos. El primer paso pregunta si se desea cifrar el backup: <em>No</em> continúa sin cifrado; <em>Yes</em> pasa al segundo paso. El segundo paso depende de si ya hay un keyfile instalado en <code>/usr/local/share/proxmenux/pbs-key.conf</code>. Si lo hay, se reutiliza silenciosamente y el backup continúa. Si no lo hay, aparece un menú de dos opciones. <em>Generate a new keyfile</em> ejecuta <code>proxmox-backup-client key create --kdf none</code> — el keyfile resultante no lleva passphrase, así que el runner programado bajo systemd puede usarlo sin prompt interactivo. <em>Import an existing keyfile</em> toma una ruta indicada por el operador y la copia en la ubicación canónica con <code>chmod 600</code>; ProxMenux no inspecciona el contenido (cualquier keyfile que el operador acepte como válido en su PBS se acepta aquí, incluyendo keyfiles cifrados con scrypt que no podrían validarse de forma no interactiva). Al importar, el flujo pide también la passphrase del propio keyfile — la que <code>proxmox-backup-client key create --kdf scrypt</code> pidió al crearlo. Esa passphrase se persiste en <code>/usr/local/share/proxmenux/pbs-key.pass</code> (chmod 600) y se reutiliza en cada job cifrado del host como <code>PBS_ENCRYPTION_PASSWORD</code>. Dejarla en blanco equivale a un keyfile <code>--kdf none</code> (sin passphrase). Ambas ramas se ejecutan solo tras confirmar la passphrase de recuperación — cancelar cualquier diálogo antes de ese punto deja el disco intacto.",
+    "glossaryHint": "En esta sección aparecen los términos <em>clave</em>, <em>passphrase</em> y <em>sobre de recuperación</em>. Si en algún momento cuesta seguir cuál es cuál, el <glosarioLink>glosario</glosarioLink> resume las diferencias en una frase por término.",
+    "intro": "PBS puede cifrar las copias con una clave que reside únicamente en el host de origen: los datos se cifran en el propio host antes de subirse, y en PBS solo se guardan cifrados. Sin esa clave, las copias no pueden descifrarse. ProxMenux añade una salvaguarda: cuando se activa el cifrado obliga a definir una <strong>passphrase de recuperación</strong>. Esa passphrase no protege la clave local (que ya vive en el host), sino una copia cifrada de la clave que ProxMenux sube al propio PBS, para poder recuperarla si el host se pierde o se reinstala.",
+    "keyfileTitle": "La clave de cifrado (keyfile)",
+    "keyfileBody": "El diálogo pregunta primero si se quiere cifrar la copia. Si se responde <em>No</em>, la copia continúa sin cifrado. Si se responde <em>Sí</em>, ProxMenux comprueba si el host ya tiene una clave instalada: en ese caso la reutiliza sin más preguntas; si no la tiene, ofrece dos opciones. <em>Generar una clave nueva</em> crea una clave sin contraseña, para que las copias programadas puedan ejecutarse automáticamente sin diálogos. <em>Importar una clave existente</em> permite indicar la ruta de una clave ya generada —por ejemplo la clave común de una flota de hosts—; en ese caso el diálogo pide también la contraseña de esa clave y la guarda cifrada en el host para reutilizarla en cada copia. Cualquiera de las dos opciones se ejecuta solo después de confirmar la passphrase de recuperación; cancelar el diálogo antes de ese punto no deja nada en disco.",
     "modesTitle": "Keyfile por host o compartido",
     "modesIntro": "Ambos modelos operativos están soportados y ninguno se impone — la decisión pertenece al usuario según cómo esté organizada su flota.",
     "modesPerHostTitle": "Keyfile por host (por defecto)",
-    "modesPerHostBody": "Cada host genera su propio keyfile la primera vez que activa el cifrado PBS. El aislamiento es máximo: comprometer el keyfile de un host no expone las copias de ningún otro. Cada host tiene su propio blob de recuperación emparejado en PBS, restaurable con la passphrase de recuperación de ese host. Recomendado para flotas de producción y para entornos donde los hosts tienen propietarios o límites de compliance distintos.",
-    "modesSharedTitle": "Keyfile compartido (importar en cada host)",
-    "modesSharedBody": "Un keyfile maestro generado una vez e instalado en cada host mediante la opción <em>Importar</em>. La gestión es más simple: un único secreto que proteger, un único blob de recuperación sirve para todos los hosts, y cualquier host puede desencriptar los archives de cualquier otro (útil para consolidación, simulacros de restore cruzado o verificación centralizada de backups). El trade-off es que una filtración del keyfile compartido expone todos los hosts a la vez. Recomendado para homelabs y para flotas donde todos los hosts tienen el mismo propietario y límite de confianza.",
-    "recoveryTitle": "Passphrase de recuperación y blob de escrow",
-    "recoveryBody": "La passphrase de recuperación se solicita ANTES de escribir ningún keyfile en disco. ProxMenux la pide dos veces con validación de coincidencia; solo cuando el operador la confirma, se crea (o importa) el keyfile y <code>openssl</code> produce <code>pbs-key.recovery.enc</code> — el keyfile cifrado con la passphrase. Se escribe una copia en <code>/root/pbs-key.recovery-HOSTNAME-YYYYMMDD.enc</code> como respaldo offsite. Cancelar el diálogo de la passphrase deja el disco intacto — no se crea ningún keyfile y no hay nada que limpiar.",
+    "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. Cada host guarda además su propio sobre de recuperación en PBS, que se abre con la passphrase de recuperación de ese host. 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>Importar</em>. La gestión es más sencilla: hay un solo secreto que proteger, un solo sobre de recuperación válido para todos los hosts, y cualquier host puede leer las copias de cualquier otro (útil para verificar copias desde una máquina distinta o para ejercicios de restauración cruzada). 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": "Passphrase de recuperación y sobre cifrado",
+    "recoveryBody": "La passphrase de recuperación se pide ANTES de generar o importar ninguna clave. ProxMenux la solicita dos veces y comprueba que coincidan; solo entonces crea la clave y produce el sobre de recuperación, que consiste en la propia clave cifrada con esa passphrase. Se guarda además una copia local del sobre en <code>/root/</code>, con el nombre del host y la fecha, pensada como respaldo externo (para llevarla a otro medio). Si se cancela el diálogo de la passphrase, no se crea nada: el host queda exactamente como estaba.",
     "blobUploadTitle": "Grupo emparejado en PBS",
-    "blobUploadBody1": "Tras una copia PBS que usó el keyfile, el blob de escrow se sube como un segundo grupo de copia: <code>host/hostcfg-HOSTNAME-keyrecovery/BACKUP-TIME</code>. El prefijo compartido <code>hostcfg-HOSTNAME</code> coloca ambos grupos adyacentes en la interfaz de PBS; el sufijo <code>-keyrecovery</code> etiqueta la relación. La subida se ejecuta sin <code>--keyfile</code> (el blob ya está protegido con passphrase por openssl) y sólo cuando la copia actual usó el keyfile.",
-    "blobUploadConstraintTitle": "Por qué dos grupos",
-    "blobUploadConstraintBody": "<code>--keyfile</code> es un flag por invocación en <code>proxmox-backup-client backup</code>: todos los archivos de una misma invocación se cifran con el keyfile o ninguno. <code>hostcfg.pxar</code> requiere cifrado; <code>keyrecovery.conf</code> no puede cifrarse con el mismo keyfile (la recuperación en instalación fresca requeriría el propio keyfile que pretende recuperar). Dos invocaciones, dos backup IDs.",
+    "blobUploadBody1": "Tras una copia cifrada, ProxMenux sube el sobre de recuperación a PBS como un segundo grupo de copia, con el mismo nombre que el del host pero terminado en <code>-keyrecovery</code>. Así aparecen los dos juntos en el listado del datastore, uno con las copias del host y otro con los sobres de recuperación. <strong>El sobre nunca sale del host en claro</strong>: antes de subirse, ProxMenux lo transforma en el propio host en un fichero cifrado con AES-256-CBC, usando una clave derivada de la passphrase de recuperación mediante PBKDF2 con 600 000 iteraciones y sal aleatoria (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS recibe únicamente el sobre ya cifrado, y solo se sube cuando la copia principal ha ido cifrada.",
+    "envelopeSecurityTitle": "¿No es un riesgo subir el archivo keyrecovery a PBS?",
+    "envelopeSecurityBody": "El keyrecovery viaja y se almacena cifrado en todo momento. La passphrase de recuperación nunca abandona el host: el cifrado ocurre localmente antes de la subida y PBS solo recibe el resultado ya cifrado. Aunque un administrador de PBS —o cualquiera con acceso al datastore— descargue el keyrecovery, sin la passphrase de recuperación no puede leer la clave que contiene: son solo bytes cifrados. Para reconstruir la clave hacen falta las dos cosas al mismo tiempo, el keyrecovery y la passphrase, y solo el operador dispone de ambas.",
+    "blobUploadConstraintTitle": "Por qué dos grupos y no uno solo cifrado",
+    "blobUploadConstraintBody": "Una misma subida de <code>proxmox-backup-client backup</code> cifra todos sus archivos con la misma clave, o no cifra ninguno — no hay opción intermedia. La copia del host tiene que ir cifrada con la clave del host; el sobre de recuperación no puede ir en esa misma subida, porque quedaría cifrado con la clave que precisamente contiene: en un equipo recién reinstalado no habría manera de abrirlo (haría falta la clave para descifrar la clave). Por eso se hacen dos subidas independientes y aparecen como dos grupos separados: la copia del host va cifrada por PBS con la clave, y el sobre de recuperación va cifrado por ProxMenux con la passphrase antes de subirse. Son dos capas de cifrado distintas que protegen dos activos distintos.",
     "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 el blob de escrow.",
-    "recoverTitle": "Recuperación en instalación fresca",
-    "recoverBody": "En un host sin keyfile local, el flujo de restauración llama a <code>hb_pbs_try_keyfile_recovery</code>. La función lista los grupos keyrecovery del PBS configurado, descarga el más reciente y pregunta por la passphrase. En caso de éxito, <code>pbs-key.conf</code> se escribe en el directorio de estado de ProxMenux y la copia cifrada puede restaurarse. Sin el keyfile y la passphrase, la copia cifrada no es recuperable."
+    "recoverTitle": "Recuperación en un equipo recién instalado",
+    "recoverBody": "Si se intenta restaurar en un equipo que no tiene todavía la clave de cifrado —por ejemplo tras reinstalar el host desde cero—, ProxMenux consulta los grupos de recuperación del PBS configurado, descarga el sobre más reciente y pide la passphrase de recuperación. Al confirmarla, la clave queda instalada en el host y la copia cifrada ya puede restaurarse con normalidad. Sin la clave y sin la passphrase, la copia cifrada no puede recuperarse."
   },
   "restoreAccess": {
     "heading": "Recuperación del lado de la restauración",