update documentation

web/messages/en/docs/backup-restore/destinations/pbs.json

@@ -51,7 +51,7 @@
   "encryption": {
     "heading": "Client-side encryption",
     "glossaryHint": "This section uses the terms <em>keyfile</em>, <em>passphrase</em> and <em>recovery envelope</em>. The <glosarioLink>glossary</glosarioLink> 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 — <code>/usr/local/share/proxmenux/pbs-key.conf</code> — 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 — <code>/usr/local/share/proxmenux/pbs-key.conf</code> — 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: <em>No</em> continues without encryption; <em>Yes</em> moves to step two. Step two depends on whether a keyfile is already installed at <code>/usr/local/share/proxmenux/pbs-key.conf</code>. 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. <em>Generate a new keyfile</em> runs <code>proxmox-backup-client key create --kdf none</code>. <em>Use an existing keyfile</em> auto-detects a PVE-managed keyfile: when the selected PBS repository is registered in Proxmox with an encryption key at <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, 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 <code>chmod 600</code>.",
     "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 <em>Use an existing keyfile</em> 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 — <em>Upload key to PBS?</em> — with two answers. The default is <em>No, keep local only</em>: the keyfile stays only at the canonical local path and the operator handles the offsite copy themselves (the Monitor's <em>Download keyfile</em> button provides one on demand). Choosing <em>Yes, upload</em> 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 <code>pbs-key.recovery.enc</code>. 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 — <em>Upload key to PBS?</em> — with two answers. <strong>Nothing gets uploaded to PBS until the operator answers Yes.</strong> The default is <em>No, keep local only</em>: 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 <em>Download keyfile</em> button in the PBS destination row provides one on demand). Choosing <em>Yes, upload</em> 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 <code>pbs-key.recovery.enc</code>. 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 <em>Yes, upload</em>, 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 <code>-keyrecovery</code>. The two groups sit next to each other in the datastore listing — one for host backups, one for recovery envelopes. <strong>The envelope never leaves the host in plaintext</strong>: encryption happens on the host itself with AES-256-CBC and PBKDF2 before any bytes go on the wire (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). 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 <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, that file is copied to the canonical path silently. Second, when a <code>-keyrecovery</code> 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 <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, that file is copied to the canonical path silently. Second, when a <code>-keyrecovery</code> 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 <code>wrong key — manifest's key XX does not match provided key YY</code> 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: <em>Download</em> exports the current keyfile to the operator's browser, <em>Upload</em> 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 <em>Delete</em> removes the keyfile from the host. The recovery-escrow toggle is a single inline control next to those actions: a Yes/No radio for <em>Upload key to PBS?</em>, a passphrase field when Yes is selected, and a contextual Apply button that reads <em>Start uploading</em>, <em>Stop uploading</em> or <em>Update passphrase</em> 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",