mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-02 19:02:31 +00:00
docs: review backup and restore documentation in all seven translations
This commit is contained in:
Jonatan
@@ -10,7 +10,7 @@
|
||||
"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.",
|
||||
"section": "Backup & Restore"
|
||||
"section": "Copias de seguridad y restauración"
|
||||
},
|
||||
"aboutBorg": {
|
||||
"heading": "Qué es Borg",
|
||||
@@ -62,7 +62,7 @@
|
||||
},
|
||||
{
|
||||
"type": "local",
|
||||
"url": "/backup/borgbackup (cualquier ruta absoluta)",
|
||||
"url": "/backup/borgbackup (any absolute path)",
|
||||
"detail": "El repositorio vive en un directorio local. Sólo tiene sentido cuando el directorio está en un disco físico distinto — un repositorio en el mismo disco que el origen protege contra error humano pero no contra fallo de disco."
|
||||
}
|
||||
]
|
||||
@@ -78,7 +78,7 @@
|
||||
"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. Las copias 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 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; un puerto distinto del predeterminado añade -p PORT. Sin clave personalizada y con el puerto predeterminado, la variable queda sin definir y Borg usa la configuración SSH del host."
|
||||
},
|
||||
{
|
||||
"var": "BORG_PASSPHRASE",
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
"header": {
|
||||
"title": "Destinos",
|
||||
"description": "Los tres backends de almacenamiento soportados por ProxMenux Backup: archivo local, Proxmox Backup Server (recomendado) y Borg. Cada uno recibe el mismo archivo de tres bloques; se diferencian en formato de almacenamiento, deduplicación, modelo de cifrado y requisitos de red.",
|
||||
"section": "Backup & Restore"
|
||||
"section": "Copias de seguridad y restauración"
|
||||
},
|
||||
"intro": {
|
||||
"title": "El mismo contenido, tres backends",
|
||||
@@ -29,8 +29,8 @@
|
||||
{
|
||||
"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",
|
||||
@@ -69,20 +69,20 @@
|
||||
"borg": "Requiere <code>borg</code> + la ruta del repositorio + la passphrase (si está cifrado)."
|
||||
}
|
||||
],
|
||||
"captionCode": "Característica",
|
||||
"captionCode": "feature",
|
||||
"captionLocal": "Local",
|
||||
"captionPbs": "Proxmox Backup Server (recomendado)",
|
||||
"captionBorg": "Borg"
|
||||
},
|
||||
"sameArchive": {
|
||||
"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."
|
||||
"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",
|
||||
"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.",
|
||||
"localCmd": "# From a local .tar.zst archive:\ntar --zstd -xf hostcfg-HOST-TIMESTAMP.tar.zst\n\n# From a .tar.gz fallback:\ntar -xzf hostcfg-HOST-TIMESTAMP.tar.gz",
|
||||
"pbsCmd": "# From a PBS backup (requires 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# Add --keyfile KEY-PATH when the backup is encrypted.",
|
||||
"borgCmd": "# Desde un archivo Borg (requiere el binario borg + passphrase si hay cifrado):\nborg extract REPO-PATH::ARCHIVE-NAME\n\n# Sobre un repo servido por SSH:\nborg extract ssh://USER@HOST:PORT/REPO-PATH::ARCHIVE-NAME",
|
||||
"note": "El árbol extraído puede inspeccionarse manualmente o alimentar una restauración manual. Consulta las páginas de cada destino para conocer el flujo exacto de recuperación que ProxMenux utiliza por dentro."
|
||||
},
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
"header": {
|
||||
"title": "Archivo local",
|
||||
"description": "El destino local escribe un único archivo tar comprimido en cualquier directorio escribible del host: un disco interno, un montaje NFS o SMB, o una unidad USB.",
|
||||
"section": "Backup & Restore"
|
||||
"section": "Copias de seguridad y restauración"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Un solo fichero, autocontenido",
|
||||
@@ -31,17 +31,17 @@
|
||||
"statesTitle": "Los tres estados del dispositivo",
|
||||
"stateRows": [
|
||||
{
|
||||
"state": "mounted",
|
||||
"shown": "Tamaño · label · [fstype] · → /punto/de/montaje",
|
||||
"state": "montado",
|
||||
"shown": "Tamaño · etiqueta · [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."
|
||||
},
|
||||
{
|
||||
"state": "unmounted",
|
||||
"state": "sin montar",
|
||||
"shown": "Tamaño · label · [fstype] · (no montada — se montará)",
|
||||
"action": "Hay un filesystem pero no está montado. Al confirmar, ProxMenux ejecuta <code>hb_mount_usb_partition</code>: crea <code>/mnt/backup-LABEL</code> (o una ruta basada en UUID si no hay label), monta la partición y persiste el punto de montaje como destino local."
|
||||
},
|
||||
{
|
||||
"state": "empty",
|
||||
"state": "vacía",
|
||||
"shown": "Tamaño · disco USB en crudo — sin filesystem (se FORMATEARÁ)",
|
||||
"action": "El dispositivo no tiene filesystem. Camino destructivo — protegido por dos confirmaciones. Primero un diálogo Yes/No explica que la operación borrará el disco. Después una caja de entrada obliga al usuario a <strong>escribir la ruta exacta del dispositivo</strong> (por ejemplo <code>/dev/sdb</code>) antes de que ProxMenux cree una partición GPT + ext4 fresca y la monte."
|
||||
}
|
||||
@@ -50,7 +50,7 @@
|
||||
},
|
||||
"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 error 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."
|
||||
},
|
||||
"archiveFormat": {
|
||||
"heading": "Formato de archivo y compresión",
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"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 guarda las copias del host de ProxMenux como copias PBS. Explica la detección de repositorios desde /etc/pve/storage.cfg, la configuración manual, la subida de .pxar, el cifrado con archivo de clave en el cliente y su custodia opcional protegida por una frase de contraseña, y la recuperación de la clave desde varias fuentes en un host recién instalado.",
|
||||
"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",
|
||||
@@ -9,8 +9,8 @@
|
||||
},
|
||||
"header": {
|
||||
"title": "Proxmox Backup Server",
|
||||
"description": "El destino PBS sube la raíz de staging como un único backup .pxar a un datastore de Proxmox Backup Server, con cifrado opcional por keyfile del lado del cliente y escrow automático de una passphrase de recuperación para recuperación tras reinstalación.",
|
||||
"section": "Backup & Restore"
|
||||
"description": "El destino PBS sube todo el directorio de preparación como una única copia .pxar a un datastore de Proxmox Backup Server. Permite cifrarla en el cliente con un archivo de clave y, de forma opcional, subir junto a cada copia una copia de la clave protegida por una frase de contraseña para recuperarla después.",
|
||||
"section": "Copias de seguridad y restauración"
|
||||
},
|
||||
"recommendedBadge": "Destino recomendado",
|
||||
"aboutPbs": {
|
||||
@@ -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; 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.",
|
||||
"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.",
|
||||
"sourceRows": [
|
||||
{
|
||||
"source": "storage.cfg de Proxmox (auto-descubierto)",
|
||||
@@ -41,12 +41,12 @@
|
||||
},
|
||||
"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.",
|
||||
"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.",
|
||||
"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."
|
||||
"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>."
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Cifrado del lado del cliente",
|
||||
@@ -61,19 +61,19 @@
|
||||
"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.",
|
||||
"recoveryTitle": "¿Subir la clave a PBS? — el usuario decide",
|
||||
"recoveryBody": "Justo después de elegir la clave, ProxMenux pregunta si se quiere subir una copia de esa clave a PBS como red de seguridad, con dos opciones. <strong>No</strong> (por defecto) mantiene la clave solo en el host; ProxMenux no toca PBS con nada relacionado con la recuperación y el usuario gestiona por su cuenta la copia externa (desde el Monitor, la acción <em>Descargar</em> en la fila del destino PBS la exporta en el acto). <strong>Sí</strong> pide una passphrase de recuperación —dos veces, para comprobar que coincidan—; con esa passphrase, la clave se envuelve localmente con 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 copia cifrada sube también ese fichero envuelto a PBS. 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 está inline en la fila del destino PBS y el botón que aparece se adapta al estado (empezar a subir, dejar de subir, o cambiar la passphrase).",
|
||||
"recoveryBody": "Justo después de elegir la clave, ProxMenux pregunta <em>¿Subir la 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 en 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 de 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 copia cifrada posterior sube esa envoltura a PBS como un grupo de copias 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 el usuario ha respondido Sí, ProxMenux sube el sobre de recuperación a PBS después de cada copia cifrada 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 las copias del host, otro con los sobres. <strong>El sobre nunca sale del host en claro</strong>: se cifra en el 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.",
|
||||
"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.",
|
||||
"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. La copia 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 la copia 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.",
|
||||
"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/<NAME>.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.",
|
||||
"monitorManagementTitle": "Gestionar la clave desde el Monitor",
|
||||
"monitorManagementBody": "En la página de configuración de copias, la fila de cada destino PBS incluye los controles de la clave. Tres acciones directas: <em>Descargar</em> exporta la clave actual al navegador. <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 sitio). <em>Eliminar</em> retira la clave del host. Justo al lado está el interruptor del sobre de recuperación: un Sí/No para subir o no la clave a PBS, un campo de passphrase que aparece al elegir Sí, y un botón que se adapta al estado actual (empezar a subir, dejar de subir, o cambiar la passphrase). 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 la que se use."
|
||||
"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."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Recuperación del lado de la restauración",
|
||||
@@ -96,7 +96,7 @@
|
||||
{
|
||||
"label": "Cifrado del lado del cliente",
|
||||
"href": "https://pbs.proxmox.com/docs/backup-client.html#encryption",
|
||||
"tail": " — creación del keyfile, modos --kdf, el modelo de cifrado que ProxMenux extiende con un escrow de passphrase."
|
||||
"tail": " — creación del archivo de clave, modos --kdf y modelo de cifrado que ProxMenux amplía con una copia de recuperación protegida por frase de contraseña."
|
||||
},
|
||||
{
|
||||
"label": "Gestión de datastores",
|
||||
|
||||
Reference in New Issue
Block a user