From 17246ebddeb9485e09c53e257b3a8dcc60d4d8f6 Mon Sep 17 00:00:00 2001 From: MacRimi Date: Wed, 8 Jul 2026 19:42:48 +0200 Subject: [PATCH] update documentation --- .../docs/backup-restore/destinations/pbs/page.tsx | 10 +++++++++- .../en/docs/backup-restore/destinations/pbs.json | 10 ++++++---- .../es/docs/backup-restore/destinations/pbs.json | 14 ++++++++------ 3 files changed, 23 insertions(+), 11 deletions(-) diff --git a/web/app/[locale]/docs/backup-restore/destinations/pbs/page.tsx b/web/app/[locale]/docs/backup-restore/destinations/pbs/page.tsx index 818bc71c..4bf935fb 100644 --- a/web/app/[locale]/docs/backup-restore/destinations/pbs/page.tsx +++ b/web/app/[locale]/docs/backup-restore/destinations/pbs/page.tsx @@ -217,7 +217,7 @@ export default async function PbsDestinationPage({

- {t.rich("encryption.recoveryBody", { code })} + {t.rich("encryption.recoveryBody", { code, em, strong })}

@@ -271,6 +271,14 @@ export default async function PbsDestinationPage({ {t.rich("encryption.recoverBody", { code })}

+

+ {t("encryption.monitorManagementTitle")} +

+ +

+ {t.rich("encryption.monitorManagementBody", { code, em })} +

+

{t("restoreAccess.heading")}

diff --git a/web/messages/en/docs/backup-restore/destinations/pbs.json b/web/messages/en/docs/backup-restore/destinations/pbs.json index 69b69090..270f1b02 100644 --- a/web/messages/en/docs/backup-restore/destinations/pbs.json +++ b/web/messages/en/docs/backup-restore/destinations/pbs.json @@ -51,7 +51,7 @@ "encryption": { "heading": "Client-side encryption", "glossaryHint": "This section uses the terms keyfile, passphrase and recovery envelope. The glossary summarises the differences in one sentence per term.", - "intro": "PBS client-side keyfile encryption encrypts chunks on the source host before upload. In ProxMenux encryption is optional; when enabled, uploading a passphrase-wrapped copy of the keyfile to PBS as a recovery escrow is also optional. The keyfile itself always lives at one canonical path on the host — /usr/local/share/proxmenux/pbs-key.conf — and is reused silently by every subsequent encrypted backup.", + "intro": "PBS client-side keyfile encryption encrypts chunks on the source host before upload. In ProxMenux encryption is optional; when enabled, whether to also upload a passphrase-wrapped copy of the keyfile to PBS as a recovery escrow is an explicit yes/no choice the operator makes at setup time (and can revisit later from the Monitor). The keyfile itself always lives at one canonical path on the host — /usr/local/share/proxmenux/pbs-key.conf — and is reused silently by every subsequent encrypted backup.", "keyfileTitle": "Setting up the keyfile", "keyfileBody": "The encryption prompt runs at the first encrypted backup on the host. Step one asks whether to encrypt the backup: No continues without encryption; Yes moves to step two. Step two depends on whether a keyfile is already installed at /usr/local/share/proxmenux/pbs-key.conf. If it is, the installed keyfile is reused silently and the backup proceeds — subsequent backups never re-ask. If it is not, a two-option menu asks how to set one up. Generate a new keyfile runs proxmox-backup-client key create --kdf none. Use an existing keyfile auto-detects a PVE-managed keyfile: when the selected PBS repository is registered in Proxmox with an encryption key at /etc/pve/priv/storage/<NAME>.enc, that file is copied to the ProxMenux canonical path silently and the flow continues. When no PVE-managed keyfile matches the repository, an input prompts for the absolute path where the operator has already placed the keyfile on this host. Either way, the file lands at the canonical path with chmod 600.", "modesTitle": "Per-host or shared keyfile", @@ -60,8 +60,8 @@ "modesPerHostBody": "Each host generates its own keyfile the first time it enables PBS encryption. Isolation is maximum: compromising the keyfile of one host does not expose the backups of any other. Recommended for production fleets and for environments where hosts have different owners or compliance boundaries.", "modesSharedTitle": "Shared keyfile (import on every host)", "modesSharedBody": "One master keyfile generated once and installed on every host via the Use an existing keyfile option. Management is simpler: a single secret to safeguard, and any host can decrypt the archives of any other (useful for consolidation, cross-host restore drills or centralised backup verification). The trade-off is that a leak of the shared keyfile exposes every host at once. Recommended for homelabs and for fleets where all hosts have the same owner and trust boundary.", - "recoveryTitle": "Upload key to PBS — the yes/no question", - "recoveryBody": "Right after the keyfile is chosen, ProxMenux asks a single question — Upload key to PBS? — with two answers. The default is No, keep local only: the keyfile stays only at the canonical local path and the operator handles the offsite copy themselves (the Monitor's Download keyfile button provides one on demand). Choosing Yes, upload prompts for a recovery passphrase — twice, with match validation — and ProxMenux wraps the keyfile with that passphrase using AES-256-CBC and PBKDF2 (600 000 iterations, random salt) to produce pbs-key.recovery.enc. Every subsequent encrypted backup uploads that envelope to PBS as a paired backup group. Neither the passphrase nor a plaintext copy of the keyfile ever leaves the host.", + "recoveryTitle": "Upload key to PBS — the operator decides", + "recoveryBody": "Right after the keyfile is chosen, ProxMenux asks a single explicit question — Upload key to PBS? — with two answers. Nothing gets uploaded to PBS until the operator answers Yes. The default is No, keep local only: the keyfile stays only at the canonical local path, ProxMenux never touches PBS with any recovery artefact, and the operator handles the offsite copy themselves (the Monitor's Download keyfile button in the PBS destination row provides one on demand). Choosing Yes, upload prompts for a recovery passphrase — twice, with match validation — and ProxMenux wraps the keyfile with that passphrase using AES-256-CBC and PBKDF2 (600 000 iterations, random salt) to produce pbs-key.recovery.enc. Every subsequent encrypted backup uploads that envelope to PBS as a paired backup group. Neither the passphrase nor a plaintext copy of the keyfile ever leaves the host. The choice can be changed later from the Monitor at any time — the escrow toggle inline in the PBS destination row flips Yes/No and applies immediately (Start uploading, Stop uploading, or Update passphrase, matching the current state).", "blobUploadTitle": "Paired backup group on PBS", "blobUploadBody1": "When the escrow mode is Yes, upload, ProxMenux uploads the recovery envelope to PBS after every encrypted backup as a second, paired backup group with the same name as the host group but ending in -keyrecovery. The two groups sit next to each other in the datastore listing — one for host backups, one for recovery envelopes. The envelope never leaves the host in plaintext: encryption happens on the host itself with AES-256-CBC and PBKDF2 before any bytes go on the wire (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS receives only the already-encrypted envelope.", "envelopeSecurityTitle": "Is uploading the keyrecovery file to PBS a security risk?", @@ -71,7 +71,9 @@ "blobUploadImageAlt": "PBS UI showing the hostcfg-HOSTNAME and hostcfg-HOSTNAME-keyrecovery backup groups adjacent in the datastore listing.", "blobUploadImageCaption": "PBS UI — the paired backup groups. The main group holds the host backups; the -keyrecovery group holds the passphrase-wrapped keyfile.", "recoverTitle": "Recovery on a fresh host", - "recoverBody": "When the local keyfile is missing at the canonical path — on a freshly reinstalled host, or after an explicit removal — the restore flow tries three sources in order and stops at the first one that produces a usable keyfile. First, when the selected PBS repository has a matching PVE-managed keyfile at /etc/pve/priv/storage/<NAME>.enc, that file is copied to the canonical path silently. Second, when a -keyrecovery group is available on PBS, the newest snapshot is downloaded and the operator is asked for the recovery passphrase to decrypt it. Third, when neither of the above works or the operator declines them, an input prompts for the absolute path where the keyfile lives on this host and copies it to the canonical path. The Monitor exposes the same import flow inline in the backup detail modal — an amber panel appears at the top of the modal when Restore, Download or View contents would need a keyfile that is not installed." + "recoverBody": "When the local keyfile is missing at the canonical path — on a freshly reinstalled host, or after an explicit removal — the restore flow tries three sources in order and stops at the first one that produces a usable keyfile. First, when the selected PBS repository has a matching PVE-managed keyfile at /etc/pve/priv/storage/<NAME>.enc, that file is copied to the canonical path silently. Second, when a -keyrecovery group is available on PBS, the newest snapshot is downloaded and the operator is asked for the recovery passphrase to decrypt it. Third, when neither of the above works or the operator declines them, an input prompts for the absolute path where the keyfile lives on this host and copies it to the canonical path. The Monitor exposes the same import flow inline in the backup detail modal — an amber panel appears at the top of the modal when Restore, Download or View contents would need a keyfile that is not installed. When a keyfile is installed but does not match the one that encrypted the backup, PBS returns a wrong key — manifest's key XX does not match provided key YY error; the same three actions display a structured amber panel with the required manifest fingerprint prominently rendered, so the operator can identify which keyfile to import to open that specific backup.", + "monitorManagementTitle": "Managing the keyfile from the Monitor", + "monitorManagementBody": "The Monitor exposes the keyfile controls inline in each PBS destination row of the backup configuration page. The row shows three actions: Download exports the current keyfile to the operator's browser, Upload replaces the installed keyfile with one supplied by the operator (the previous file is overwritten only after the new one lands successfully at the canonical path), and Delete removes the keyfile from the host. The recovery-escrow toggle is a single inline control next to those actions: a Yes/No radio for Upload key to PBS?, a passphrase field when Yes is selected, and a contextual Apply button that reads Start uploading, Stop uploading or Update passphrase depending on the current state. Every action goes through the same Flask endpoints that the shell TUI uses, so the on-disk effect and the state on PBS are identical whichever surface the operator picks." }, "restoreAccess": { "heading": "Retrieval on the restore side", diff --git a/web/messages/es/docs/backup-restore/destinations/pbs.json b/web/messages/es/docs/backup-restore/destinations/pbs.json index af60b6fb..796f4df1 100644 --- a/web/messages/es/docs/backup-restore/destinations/pbs.json +++ b/web/messages/es/docs/backup-restore/destinations/pbs.json @@ -51,27 +51,29 @@ "encryption": { "heading": "Cifrado del lado del cliente", "glossaryHint": "En esta sección aparecen los términos clave, passphrase y sobre de recuperación. El glosario resume las diferencias en una frase por término.", - "intro": "PBS puede cifrar las copias con una clave que reside únicamente en el host de origen: los datos se cifran en el propio host antes de subirse, y en PBS solo se guardan cifrados. En ProxMenux el cifrado es opcional; al activarlo, también es opcional subir a PBS una copia de la clave envuelta con una passphrase (el sobre de recuperación). La clave siempre vive en una única ruta canónica del host — /usr/local/share/proxmenux/pbs-key.conf — y se reutiliza en silencio en todas las copias cifradas siguientes.", + "intro": "PBS puede cifrar las copias con una clave que reside únicamente en el host de origen: los datos se cifran en el propio host antes de subirse, y en PBS solo se guardan cifrados. En ProxMenux el cifrado es opcional; al activarlo, subir también a PBS una copia de la clave envuelta con una passphrase (el sobre de recuperación) es una decisión sí/no explícita que toma el usuario durante la configuración inicial (y que puede revisar más tarde desde el Monitor). La clave siempre vive en una única ruta canónica del host — /usr/local/share/proxmenux/pbs-key.conf — y se reutiliza en silencio en todas las copias cifradas siguientes.", "keyfileTitle": "Configuración inicial de la clave", - "keyfileBody": "El diálogo aparece en la primera copia cifrada del host. Primero pregunta si se quiere cifrar la copia: No continúa sin cifrado; Sí pasa al segundo paso. El segundo paso depende de si ya hay una clave instalada en /usr/local/share/proxmenux/pbs-key.conf. Si la hay, se reutiliza en silencio y la copia continúa — las copias posteriores no vuelven a preguntar. Si no la hay, aparece un menú con dos opciones. Generar una clave nueva ejecuta proxmox-backup-client key create --kdf none. Usar una clave existente autodetecta una clave gestionada por PVE: si el repositorio PBS seleccionado está registrado en Proxmox con encryption-key en /etc/pve/priv/storage/<NAME>.enc, ese fichero se copia a la ruta canónica de ProxMenux en silencio y el flujo continúa. Cuando ninguna clave PVE coincide con el repositorio, aparece un input pidiendo la ruta absoluta donde el operador ha colocado la clave en este host. En cualquier caso, el fichero acaba en la ruta canónica con chmod 600.", + "keyfileBody": "El diálogo aparece en la primera copia cifrada del host. Primero pregunta si se quiere cifrar la copia: No continúa sin cifrado; Sí pasa al segundo paso. El segundo paso depende de si ya hay una clave instalada en /usr/local/share/proxmenux/pbs-key.conf. Si la hay, se reutiliza en silencio y la copia continúa — las copias posteriores no vuelven a preguntar. Si no la hay, aparece un menú con dos opciones. Generar una clave nueva ejecuta proxmox-backup-client key create --kdf none. Usar una clave existente autodetecta una clave gestionada por PVE: si el repositorio PBS seleccionado está registrado en Proxmox con encryption-key en /etc/pve/priv/storage/<NAME>.enc, ese fichero se copia a la ruta canónica de ProxMenux en silencio y el flujo continúa. Cuando ninguna clave PVE coincide con el repositorio, aparece un input pidiendo la ruta absoluta donde el usuario ha colocado la clave en este host. En cualquier caso, el fichero acaba en la ruta canónica con chmod 600.", "modesTitle": "Clave por host o compartida", "modesIntro": "Ambos modelos operativos están soportados y ninguno se impone — la decisión pertenece al usuario según cómo esté organizada su flota.", "modesPerHostTitle": "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 Usar una clave existente. 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? — la pregunta yes/no", - "recoveryBody": "Justo después de elegir la clave, ProxMenux hace una única pregunta — Upload key to PBS? — con dos respuestas. La opción por defecto es No, keep local only: la clave se queda únicamente en la ruta canónica local y el operador gestiona su propia copia offsite (el botón Download keyfile del Monitor la genera bajo demanda). Al elegir Yes, upload, ProxMenux pide una passphrase de recuperación —dos veces, comprobando que coincidan— y envuelve la clave con esa passphrase usando AES-256-CBC y PBKDF2 (600 000 iteraciones, sal aleatoria) para producir pbs-key.recovery.enc. Todas las copias cifradas siguientes suben ese sobre a PBS como grupo emparejado. Ni la passphrase ni una copia en claro de la clave salen nunca del host.", + "recoveryTitle": "¿Subir la clave a PBS? — el usuario decide", + "recoveryBody": "Justo después de elegir la clave, ProxMenux hace una única pregunta explícita — Upload key to PBS? — con dos respuestas. No se sube nada a PBS hasta que el usuario responde Sí. La opción por defecto es No, keep local only: la clave se queda únicamente en la ruta canónica local, ProxMenux no toca PBS con ningún artefacto de recuperación, y el usuario gestiona su propia copia offsite (el botón Download keyfile en la fila de destino PBS del Monitor la genera bajo demanda). Al elegir Yes, upload, ProxMenux pide una passphrase de recuperación —dos veces, comprobando que coincidan— y envuelve la clave con esa passphrase usando AES-256-CBC y PBKDF2 (600 000 iteraciones, sal aleatoria) para producir pbs-key.recovery.enc. Todas las copias cifradas siguientes suben ese sobre a PBS como grupo emparejado. Ni la passphrase ni una copia en claro de la clave salen nunca del host. La elección se puede cambiar más adelante desde el Monitor en cualquier momento — el interruptor de escrow inline en la fila del destino PBS conmuta Sí/No y se aplica en el acto (Start uploading, Stop uploading o Update passphrase, según el estado actual).", "blobUploadTitle": "Grupo emparejado en PBS", "blobUploadBody1": "Cuando el modo elegido es Yes, upload, 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 -keyrecovery. Los dos grupos aparecen juntos en el listado del datastore, uno con las copias del host y otro con los sobres. El sobre nunca sale del host en claro: el cifrado ocurre en el propio host con AES-256-CBC y PBKDF2 antes de que se envíe un solo byte (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS recibe únicamente el sobre ya cifrado.", "envelopeSecurityTitle": "¿No es un riesgo subir el archivo keyrecovery a PBS?", - "envelopeSecurityBody": "El keyrecovery viaja y se almacena cifrado en todo momento. La passphrase de recuperación nunca abandona el host: el cifrado ocurre localmente antes de la subida y PBS solo recibe el resultado ya cifrado. Aunque un administrador de PBS —o cualquiera con acceso al datastore— descargue el keyrecovery, sin la passphrase de recuperación no puede leer la clave que contiene: son solo bytes cifrados. Para reconstruir la clave hacen falta las dos cosas al mismo tiempo, el keyrecovery y la passphrase, y solo el operador dispone de ambas.", + "envelopeSecurityBody": "El keyrecovery viaja y se almacena cifrado en todo momento. La passphrase de recuperación nunca abandona el host: el cifrado ocurre localmente antes de la subida y PBS solo recibe el resultado ya cifrado. Aunque un administrador de PBS —o cualquiera con acceso al datastore— descargue el keyrecovery, sin la passphrase de recuperación no puede leer la clave que contiene: son solo bytes cifrados. Para reconstruir la clave hacen falta las dos cosas al mismo tiempo, el keyrecovery y la passphrase, y solo el usuario dispone de ambas.", "blobUploadConstraintTitle": "Por qué dos grupos y no uno solo cifrado", "blobUploadConstraintBody": "Una misma subida de proxmox-backup-client backup cifra todos sus archivos con la misma clave, o no cifra ninguno — no hay opción intermedia. La copia del host tiene que ir cifrada con la clave del host; el sobre de recuperación no puede ir en esa misma subida, porque quedaría cifrado con la clave que precisamente contiene: en un equipo recién reinstalado no habría manera de abrirlo (haría falta la clave para descifrar la clave). Por eso se hacen dos subidas independientes y aparecen como dos grupos separados: la copia del host va cifrada por PBS con la clave, y el sobre de recuperación va cifrado por ProxMenux con la passphrase antes de subirse. Son dos capas de cifrado distintas que protegen dos activos distintos.", "blobUploadImageAlt": "Interfaz de PBS mostrando los grupos hostcfg-HOSTNAME y hostcfg-HOSTNAME-keyrecovery adyacentes en el listado del datastore.", "blobUploadImageCaption": "Interfaz de PBS — los grupos de copia emparejados. El grupo principal contiene las copias del host; el grupo -keyrecovery contiene la clave envuelta con la passphrase.", "recoverTitle": "Recuperación en un equipo recién instalado", - "recoverBody": "Cuando falta la clave en la ruta canónica —tras reinstalar el host desde cero o después de eliminarla explícitamente— 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 seleccionado tiene una clave gestionada por PVE en /etc/pve/priv/storage/<NAME>.enc, ese fichero se copia a la ruta canónica en silencio. Segundo, si hay un grupo -keyrecovery disponible en PBS, se descarga el snapshot más reciente y se pide al operador la passphrase de recuperación para descifrarlo. Tercero, si ninguna de las dos vías anteriores funciona o el operador las declina, aparece un input pidiendo la ruta absoluta donde vive la clave en este host, y el fichero se copia a la ruta canónica. El Monitor expone el mismo flujo de importación de forma inline en el modal de detalle de la copia — aparece un panel ámbar en la parte superior cuando Restaurar, Descargar o Ver contenido necesitarían una clave que no está instalada." + "recoverBody": "Cuando falta la clave en la ruta canónica —tras reinstalar el host desde cero o después de eliminarla explícitamente— 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 seleccionado tiene una clave gestionada por PVE en /etc/pve/priv/storage/<NAME>.enc, ese fichero se copia a la ruta canónica en silencio. Segundo, si hay un grupo -keyrecovery disponible en PBS, se descarga el snapshot más reciente y se pide al usuario la passphrase de recuperación para descifrarlo. Tercero, si ninguna de las dos vías anteriores funciona o el usuario las declina, aparece un input pidiendo la ruta absoluta donde vive la clave en este host, y el fichero se copia a la ruta canónica. El Monitor expone el mismo flujo de importación de forma inline en el modal de detalle de la copia — aparece un panel ámbar en la parte superior cuando Restaurar, Descargar o Ver contenido necesitarían una clave que no está instalada. Cuando la clave sí está instalada pero no coincide con la que cifró la copia, PBS devuelve un error wrong key — manifest's key XX does not match provided key YY; las mismas tres acciones muestran un panel ámbar estructurado con el fingerprint del manifest destacado en primer plano, para que el usuario pueda identificar qué clave importar para abrir esa copia concreta.", + "monitorManagementTitle": "Gestionar la clave desde el Monitor", + "monitorManagementBody": "El Monitor expone los controles de la clave de forma inline en cada fila de destino PBS de la página de configuración de copias. La fila muestra tres acciones: Descargar exporta la clave actual al navegador del usuario, Subir reemplaza la clave instalada por una que aporta el usuario (el fichero anterior solo se sobrescribe cuando el nuevo llega correctamente a la ruta canónica), y Eliminar retira la clave del host. El interruptor del sobre de recuperación es un único control inline junto a esas acciones: un radio Sí/No para Upload key to PBS?, un campo de passphrase cuando se selecciona Sí, y un botón Apply contextual que dice Start uploading, Stop uploading o Update passphrase según el estado actual. Todas las acciones pasan por los mismos endpoints Flask que usa el TUI del shell, así que el efecto en disco y en PBS es idéntico independientemente de qué superficie elija el usuario." }, "restoreAccess": { "heading": "Recuperación del lado de la restauración",