mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-01 10:22:08 +00:00
- Offline checks for terminal and website catalogs reject translations that change commands, paths, identifiers or placeholders - Terminal and documentation texts that broke those contracts are corrected in every language - Swedish can be chosen in the stable and beta installers - The website routes, language switcher and exported pages cover the eight languages, with the shared website texts in each of them - Website documentation translations are generated only when requested - From PR #475 by @jcastro
114 lines
19 KiB
JSON
114 lines
19 KiB
JSON
{
|
|
"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.",
|
|
"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",
|
|
"twitterDescription": "Destino Proxmox Backup Server con cifrado por keyfile y escrow de passphrase de recuperación."
|
|
},
|
|
"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"
|
|
},
|
|
"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."
|
|
},
|
|
"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."
|
|
},
|
|
"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.",
|
|
"sourceRows": [
|
|
{
|
|
"source": "storage.cfg de Proxmox (auto-descubierto)",
|
|
"path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
|
|
"content": "Cualquier entrada <code>pbs:</code> del propio storage de Proxmox se recoge automáticamente. Servidor, datastore, usuario y fingerprint vienen de la entrada. La contraseña se lee del directorio de credenciales propio de Proxmox. Sin re-introducción por el lado de ProxMenux — el repositorio queda disponible tan pronto como se configura en Proxmox."
|
|
},
|
|
{
|
|
"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."
|
|
}
|
|
],
|
|
"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."
|
|
},
|
|
"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.",
|
|
"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": "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",
|
|
"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.",
|
|
"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/<NAME>.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.",
|
|
"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 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).",
|
|
"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.",
|
|
"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.",
|
|
"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": "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",
|
|
"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."
|
|
},
|
|
"references": {
|
|
"heading": "Referencias",
|
|
"intro": "Documentación oficial de Proxmox Backup Server para los componentes en los que se apoya ProxMenux.",
|
|
"items": [
|
|
{
|
|
"label": "Documentación de Proxmox Backup Server",
|
|
"href": "https://pbs.proxmox.com/docs/",
|
|
"tail": " — punto de entrada principal, cubre instalación, administración, almacenamiento, usuarios y roles."
|
|
},
|
|
{
|
|
"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."
|
|
},
|
|
{
|
|
"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."
|
|
},
|
|
{
|
|
"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."
|
|
},
|
|
{
|
|
"label": "Poda y recolección de basura",
|
|
"href": "https://pbs.proxmox.com/docs/maintenance.html#pruning",
|
|
"tail": " — el modelo de retención detrás de --keep-last / --keep-daily / --keep-weekly que ProxMenux aplica por trabajo programado, más cómo PBS reclama chunks tras podar."
|
|
}
|
|
]
|
|
}
|
|
}
|