mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-07-30 12:28:23 +00:00
114 lines
18 KiB
JSON
114 lines
18 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 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)",
|
|
"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": "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",
|
|
"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 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).",
|
|
"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.",
|
|
"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": "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."
|
|
},
|
|
"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."
|
|
}
|
|
]
|
|
}
|
|
}
|