docs: promote /web from develop for backup-restore, Log2RAM and Network Flow guides

Brings 69 files from develop under /web/:
- Full Backup & Restore section (11 pages EN + ES: overview, how-it-works, destinations,
  creating backups, scheduled jobs, restoring, cross-kernel hydration)
- Log2RAM dedicated block in post-install/optional with commands + upstream link
- Network Flow diagram documented on monitor/dashboard/network
- Rewritten category descriptions in post-install/customizable
- Fixed automated.json thresholds + link to Log2RAM section
- Updated screenshots (network-flow-overview, storage-top-row, vms modals)

No code, config or AppImage binaries touched — /web/ scope only. Merging deploys
the documentation site to the current beta release notes.
This commit is contained in:
MacRimi
2026-07-04 22:10:49 +02:00
parent a92420d654
commit 720f3fdbd2
69 changed files with 7246 additions and 48 deletions
@@ -0,0 +1,234 @@
{
"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.",
"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."
},
"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"
},
"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."
},
"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."
},
"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:",
"rows": [
{
"priority": "1",
"source": "<code>borg</code> del sistema",
"detail": "Si el host ya tiene <code>borg</code> instalado vía APT (<code>which borg</code> resuelve), se usa ese binario."
},
{
"priority": "2",
"source": "Caché del state-dir",
"detail": "<code>/usr/local/share/proxmenux/borg</code> — conservado de una descarga previa desde GitHub en este host."
},
{
"priority": "3",
"source": "Bundle del Monitor AppImage",
"detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> — el AppImage incluye un binario borg-linux64 firmado. Este es el camino offline-safe: un host sin internet sigue teniendo un <code>borg</code> operativo."
},
{
"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."
}
]
},
"repoTypes": {
"heading": "Tipos de repositorio",
"intro": "El tipo de repositorio se elige al añadir un destino. Cada tipo se resuelve a una URL de repositorio que Borg entiende.",
"rows": [
{
"type": "remote",
"url": "ssh://USER@HOST/RPATH",
"detail": "El repositorio vive en un servidor remoto que ejecuta <code>borg serve</code>. Requiere una conexión SSH a ese servidor."
},
{
"type": "usb",
"url": "/mnt/MOUNTPOINT/borgbackup",
"detail": "El repositorio vive en un disco externo montado (típicamente USB). El punto de montaje se resuelve vía <code>hb_prompt_mounted_path</code>, que detecta, monta o formatea particiones USB según sea necesario."
},
{
"type": "local",
"url": "/backup/borgbackup (cualquier ruta absoluta)",
"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."
}
]
},
"serverSetup": {
"heading": "Preparar el servidor Borg (lado servidor)",
"intro": "El tipo de repositorio <code>remote</code> espera un servidor Borg operativo accesible por SSH. ProxMenux no bootstrapea el servidor por sí mismo — sólo autoriza una clave contra una cuenta existente en él. Esta sección documenta lo que necesita el servidor antes de que ProxMenux pueda conectarse.",
"hostChoicesTitle": "Dónde puede vivir el servidor",
"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.",
"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.",
"requirementsTitle": "Requisitos en el servidor",
"requirementsRows": [
{
"requirement": "binario borg en <code>/usr/bin/borg</code>",
"detail": "La línea <code>command=\"/usr/bin/borg serve ...\"</code> que ProxMenux escribe en <code>authorized_keys</code> hardcodea esa ruta. Instalar vía APT (<code>apt install borgbackup</code>) lo deja ahí. Un binario independiente debe symlinkarse a <code>/usr/bin/borg</code>."
},
{
"requirement": "Una cuenta de usuario dedicada (típicamente <code>borg</code>)",
"detail": "Es dueña del directorio del repositorio y recibe las conexiones SSH entrantes. No necesita sudo ni acceso a shell — la línea de authorized_keys desactiva las shells interactivas de todos modos."
},
{
"requirement": "Un directorio de repositorio escribible",
"detail": "La ruta que el usuario introduce en ProxMenux (por ejemplo <code>/backup/borgbackup</code>) debe existir en el servidor y ser propiedad del usuario borg."
},
{
"requirement": "Demonio SSH aceptando al usuario borg",
"detail": "<code>PubkeyAuthentication yes</code> (por defecto). La autenticación por contraseña sólo hace falta para el flujo puntual <em>generate-auto</em> — una vez instalada la clave, el servidor puede desactivar la autenticación por contraseña por completo."
}
],
"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."
},
"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:",
"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."
},
{
"mode": "generate-manual",
"label": "Sin contraseña admin en este host",
"detail": "ProxMenux genera la keypair como arriba pero muestra la línea completa de <code>authorized_keys</code> para que el usuario la pegue manualmente en el servidor. La contraseña de admin nunca sale del host ProxMenux porque nunca se pregunta."
},
{
"mode": "generate-pct",
"label": "El servidor Borg es un LXC de PVE",
"detail": "El servidor Borg se ejecuta dentro de un LXC en un nodo PVE. ProxMenux autoriza la clave vía <code>pct exec</code> desde el host PVE — root en el host PVE escribe en el <code>~borg/.ssh/authorized_keys</code> del LXC sin necesidad de hacer SSH al LXC."
},
{
"mode": "existing",
"label": "Usar una clave existente",
"detail": "ProxMenux escanea <code>/root/.ssh/</code> y <code>$HOME/.ssh/</code> buscando claves privadas ed25519/RSA parseables y las lista. El usuario elige una o navega manualmente a una ruta no estándar."
},
{
"mode": "none",
"label": "Configuración SSH por defecto",
"detail": "Sin clave personalizada — Borg usa la configuración SSH por defecto del host (típicamente <code>~/.ssh/id_rsa</code> o un agente SSH)."
}
],
"restrictTitle": "La línea authorized_keys",
"restrictBody": "Para cada clave generada, la línea de <code>authorized_keys</code> que ProxMenux escribe en el servidor bloquea la clave a una única invocación de borg-serve contra la ruta configurada del repositorio:",
"restrictLine": "command=\"/usr/bin/borg serve --restrict-to-path RPATH\",restrict PUBKEY",
"restrictNote": "El <code>command=</code> fuerza que cada sesión SSH que use esta clave ejecute sólo ese comando borg-serve; <code>restrict</code> desactiva port forwarding, agent forwarding, X11 forwarding y asignación de PTY. La clave no se puede usar para abrir una shell interactiva en el servidor ni para acceder a ninguna otra ruta de repositorio, aunque la cuenta tenga privilegios más amplios."
},
"savedTargets": {
"heading": "Destinos guardados",
"intro": "Un destino guardado persiste la configuración del repositorio bajo un nombre amigable para no tener que reintroducir los detalles. Layout de almacenamiento en el directorio de estado de ProxMenux:",
"rows": [
{
"file": "borg-targets.txt",
"content": "Una línea por destino: <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. La lee <code>hb_collect_borg_configs</code> para poblar el menú de selección de destino."
},
{
"file": "borg-pass-NAME.txt",
"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."
},
"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."
},
"runtimeEnv": {
"heading": "Entorno de ejecución",
"intro": "ProxMenux exporta las siguientes variables de entorno antes de invocar <code>borg</code>. Configuran la conexión y desbloquean el repositorio sin embeber secretos en la línea de comandos.",
"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."
},
{
"var": "BORG_PASSPHRASE",
"value": "(passphrase de borg-pass-NAME.txt)",
"purpose": "Desbloquea la repokey. Se fija sólo cuando el destino usa cifrado <code>repokey</code>. Nunca aparece en la lista de argumentos del proceso."
},
{
"var": "BORG_ENCRYPT_MODE",
"value": "repokey | none",
"purpose": "Lo usa <code>hb_borg_init_if_needed</code> al inicializar un repositorio que aún no existe. <code>borg create</code> lo ignora en repositorios existentes."
},
{
"var": "BORG_RELOCATED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Suprime el prompt interactivo que Borg lanza cuando la URL del repositorio difiere de la URL desde la que se alcanzó originalmente (habitual tras un renombrado del punto de montaje o un cambio de dirección del host SSH)."
},
{
"var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Suprime el prompt interactivo que Borg lanza la primera vez que se accede a un repositorio sin cifrar desde un cliente nuevo."
}
]
},
"archiveFormat": {
"heading": "Nombrado de archivos y retención",
"intro": "Cada copia 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."
},
"restoreAccess": {
"heading": "Recuperación del lado de la restauración",
"body": "El flujo de restauración lista los archivos con <code>borg list REPO</code> y extrae el seleccionado con <code>borg extract REPO::ARCHIVE-NAME</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, los mismos comandos funcionan; el árbol extraído es el layout estándar de tres bloques descrito en <em>Cómo funciona</em>."
},
"references": {
"heading": "Referencias",
"intro": "Documentación oficial de Borg para los componentes en los que se apoya ProxMenux.",
"items": [
{
"label": "Documentación de Borg",
"href": "https://borgbackup.readthedocs.io/",
"tail": " — punto de entrada principal, cubre conceptos, despliegue, quickstart y todos los comandos."
},
{
"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."
},
{
"label": "Cifrado del repositorio",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/init.html#encryption-mode",
"tail": " — los modos de cifrado que Borg soporta, incluido repokey que ProxMenux usa por defecto."
},
{
"label": "borg serve y despliegue SSH",
"href": "https://borgbackup.readthedocs.io/en/stable/deployment/central-backup-server.html",
"tail": " — cómo montar un servidor Borg central accedido por SSH, incluyendo el comando borg-serve y la flag restrict-to-path que ProxMenux escribe en authorized_keys."
},
{
"label": "borg prune",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/prune.html",
"tail": " — el modelo de retención detrás de --keep-last / --keep-daily / --keep-weekly que ProxMenux aplica por trabajo programado."
}
]
}
}
@@ -0,0 +1,110 @@
{
"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.",
"ogTitle": "Destinos de ProxMenux Backup",
"ogDescription": "Local, Proxmox Backup Server y Borg — tres backends de almacenamiento para el mismo contenido de copia del host.",
"twitterTitle": "Destinos de ProxMenux Backup | ProxMenux",
"twitterDescription": "Archivo local, Proxmox Backup Server y Borg como backends para copias del host."
},
"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"
},
"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."
},
"comparison": {
"heading": "Comparativa de características",
"intro": "La siguiente tabla lista las diferencias concretas entre los tres backends tal como se comportan hoy en ProxMenux. Los valores describen el comportamiento observado del backend en sí, no recomendaciones editoriales.",
"rows": [
{
"feature": "Formato de almacenamiento",
"local": "Un único fichero <code>.tar.zst</code> (o <code>.tar.gz</code> si <code>zstd</code> no está disponible).",
"pbs": "Backup PBS (chunks <code>.pxar</code> en el datastore).",
"borg": "Archivo Borg dentro de un repositorio Borg (ficheros de segmento)."
},
{
"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."
},
{
"feature": "Deduplicación",
"local": "Ninguna. Cada copia 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."
},
{
"feature": "Cifrado en reposo",
"local": "Ninguno (depende de la protección a nivel de filesystem).",
"pbs": "Cifrado opcional del lado del cliente mediante keyfile. Si se activa, el blob de recuperación se sube como grupo de backups aparte.",
"borg": "Cifrado opcional repokey (la clave se guarda en el repo, se desbloquea con una passphrase)."
},
{
"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."
},
{
"feature": "Red",
"local": "Ninguna. Escribe en un punto de montaje local (típicamente un disco interno o una unidad USB).",
"pbs": "TCP contra el servidor PBS (puerto por defecto 8007). Requiere credenciales PBS + fingerprint.",
"borg": "Ruta local de sistema de ficheros o túnel SSH a un host Borg remoto."
},
{
"feature": "Dependencias",
"local": "<code>tar</code>, <code>zstd</code> (presentes en Proxmox por defecto).",
"pbs": "Paquete <code>proxmox-backup-client</code> (incluido en Proxmox VE 8+).",
"borg": "Binario <code>borg</code>. ProxMenux lo provisiona automáticamente desde el bundle del Monitor AppImage cuando no está presente."
},
{
"feature": "Acceso a la restauración",
"local": "Cualquier host con tar+zstd puede extraer el archivo. No se necesita PBS ni Borg.",
"pbs": "Requiere <code>proxmox-backup-client</code> + credenciales PBS + el keyfile (si está cifrado).",
"borg": "Requiere <code>borg</code> + la ruta del repositorio + la passphrase (si está cifrado)."
}
],
"captionCode": "Característica",
"captionLocal": "Local",
"captionPbs": "Proxmox Backup Server (recomendado)",
"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."
},
"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.",
"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."
},
"whereNext": {
"heading": "Detalle por destino",
"intro": "Cada destino tiene su propia página con el flujo de configuración, el formato en disco y el comando de recuperación que utiliza la restauración.",
"items": [
{
"label": "Archivo local",
"href": "/docs/backup-restore/destinations/local",
"tail": " — preconfiguración del destino local, montaje de unidades USB, el chequeo de seguridad contra escribir el archivo dentro de sí mismo, el sidecar JSON que permite al Monitor identificar el fichero."
},
{
"label": "Proxmox Backup Server (recomendado)",
"href": "/docs/backup-restore/destinations/pbs",
"tail": " — selección de datastore, credenciales y fingerprint, ciclo de vida del keyfile de cifrado, passphrase de recuperación, subida del blob de recuperación a PBS para recuperación tras reinstalación."
},
{
"label": "Borg",
"href": "/docs/backup-restore/destinations/borg",
"tail": " — repositorios locales vs. servidos por SSH, cómo se obtiene el binario Borg (sistema / caché / bundle del Monitor AppImage / descarga de GitHub), inicialización del repositorio, gestión de la passphrase, setup de claves SSH para repos remotos."
}
]
}
}
@@ -0,0 +1,75 @@
{
"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.",
"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."
},
"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"
},
"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."
},
"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>:",
"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.",
"<strong>Elegir una unidad USB.</strong> Abre el submenú USB (más abajo), que detecta los dispositivos extraíbles y ofrece montar o formatear uno."
]
},
"usbFlow": {
"heading": "Detección y montaje de la unidad USB",
"intro": "El submenú USB lista las particiones de los dispositivos extraíbles reportados por <code>lsblk</code>. Cada partición se muestra con su tamaño, etiqueta del filesystem y estado actual. El estado determina la acción que ProxMenux ofrece.",
"statesTitle": "Los tres estados del dispositivo",
"stateRows": [
{
"state": "mounted",
"shown": "Tamaño · label · [fstype] · → /punto/de/montaje",
"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",
"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",
"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."
}
],
"notMountedFallback": "Cuando no se detecta ningún dispositivo USB, el submenú cae en un inputbox simple. El usuario puede introducir una ruta de punto de montaje arbitraria; si la ruta no es un punto de montaje registrado, un diálogo de confirmación advierte antes de continuar."
},
"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."
},
"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.",
"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.",
"sourceTitle": "Qué entra en el archivo",
"sourceBody": "El comando tar se invoca con <code>-C \"$staging_root\" .</code>, lo que archiva la <strong>raíz de staging completa</strong>: <code>rootfs/</code>, <code>metadata/</code> y <code>manifest.json</code>. Los tres bloques quedan uno al lado del otro en el nivel superior del tarball. Extraer el archivo produce exactamente el mismo árbol que consume el código de restauración."
},
"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.",
"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."
},
"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."
}
}
@@ -0,0 +1,102 @@
{
"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; la elección determina <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": "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>."
},
"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": "En el primer uso, <code>proxmox-backup-client key create --kdf none</code> genera el keyfile en <code>/usr/local/share/proxmenux/pbs-key.conf</code> (<code>chmod 600</code>). Las copias posteriores lo reutilizan tras un único diálogo de confirmación. Si la creación del keyfile falla, la copia se cancela y la salida de error de la herramienta se muestra en un diálogo.",
"recoveryTitle": "Passphrase de recuperación y blob de escrow",
"recoveryBody": "Tras crear el keyfile, ProxMenux pregunta dos veces por una passphrase de recuperación (con validación de coincidencia) y ejecuta <code>openssl</code> para producir <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> para almacenamiento offsite. Cancelar el diálogo de la passphrase borra el keyfile recién creado.",
"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.",
"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."
},
"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."
}
]
}
}