update documentation

web/app/[locale]/docs/backup-restore/destinations/pbs/page.tsx

@@ -1,7 +1,8 @@
 import type { Metadata } from "next"
 import { getTranslations, getMessages, setRequestLocale } from "next-intl/server"
-import { Star, ExternalLink } from "lucide-react"
+import { Star, ExternalLink, BookOpen } from "lucide-react"
 import Image from "next/image"
+import { Link } from "@/i18n/navigation"
 import { DocHeader } from "@/components/ui/doc-header"
 import { Callout } from "@/components/ui/callout"
 import CopyableCode from "@/components/CopyableCode"
@@ -98,7 +99,7 @@ export default async function PbsDestinationPage({
       </h2>
 
       <p className="mb-4 text-gray-800 leading-relaxed">
-        {t.rich("repoSelection.intro", { code })}
+        {t.rich("repoSelection.intro", { code, em })}
       </p>
 
       <div className="overflow-x-auto mb-6">
@@ -160,6 +161,23 @@ export default async function PbsDestinationPage({
         {t("encryption.heading")}
       </h2>
 
+      <div className="mb-6 flex items-start gap-3 rounded-md border border-slate-200 bg-slate-50 px-4 py-3 text-sm text-slate-800">
+        <BookOpen className="h-4 w-4 text-slate-500 shrink-0 mt-0.5" aria-hidden="true" />
+        <p className="leading-relaxed">
+          {t.rich("encryption.glossaryHint", {
+            em,
+            glosarioLink: (chunks) => (
+              <Link
+                href="/docs/backup-restore/glossary#group-0"
+                className="text-blue-600 hover:underline font-medium"
+              >
+                {chunks}
+              </Link>
+            ),
+          })}
+        </p>
+      </div>
+
       <p className="mb-4 text-gray-800 leading-relaxed">
         {t.rich("encryption.intro", { code, strong })}
       </p>
@@ -207,7 +225,7 @@ export default async function PbsDestinationPage({
       </h3>
 
       <p className="mb-4 text-gray-800 leading-relaxed">
-        {t.rich("encryption.blobUploadBody1", { code })}
+        {t.rich("encryption.blobUploadBody1", { code, strong })}
       </p>
 
       <figure className="my-6">
@@ -231,6 +249,12 @@ export default async function PbsDestinationPage({
         </figcaption>
       </figure>
 
+      <Callout variant="success" title={t("encryption.envelopeSecurityTitle")}>
+        <p className="leading-relaxed">
+          {t.rich("encryption.envelopeSecurityBody", { code, strong, em })}
+        </p>
+      </Callout>
+
       <h4 className="text-base font-semibold mt-6 mb-2 text-gray-900">
         {t("encryption.blobUploadConstraintTitle")}
       </h4>

web/app/[locale]/docs/backup-restore/glossary/page.tsx

@@ -0,0 +1,141 @@
+import type { Metadata } from "next"
+import { getTranslations, getMessages, setRequestLocale } from "next-intl/server"
+import { Link } from "@/i18n/navigation"
+import { DocHeader } from "@/components/ui/doc-header"
+
+export async function generateMetadata({
+  params,
+}: {
+  params: Promise<{ locale: string }>
+}): Promise<Metadata> {
+  const { locale } = await params
+  const t = await getTranslations({ locale, namespace: "docs.backupRestore.glossary.meta" })
+  return {
+    title: t("title"),
+    description: t("description"),
+    keywords: [
+      "proxmenux backup glossary",
+      "proxmox backup terminology",
+      "pbs recovery envelope",
+      "pbs keyfile passphrase",
+      "backup vocabulary",
+    ],
+    alternates: { canonical: "https://proxmenux.com/docs/backup-restore/glossary" },
+    openGraph: {
+      title: t("ogTitle"),
+      description: t("ogDescription"),
+      type: "article",
+      url: "https://proxmenux.com/docs/backup-restore/glossary",
+    },
+    twitter: {
+      card: "summary_large_image",
+      title: t("twitterTitle"),
+      description: t("twitterDescription"),
+    },
+  }
+}
+
+type Entry = { id: string; term: string; also?: string; def: string }
+type Group = { title: string; intro: string; entries: Entry[] }
+type WhereNextItem = { label: string; href: string; tail: string }
+
+export default async function GlossaryPage({
+  params,
+}: {
+  params: Promise<{ locale: string }>
+}) {
+  const { locale } = await params
+  setRequestLocale(locale)
+  const t = await getTranslations({ locale, namespace: "docs.backupRestore.glossary" })
+
+  const messages = (await getMessages({ locale })) as unknown as {
+    docs: { backupRestore: { glossary: {
+      groups: Group[]
+      whereNext: { items: WhereNextItem[] }
+    } } }
+  }
+  const gl = messages.docs.backupRestore.glossary
+  const groups = gl.groups
+  const whereNextItems = gl.whereNext.items
+
+  return (
+    <div>
+      <DocHeader
+        title={t("header.title")}
+        description={t("header.description")}
+        section={t("header.section")}
+        estimatedMinutes={8}
+      />
+
+      <p className="mt-8 mb-8 text-gray-800 leading-relaxed">
+        {t("intro.body")}
+      </p>
+
+      <nav
+        className="mb-10 rounded-lg border border-gray-200 bg-gray-50 p-4"
+        aria-label={t("header.title")}
+      >
+        <ul className="flex flex-wrap gap-x-4 gap-y-2 text-sm">
+          {groups.map((group, idx) => (
+            <li key={idx}>
+              <a
+                href={`#group-${idx}`}
+                className="text-blue-600 hover:underline font-medium"
+              >
+                {group.title}
+              </a>
+            </li>
+          ))}
+        </ul>
+      </nav>
+
+      {groups.map((group, idx) => (
+        <section key={idx} id={`group-${idx}`} className="mb-12 scroll-mt-24">
+          <h2 className="text-2xl font-semibold mt-10 mb-3 text-gray-900">
+            {group.title}
+          </h2>
+          <p className="mb-6 text-gray-800 leading-relaxed">
+            {group.intro}
+          </p>
+          <dl className="space-y-6">
+            {group.entries.map((entry) => (
+              <div
+                key={entry.id}
+                id={entry.id}
+                className="scroll-mt-24 border-l-4 border-blue-100 pl-4"
+              >
+                <dt className="mb-1">
+                  <span className="font-semibold text-gray-900">{entry.term}</span>
+                  {entry.also ? (
+                    <span className="ml-2 text-sm text-gray-500 italic">
+                      ({entry.also})
+                    </span>
+                  ) : null}
+                </dt>
+                <dd
+                  className="text-gray-800 leading-relaxed [&_a]:text-blue-600 [&_a]:hover:underline [&_code]:bg-gray-100 [&_code]:px-1 [&_code]:py-0.5 [&_code]:rounded [&_code]:text-sm"
+                  dangerouslySetInnerHTML={{ __html: entry.def }}
+                />
+              </div>
+            ))}
+          </dl>
+        </section>
+      ))}
+
+      <h2 className="text-2xl font-semibold mt-12 mb-4 text-gray-900">
+        {t("whereNext.heading")}
+      </h2>
+
+      <ul className="mb-6 space-y-2">
+        {whereNextItems.map((item) => (
+          <li key={item.href} className="text-gray-800 leading-relaxed">
+            <Link href={item.href} className="text-blue-600 hover:underline font-medium">
+              {item.label}
+            </Link>
+            <span>{item.tail}</span>
+          </li>
+        ))}
+      </ul>
+    </div>
+  )
+}

web/app/[locale]/docs/backup-restore/scheduled-jobs/page.tsx

@@ -1,6 +1,6 @@
 import type { Metadata } from "next"
 import { getTranslations, getMessages, setRequestLocale } from "next-intl/server"
-import { Info } from "lucide-react"
+import { Info, CalendarClock } from "lucide-react"
 import { Link } from "@/i18n/navigation"
 import { DocHeader } from "@/components/ui/doc-header"
 import { Callout } from "@/components/ui/callout"
@@ -117,6 +117,20 @@ export default async function ScheduledJobsPage({
         </div>
       </div>
 
+      <div className="my-8 rounded-lg border border-emerald-200 bg-emerald-50 p-5">
+        <div className="flex items-start gap-3">
+          <CalendarClock className="h-5 w-5 text-emerald-700 shrink-0 mt-0.5" aria-hidden="true" />
+          <div>
+            <h3 className="text-base font-semibold text-emerald-900 mb-1">
+              {t("frequencyBadge.title")}
+            </h3>
+            <p className="text-sm text-emerald-900/90 leading-relaxed">
+              {t.rich("frequencyBadge.body", { code, strong })}
+            </p>
+          </div>
+        </div>
+      </div>
+
       <h2 className="text-2xl font-semibold mt-10 mb-4 text-gray-900">
         {t("modes.heading")}
       </h2>

web/components/DocSidebar.tsx

@@ -270,6 +270,7 @@ export const sidebarItems: MenuItem[] = [
       { title: "Scheduled jobs", i18nKey: "backupRestoreJobs", href: "/docs/backup-restore/scheduled-jobs" },
       { title: "Restoring", i18nKey: "backupRestoreRestoring", href: "/docs/backup-restore/restoring" },
       { title: "Cross-kernel restore", i18nKey: "backupRestoreCrossKernel", href: "/docs/backup-restore/cross-kernel" },
+      { title: "Glossary", i18nKey: "backupRestoreGlossary", href: "/docs/backup-restore/glossary" },
     ],
   },
 

web/messages/en/common.json

@@ -180,7 +180,8 @@
       "backupRestoreCreating": "Creating backups",
       "backupRestoreJobs": "Scheduled jobs",
       "backupRestoreRestoring": "Restoring",
-      "backupRestoreCrossKernel": "Cross-kernel restore"
+      "backupRestoreCrossKernel": "Cross-kernel restore",
+      "backupRestoreGlossary": "Glossary"
     }
   },
   "hero": {

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

@@ -50,6 +50,7 @@
   },
   "encryption": {
     "heading": "Client-side encryption",
+    "glossaryHint": "This section uses the terms <em>keyfile</em>, <em>passphrase</em> and <em>recovery envelope</em>. If it ever gets hard to keep them apart, 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. ProxMenux enables the feature with one added constraint: a recovery passphrase is mandatory when encryption is enabled. The passphrase does not protect the local keyfile; it protects the escrow copy of the keyfile that ProxMenux uploads to PBS for disaster recovery.",
     "keyfileTitle": "Keyfile",
     "keyfileBody": "The encryption prompt is a two-step yes/no. 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. 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> — the resulting keyfile has no passphrase, so the scheduled runner can use it under systemd without any interactive prompt. <em>Import an existing keyfile</em> takes a path the operator supplies and copies it into place with <code>chmod 600</code>; ProxMenux does not inspect the contents (any keyfile the operator accepts as valid on their PBS is accepted here, including scrypt-encoded keyfiles that could not be validated non-interactively). When importing, the flow also asks for the keyfile's own passphrase — the one that <code>proxmox-backup-client key create --kdf scrypt</code> asked for at creation. That passphrase is persisted at <code>/usr/local/share/proxmenux/pbs-key.pass</code> (chmod 600) and reused by every encrypted job on this host as <code>PBS_ENCRYPTION_PASSWORD</code>. Leaving it blank means the keyfile is <code>--kdf none</code> (no passphrase). Both branches run only after the recovery passphrase has been confirmed — cancelling any dialog before that point leaves the disk unchanged.",
@@ -62,9 +63,11 @@
     "recoveryTitle": "Recovery passphrase and escrow blob",
     "recoveryBody": "The recovery passphrase is asked BEFORE any keyfile is written to disk. ProxMenux prompts twice with match validation; then, only if the operator confirms, the keyfile is created (or imported) and <code>openssl</code> produces <code>pbs-key.recovery.enc</code> — the keyfile encrypted with the passphrase. A copy is written to <code>/root/pbs-key.recovery-HOSTNAME-YYYYMMDD.enc</code> for offsite storage. Cancelling the passphrase dialog leaves the disk untouched — no keyfile is created and no cleanup is needed.",
     "blobUploadTitle": "Paired backup group on PBS",
-    "blobUploadBody1": "After a PBS backup that used the keyfile, the escrow blob is uploaded as a second backup group: <code>host/hostcfg-HOSTNAME-keyrecovery/BACKUP-TIME</code>. The shared <code>hostcfg-HOSTNAME</code> prefix places both groups adjacent in the PBS UI; the <code>-keyrecovery</code> suffix labels the relationship. The upload runs without <code>--keyfile</code> (the blob is already passphrase-protected by openssl) and only when the current backup used the keyfile.",
-    "blobUploadConstraintTitle": "Why two groups",
-    "blobUploadConstraintBody": "<code>--keyfile</code> is a per-invocation flag in <code>proxmox-backup-client backup</code>: all archives in a single invocation are encrypted with the keyfile or none are. <code>hostcfg.pxar</code> requires encryption; <code>keyrecovery.conf</code> cannot be encrypted with the same keyfile (fresh-install recovery would then require the keyfile it is meant to recover). Two invocations, two backup IDs.",
+    "blobUploadBody1": "After a backup that used the keyfile, ProxMenux uploads the recovery envelope to PBS 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>: before upload, ProxMenux encrypts it on the host itself with AES-256-CBC, using a key derived from the recovery passphrase via PBKDF2 with 600 000 iterations and a random salt (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS receives only the already-encrypted envelope, and the upload happens only when the main backup was encrypted.",
+    "envelopeSecurityTitle": "Is uploading the keyrecovery file to PBS a security risk?",
+    "envelopeSecurityBody": "The keyrecovery file is encrypted in transit and at rest. The recovery passphrase never leaves the host: encryption happens locally before the upload, and PBS only ever sees the already-encrypted result. A PBS administrator — or anyone with access to the datastore — can download the keyrecovery file, but without the recovery passphrase they cannot read the keyfile inside: it is opaque ciphertext. Reconstructing the keyfile requires both pieces at once, the keyrecovery file and the passphrase, and only the operator holds both.",
+    "blobUploadConstraintTitle": "Why two groups instead of a single encrypted one",
+    "blobUploadConstraintBody": "A single <code>proxmox-backup-client backup</code> invocation encrypts every one of its archives with the same keyfile, or none at all — there is no in-between. The host backup has to be encrypted with the host keyfile, but the recovery envelope cannot ride along in that same upload, because it would end up encrypted with the very keyfile it contains: on a freshly reinstalled host there would be no way to open it (you would need the keyfile to decrypt the keyfile). That is why the two artefacts are uploaded independently and appear as two separate groups: the host backup is encrypted by PBS with the keyfile, and the recovery envelope is encrypted by ProxMenux with the passphrase before upload. Two different encryption layers protecting two different assets.",
     "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 escrow blob.",
     "recoverTitle": "Fresh-install recovery",

web/messages/en/docs/backup-restore/glossary.json

@@ -0,0 +1,230 @@
+{
+  "meta": {
+    "title": "Glossary — Backup & Restore | ProxMenux",
+    "description": "Glossary of terms and definitions for the ProxMenux backup & restore stack: encryption, keyfile, passphrase, recovery envelope, PBS, chunks, rootfs, manifest, runner and cross-kernel hydration.",
+    "ogTitle": "Backup & Restore glossary | ProxMenux",
+    "ogDescription": "Clear definitions for the vocabulary used across the ProxMenux backup & restore documentation.",
+    "twitterTitle": "Backup & Restore glossary | ProxMenux",
+    "twitterDescription": "Passphrase, keyfile, recovery envelope, rootfs, manifest, PBS, chunks — all defined in one place."
+  },
+  "header": {
+    "title": "Glossary",
+    "description": "Terms used across the backup & restore documentation, with their definition.",
+    "section": "Backup & Restore"
+  },
+  "intro": {
+    "body": "Terms are grouped by theme. Every entry gives the term and a short definition."
+  },
+  "groups": [
+    {
+      "title": "Encryption and key recovery",
+      "intro": "Vocabulary for the PBS encryption block. It involves two distinct secrets: a binary keyfile and a written passphrase.",
+      "entries": [
+        {
+          "id": "passphrase-recuperacion",
+          "term": "Recovery passphrase",
+          "def": "Text password the operator picks to protect the <a href=\"#sobre-recuperacion\">recovery envelope</a>. It is prompted twice with a match check, and is only used to encrypt the envelope and to decrypt it if the keyfile ever needs to be recovered. <strong>It is not the passphrase that unlocks the keyfile itself</strong>, and it is never sent to PBS. During a normal backup it never leaves the host."
+        },
+        {
+          "id": "clave-cifrado",
+          "term": "Keyfile (encryption key)",
+          "def": "Binary file that Proxmox Backup Server uses to encrypt the <a href=\"#chunk\">chunks</a> of each backup before uploading them. Without this file, no encrypted backup can be read. ProxMenux stores it at <code>/usr/local/share/proxmenux/pbs-key.conf</code> with mode <code>600</code>. This is the asset that has to be protected; the <a href=\"#sobre-recuperacion\">recovery envelope</a> exists precisely so that this file can be rescued if it is lost."
+        },
+        {
+          "id": "contrasena-keyfile",
+          "term": "Keyfile passphrase (KDF passphrase)",
+          "def": "Optional passphrase that the keyfile itself may carry, distinct from the <a href=\"#passphrase-recuperacion\">recovery passphrase</a>. It only exists when the keyfile was created with <code>--kdf scrypt</code> (typically an imported keyfile). Without it, the keyfile cannot be unlocked for use. ProxMenux persists it in encrypted form on the host so that scheduled backups can run without an interactive prompt."
+        },
+        {
+          "id": "sobre-recuperacion",
+          "term": "Recovery envelope",
+          "def": "The <a href=\"#clave-cifrado\">keyfile</a> wrapped in an extra layer: it is encrypted with the <a href=\"#passphrase-recuperacion\">recovery passphrase</a> using <a href=\"#aes-256-cbc\">AES-256-CBC</a> and <a href=\"#pbkdf2\">PBKDF2</a> before it ever leaves the host. It is what gets uploaded to PBS as the <code>-keyrecovery</code> group and what is also written to <code>/root/pbs-key.recovery-HOSTNAME-DATE.enc</code> as an offsite backup. Without the passphrase, the envelope is opaque: downloading it from PBS does not reveal the keyfile."
+        },
+        {
+          "id": "cifrado-cliente",
+          "term": "Client-side encryption",
+          "def": "Encryption model in which data is encrypted on the source host before being uploaded. PBS only ever receives and stores ciphertext; not even a PBS administrator with datastore access can read it without the keyfile. ProxMenux builds on this model and adds the <a href=\"#sobre-recuperacion\">recovery envelope</a> on top."
+        },
+        {
+          "id": "kdf-none",
+          "term": "--kdf none",
+          "def": "Option to <code>proxmox-backup-client key create</code> that produces a keyfile with no attached passphrase. The keyfile can be used directly without a prompt, which is essential for scheduled jobs running unattended. This is what ProxMenux uses by default when generating a new keyfile."
+        },
+        {
+          "id": "kdf-scrypt",
+          "term": "--kdf scrypt",
+          "def": "Option to <code>proxmox-backup-client key create</code> that produces a keyfile protected by a <a href=\"#contrasena-keyfile\">keyfile passphrase</a>. Each use of the keyfile requires unlocking it with that passphrase. ProxMenux accepts this style of keyfile on import and stores the passphrase encrypted so scheduled backups can still run unattended."
+        },
+        {
+          "id": "aes-256-cbc",
+          "term": "AES-256-CBC",
+          "def": "Standard symmetric cipher. ProxMenux uses it (via <code>openssl enc -aes-256-cbc</code>) to wrap the <a href=\"#clave-cifrado\">keyfile</a> with the <a href=\"#passphrase-recuperacion\">recovery passphrase</a> and produce the <a href=\"#sobre-recuperacion\">envelope</a>."
+        },
+        {
+          "id": "pbkdf2",
+          "term": "PBKDF2",
+          "def": "Cryptographic function that turns a human-typed passphrase into a binary key suitable for encryption. It slows down brute-force attempts by applying many iterations. ProxMenux uses it with 600 000 iterations and a random salt when encrypting the recovery envelope."
+        }
+      ]
+    },
+    {
+      "title": "Backup structure",
+      "intro": "Terms describing what lives inside a backup, regardless of destination.",
+      "entries": [
+        {
+          "id": "rootfs",
+          "term": "rootfs / root filesystem",
+          "def": "A flat copy of the source host's filesystem, produced by <code>rsync</code> over the <a href=\"#perfil-defecto\">default profile</a> plus any <a href=\"#rutas-personalizadas\">custom paths</a>. It is not a whole-disk image: only paths that contain configuration or state Proxmox cannot regenerate on its own are copied."
+        },
+        {
+          "id": "manifiesto",
+          "term": "Manifest (manifest.json)",
+          "def": "Structured JSON document describing the source host at backup time: hardware, storage, kernel, ProxMenux-installed components and inventory of VMs and LXCs. It is produced by six independent collectors. The restore flow uses it to compare source and target."
+        },
+        {
+          "id": "staging",
+          "term": "Staging directory",
+          "def": "Temporary directory where ProxMenux assembles the three blocks (rootfs, metadata and manifest) before packing them and uploading to the destination. It is removed automatically when the backup finishes, even on abort."
+        },
+        {
+          "id": "perfil-defecto",
+          "term": "Default profile",
+          "def": "Curated set of paths that ProxMenux copies by default in every backup. Covers PVE config, network, SSH, kernel, apt, ProxMenux tools and more. It is defined in code and documented on the <em>How it works</em> page."
+        },
+        {
+          "id": "rutas-personalizadas",
+          "term": "Custom paths",
+          "def": "Extra paths the user adds on top of the <a href=\"#perfil-defecto\">default profile</a>. Either persistent (stored in <code>backup-extra-paths.txt</code>) or per-run (picked in Custom mode)."
+        }
+      ]
+    },
+    {
+      "title": "Destinations and storage",
+      "intro": "Terms tied to where the backup lands — PBS server, local archive or Borg repository — and how PBS organises the data.",
+      "entries": [
+        {
+          "id": "repositorio-pbs",
+          "term": "PBS repository",
+          "def": "Combination of Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + user that receives the backup. Identified by the string <code>user@realm@host:datastore</code>. A single PBS server can host several repositories."
+        },
+        {
+          "id": "datastore",
+          "term": "Datastore",
+          "def": "Concrete store inside a PBS server where backups and their chunks live. Each datastore sits on a filesystem of the PBS server and has its own permissions and policies."
+        },
+        {
+          "id": "chunk",
+          "term": "Chunk / chunk deduplication",
+          "def": "PBS splits every backup into variable-size chunks, identifies each chunk by its hash and stores each chunk only once, even if it appears in many different backups. This means successive backups of the same host — or across similar hosts — take very little additional space."
+        },
+        {
+          "id": "fingerprint",
+          "term": "Fingerprint",
+          "def": "Cryptographic fingerprint of the PBS server's TLS certificate. It lets the client verify it is talking to the intended server without relying on a public certificate authority. ProxMenux passes it to <code>proxmox-backup-client</code> via the <code>PBS_FINGERPRINT</code> environment variable."
+        },
+        {
+          "id": "grupo-copia",
+          "term": "Backup group",
+          "def": "Logical container inside PBS under which successive backups of the same asset accumulate. Each new backup shares deduplication with earlier ones in the same group. ProxMenux uses two groups per host when encryption is enabled: one for the host backup and one with a <code>-keyrecovery</code> suffix for the <a href=\"#sobre-recuperacion\">recovery envelope</a>."
+        },
+        {
+          "id": "backup-id",
+          "term": "Backup ID",
+          "def": "Name of the <a href=\"#grupo-copia\">backup group</a>. ProxMenux defaults to <code>hostcfg-HOSTNAME</code> and lets the operator edit it before upload; unsupported characters are stripped automatically."
+        },
+        {
+          "id": "pxar",
+          "term": ".pxar",
+          "def": "PBS-native archive format for directories. It behaves like a tar optimised for chunk deduplication: rather than storing an opaque file, PBS breaks its contents into reusable chunks."
+        }
+      ]
+    },
+    {
+      "title": "Execution and scheduling",
+      "intro": "Terms used by the ProxMenux scheduled-jobs system.",
+      "entries": [
+        {
+          "id": "runner",
+          "term": "Runner",
+          "def": "The <code>run_scheduled_backup.sh</code> script that executes a scheduled backup. It reads the job config, launches the matching backend (Local, PBS or Borg), applies retention on success and sends the configured notifications."
+        },
+        {
+          "id": "trabajo-programado",
+          "term": "Scheduled job",
+          "def": "Persisted configuration of a recurring backup. Holds destination, credentials, encryption, schedule and retention. Lives at <code>/var/lib/proxmenux/backup-jobs/&lt;id&gt;.env</code>."
+        },
+        {
+          "id": "modo-adjunto",
+          "term": "Attach mode",
+          "def": "Scheduled job with no schedule of its own; it fires automatically whenever an existing PVE <code>vzdump</code> task runs. It inherits the schedule and retention from that parent task. Supported for Local and PBS destinations only."
+        },
+        {
+          "id": "timer-systemd",
+          "term": "Systemd timer",
+          "def": "Standard systemd mechanism that fires a command on a calendar. ProxMenux creates one timer per <em>independent</em> scheduled job; <a href=\"#modo-adjunto\">attach-mode</a> jobs use no timer, they run via the PVE script-hook."
+        },
+        {
+          "id": "retencion",
+          "term": "Retention (keep-last, keep-daily…)",
+          "def": "Policy that decides which older backups to keep and which to prune. Defined per job with parameters like <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. Applied by the runner after each successful backup."
+        }
+      ]
+    },
+    {
+      "title": "Restore",
+      "intro": "Terms from the restore flow.",
+      "entries": [
+        {
+          "id": "restauracion-universal",
+          "term": "Universal restore",
+          "def": "The ProxMenux restore flow does not just extract the filesystem: it reads the manifest to spot differences between source and target, reproduces the system configuration and re-runs the installers for the ProxMenux-managed components. The goal is to reproduce the source host, not merely the archive."
+        },
+        {
+          "id": "hidratacion",
+          "term": "Hydration (cross-kernel)",
+          "def": "Restore pass that merges the user's own configuration from the source (IOMMU tokens, VFIO device IDs, custom quirks, GRUB keys) on top of the target's fresh boot configuration, without copying the source's kernel-tied files verbatim. Runs when the target kernel is newer than the backup's."
+        },
+        {
+          "id": "cross-kernel",
+          "term": "Cross-kernel restore",
+          "def": "Restore where the target's kernel differs from (usually is newer than) the source's. Requires the <a href=\"#hidratacion\">hydration</a> pass to avoid dragging along files incompatible with the target's kernel."
+        },
+        {
+          "id": "instalador-postboot",
+          "term": "Post-boot installer",
+          "def": "Components reinstalled after the first boot of the restored host (NVIDIA drivers, Coral TPU drivers, AMD GPU tools, Intel GPU tools). Each installer runs against the target's kernel, so the restored host does not depend on the source's kernel being present."
+        },
+        {
+          "id": "compatibility-check",
+          "term": "Compatibility check",
+          "def": "Comparison between the source manifest and the target's state that ProxMenux performs at the start of the restore. It decides which parts are copied verbatim, which need hydration and which are recreated by an installer."
+        },
+        {
+          "id": "equipo-recien-instalado",
+          "term": "Fresh install",
+          "def": "Host just reinstalled from scratch, with no local <a href=\"#clave-cifrado\">keyfile</a>. Restoring an encrypted backup requires first recovering the keyfile from the <a href=\"#sobre-recuperacion\">envelope</a> stored on PBS, using the <a href=\"#passphrase-recuperacion\">recovery passphrase</a>."
+        }
+      ]
+    }
+  ],
+  "whereNext": {
+    "heading": "Where next",
+    "items": [
+      {
+        "label": "How it works",
+        "href": "/docs/backup-restore/how-it-works",
+        "tail": " — where the rootfs, manifest and application inventory fit inside a backup."
+      },
+      {
+        "label": "Proxmox Backup Server destination",
+        "href": "/docs/backup-restore/destinations/pbs",
+        "tail": " — where client-side encryption, keyfile, recovery passphrase and envelope are documented in depth."
+      },
+      {
+        "label": "Restoring",
+        "href": "/docs/backup-restore/restoring",
+        "tail": " — the restore flow and manifest usage."
+      }
+    ]
+  }
+}

web/messages/en/docs/backup-restore/scheduled-jobs.json

@@ -24,6 +24,10 @@
     "title": "Attach mode — recommended when a PVE vzdump task already exists",
     "body": "When a PVE vzdump backup task is already configured for the VMs and LXCs on this node, attaching the host backup to that task guarantees the host configuration is captured in the <strong>same window</strong> as the guests. On restore, the guest configs come from the host backup (they live under <code>/etc/pve</code>), and the guest disks come from the vzdump backup taken alongside — both sets are consistent with each other, so a full-node recovery can reproduce the host and re-attach every guest without version drift."
   },
+  "frequencyBadge": {
+    "title": "Recommended frequency",
+    "body": "To maximise compatibility between a host backup and its future restore, run host backups frequently. The closer the backup is to the current state of the host, the less configuration, package and component drift the restore has to reconcile."
+  },
   "modes": {
     "heading": "The two modes",
     "rows": [

web/messages/es/common.json

@@ -180,7 +180,8 @@
       "backupRestoreCreating": "Crear copias",
       "backupRestoreJobs": "Trabajos programados",
       "backupRestoreRestoring": "Restauración",
-      "backupRestoreCrossKernel": "Restauración cross-kernel"
+      "backupRestoreCrossKernel": "Restauración cross-kernel",
+      "backupRestoreGlossary": "Glosario"
     }
   },
   "hero": {

web/messages/es/docs/backup-restore/creating-backups.json

@@ -163,7 +163,7 @@
     "customPathsBody": "Una ruta custom añadida en línea en modo Custom o persistida en <code>backup-extra-paths.txt</code> pasa por el mismo pipeline de <code>rsync</code> que las rutas del perfil por defecto. Se aplican las exclusiones globales. Si la ruta custom está bajo <code>/root/</code> o <code>/usr/local/share/proxmenux/</code>, siguen aplicando las exclusiones específicas de arriba. Cada ruta archivada — default o custom — queda registrada en <code>metadata/paths_archived.txt</code>. Las rutas que no existen en el origen se registran en <code>metadata/missing_paths.txt</code> sin detener la copia."
   },
   "archiveStructure": {
-    "heading": "Estructura del archive",
+    "heading": "Estructura del archivo",
     "intro": "El directorio de staging que produce cada backend sigue el mismo layout con independencia del destino. El tarball, el <code>.pxar</code> de PBS o el archivo Borg almacenan este árbol verbatim.",
     "tree": "backup-[timestamp]/\n├── manifest.json                  # estado estructurado del host (kernel_params, hardware, storage, guests, components, source_host)\n├── metadata/\n│   ├── packages.manual.list       # salida de apt-mark showmanual\n│   ├── run_info.env               # hostname, timestamp, versión del kernel\n│   ├── paths_archived.txt         # lista exacta de rutas que llegaron a rootfs/\n│   └── missing_paths.txt          # rutas del perfil ausentes en el origen\n└── rootfs/\n    ├── etc/                       # /etc/pve, /etc/network, /etc/ssh, /etc/apt, ...\n    ├── root/                      # /root sin subpaths volátiles\n    ├── usr/local/                 # /usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux (sólo estado)\n    └── var/                       # /var/lib/pve-cluster, /var/spool/cron/crontabs"
   },

web/messages/es/docs/backup-restore/destinations/index.json

@@ -75,8 +75,8 @@
     "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."
+    "heading": "El contenido interno de la copia es el mismo en cualquier destino",
+    "body": "Con independencia de dónde se guarde la copia, dentro siempre están los mismos tres bloques descritos en <em>Cómo funciona</em>: el sistema de ficheros (<code>rootfs/</code>), los metadatos (<code>metadata/</code>) y el manifiesto (<code>manifest.json</code>). Al extraer una copia local <code>.tar.zst</code>, restaurar un archivo <code>.pxar</code> desde PBS o descomprimir un archivo Borg, el árbol de directorios resultante es idéntico en los tres casos. Esto significa que el proceso de restauración lee siempre los mismos ficheros y no le importa desde qué destino provenga la copia."
   },
   "extractStandalone": {
     "heading": "Extraer una copia fuera de ProxMenux",

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

@@ -23,7 +23,7 @@
   },
   "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.",
+    "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)",
@@ -45,30 +45,33 @@
     "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>."
+    "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",
-    "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": "El diálogo de cifrado sigue un flujo yes/no en dos pasos. El primer paso pregunta si se desea cifrar el backup: <em>No</em> continúa sin cifrado; <em>Yes</em> pasa al segundo paso. El segundo paso depende de si ya hay un keyfile instalado en <code>/usr/local/share/proxmenux/pbs-key.conf</code>. Si lo hay, se reutiliza silenciosamente y el backup continúa. Si no lo hay, aparece un menú de dos opciones. <em>Generate a new keyfile</em> ejecuta <code>proxmox-backup-client key create --kdf none</code> — el keyfile resultante no lleva passphrase, así que el runner programado bajo systemd puede usarlo sin prompt interactivo. <em>Import an existing keyfile</em> toma una ruta indicada por el operador y la copia en la ubicación canónica con <code>chmod 600</code>; ProxMenux no inspecciona el contenido (cualquier keyfile que el operador acepte como válido en su PBS se acepta aquí, incluyendo keyfiles cifrados con scrypt que no podrían validarse de forma no interactiva). Al importar, el flujo pide también la passphrase del propio keyfile — la que <code>proxmox-backup-client key create --kdf scrypt</code> pidió al crearlo. Esa passphrase se persiste en <code>/usr/local/share/proxmenux/pbs-key.pass</code> (chmod 600) y se reutiliza en cada job cifrado del host como <code>PBS_ENCRYPTION_PASSWORD</code>. Dejarla en blanco equivale a un keyfile <code>--kdf none</code> (sin passphrase). Ambas ramas se ejecutan solo tras confirmar la passphrase de recuperación — cancelar cualquier diálogo antes de ese punto deja el disco intacto.",
+    "glossaryHint": "En esta sección aparecen los términos <em>clave</em>, <em>passphrase</em> y <em>sobre de recuperación</em>. Si en algún momento cuesta seguir cuál es cuál, el <glosarioLink>glosario</glosarioLink> 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. Sin esa clave, las copias no pueden descifrarse. ProxMenux añade una salvaguarda: cuando se activa el cifrado obliga a definir una <strong>passphrase de recuperación</strong>. Esa passphrase no protege la clave local (que ya vive en el host), sino una copia cifrada de la clave que ProxMenux sube al propio PBS, para poder recuperarla si el host se pierde o se reinstala.",
+    "keyfileTitle": "La clave de cifrado (keyfile)",
+    "keyfileBody": "El diálogo pregunta primero si se quiere cifrar la copia. Si se responde <em>No</em>, la copia continúa sin cifrado. Si se responde <em>Sí</em>, ProxMenux comprueba si el host ya tiene una clave instalada: en ese caso la reutiliza sin más preguntas; si no la tiene, ofrece dos opciones. <em>Generar una clave nueva</em> crea una clave sin contraseña, para que las copias programadas puedan ejecutarse automáticamente sin diálogos. <em>Importar una clave existente</em> permite indicar la ruta de una clave ya generada —por ejemplo la clave común de una flota de hosts—; en ese caso el diálogo pide también la contraseña de esa clave y la guarda cifrada en el host para reutilizarla en cada copia. Cualquiera de las dos opciones se ejecuta solo después de confirmar la passphrase de recuperación; cancelar el diálogo antes de ese punto no deja nada en disco.",
     "modesTitle": "Keyfile por host o compartido",
     "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": "Keyfile por host (por defecto)",
-    "modesPerHostBody": "Cada host genera su propio keyfile la primera vez que activa el cifrado PBS. El aislamiento es máximo: comprometer el keyfile de un host no expone las copias de ningún otro. Cada host tiene su propio blob de recuperación emparejado en PBS, restaurable con la passphrase de recuperación de ese host. Recomendado para flotas de producción y para entornos donde los hosts tienen propietarios o límites de compliance distintos.",
-    "modesSharedTitle": "Keyfile compartido (importar en cada host)",
-    "modesSharedBody": "Un keyfile maestro generado una vez e instalado en cada host mediante la opción <em>Importar</em>. La gestión es más simple: un único secreto que proteger, un único blob de recuperación sirve para todos los hosts, y cualquier host puede desencriptar los archives de cualquier otro (útil para consolidación, simulacros de restore cruzado o verificación centralizada de backups). El trade-off es que una filtración del keyfile compartido expone todos los hosts a la vez. Recomendado para homelabs y para flotas donde todos los hosts tienen el mismo propietario y límite de confianza.",
-    "recoveryTitle": "Passphrase de recuperación y blob de escrow",
-    "recoveryBody": "La passphrase de recuperación se solicita ANTES de escribir ningún keyfile en disco. ProxMenux la pide dos veces con validación de coincidencia; solo cuando el operador la confirma, se crea (o importa) el keyfile y <code>openssl</code> produce <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> como respaldo offsite. Cancelar el diálogo de la passphrase deja el disco intacto — no se crea ningún keyfile y no hay nada que limpiar.",
+    "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. Cada host guarda además su propio sobre de recuperación en PBS, que se abre con la passphrase de recuperación de ese host. 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>Importar</em>. La gestión es más sencilla: hay un solo secreto que proteger, un solo sobre de recuperación válido para todos los hosts, y cualquier host puede leer las copias de cualquier otro (útil para verificar copias desde una máquina distinta o para ejercicios de restauración cruzada). 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": "Passphrase de recuperación y sobre cifrado",
+    "recoveryBody": "La passphrase de recuperación se pide ANTES de generar o importar ninguna clave. ProxMenux la solicita dos veces y comprueba que coincidan; solo entonces crea la clave y produce el sobre de recuperación, que consiste en la propia clave cifrada con esa passphrase. Se guarda además una copia local del sobre en <code>/root/</code>, con el nombre del host y la fecha, pensada como respaldo externo (para llevarla a otro medio). Si se cancela el diálogo de la passphrase, no se crea nada: el host queda exactamente como estaba.",
     "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.",
+    "blobUploadBody1": "Tras una copia cifrada, ProxMenux sube el sobre de recuperación a PBS como un segundo grupo de copia, con el mismo nombre que el del host pero terminado en <code>-keyrecovery</code>. Así aparecen los dos juntos en el listado del datastore, uno con las copias del host y otro con los sobres de recuperación. <strong>El sobre nunca sale del host en claro</strong>: antes de subirse, ProxMenux lo transforma en el propio host en un fichero cifrado con AES-256-CBC, usando una clave derivada de la passphrase de recuperación mediante PBKDF2 con 600 000 iteraciones y sal aleatoria (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS recibe únicamente el sobre ya cifrado, y solo se sube cuando la copia principal ha ido cifrada.",
+    "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.",
+    "blobUploadConstraintTitle": "Por qué dos grupos y no uno solo cifrado",
+    "blobUploadConstraintBody": "Una misma subida de <code>proxmox-backup-client backup</code> 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 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."
+    "recoverTitle": "Recuperación en un equipo recién instalado",
+    "recoverBody": "Si se intenta restaurar en un equipo que no tiene todavía la clave de cifrado —por ejemplo tras reinstalar el host desde cero—, ProxMenux consulta los grupos de recuperación del PBS configurado, descarga el sobre más reciente y pide la passphrase de recuperación. Al confirmarla, la clave queda instalada en el host y la copia cifrada ya puede restaurarse con normalidad. Sin la clave y sin la passphrase, la copia cifrada no puede recuperarse."
   },
   "restoreAccess": {
     "heading": "Recuperación del lado de la restauración",

web/messages/es/docs/backup-restore/glossary.json

@@ -0,0 +1,238 @@
+{
+  "meta": {
+    "title": "Glosario de términos — Backup & Restore | ProxMenux",
+    "description": "Glosario de términos y definiciones en español para el sistema de copia y restauración de ProxMenux: cifrado, clave, passphrase, sobre de recuperación, PBS, chunks, rootfs, manifiesto, runner y hidratación cross-kernel.",
+    "ogTitle": "Glosario de Backup & Restore | ProxMenux",
+    "ogDescription": "Definiciones claras en español para los términos que aparecen en la documentación de copia y restauración de ProxMenux.",
+    "twitterTitle": "Glosario Backup & Restore | ProxMenux",
+    "twitterDescription": "Passphrase, keyfile, sobre de recuperación, rootfs, manifiesto, PBS, chunks — todo definido en español."
+  },
+  "header": {
+    "title": "Glosario",
+    "description": "Términos que aparecen a lo largo de la documentación de copia y restauración, con su definición.",
+    "section": "Backup & Restore"
+  },
+  "intro": {
+    "body": "Los términos están agrupados por temas. Cada entrada incluye una definición breve."
+  },
+  "groups": [
+    {
+      "title": "Cifrado y recuperación de clave",
+      "intro": "Terminología del bloque de cifrado de copias en PBS. Incluye dos secretos distintos: una clave binaria y una passphrase escrita.",
+      "entries": [
+        {
+          "id": "passphrase-recuperacion",
+          "term": "Passphrase de recuperación",
+          "also": "recovery passphrase",
+          "def": "Contraseña de texto que elige el operador para proteger el <a href=\"#sobre-recuperacion\">sobre de recuperación</a>. Se pide dos veces con validación de coincidencia y solo se usa para cifrar el sobre y para descifrarlo si algún día hay que recuperar la clave. <strong>No sirve para desbloquear la clave del keyfile</strong> ni se envía nunca a PBS. Nunca sale del host durante una copia normal."
+        },
+        {
+          "id": "clave-cifrado",
+          "term": "Clave de cifrado (keyfile)",
+          "also": "keyfile, PBS encryption key",
+          "def": "Fichero binario que Proxmox Backup Server utiliza para cifrar los <a href=\"#chunk\">chunks</a> de la copia antes de subirlos. Sin ese fichero, ninguna copia cifrada puede leerse. ProxMenux lo guarda en <code>/usr/local/share/proxmenux/pbs-key.conf</code> con permisos <code>600</code>. Es el activo que hay que proteger; el <a href=\"#sobre-recuperacion\">sobre de recuperación</a> existe precisamente para poder rescatar este fichero si se pierde."
+        },
+        {
+          "id": "contrasena-keyfile",
+          "term": "Contraseña de la clave (KDF passphrase)",
+          "also": "keyfile passphrase, scrypt passphrase",
+          "def": "Contraseña opcional que puede llevar la propia clave, distinta de la <a href=\"#passphrase-recuperacion\">passphrase de recuperación</a>. Solo aparece si la clave se creó con <code>--kdf scrypt</code> (una clave importada de otro sitio, por ejemplo). Sin ella, la clave no se puede desbloquear en cada uso. ProxMenux la persiste cifrada en el host para que las copias programadas puedan ejecutarse sin diálogo interactivo."
+        },
+        {
+          "id": "sobre-recuperacion",
+          "term": "Sobre de recuperación",
+          "also": "recovery envelope, escrow blob, pbs-key.recovery.enc",
+          "def": "La propia <a href=\"#clave-cifrado\">clave de cifrado</a> envuelta en una capa adicional: se cifra con la <a href=\"#passphrase-recuperacion\">passphrase de recuperación</a> mediante <a href=\"#aes-256-cbc\">AES-256-CBC</a> y <a href=\"#pbkdf2\">PBKDF2</a> antes de salir del host. Es lo que se sube a PBS en el grupo <code>-keyrecovery</code> y lo que se guarda además en <code>/root/pbs-key.recovery-HOSTNAME-FECHA.enc</code> como respaldo local. Sin la passphrase, el sobre es opaco: descargarlo desde PBS no revela la clave."
+        },
+        {
+          "id": "cifrado-cliente",
+          "term": "Cifrado del lado del cliente",
+          "also": "client-side encryption",
+          "def": "Modelo en el que los datos se cifran en el host de origen antes de subirse. PBS solo recibe y almacena datos cifrados; ni siquiera un administrador de PBS con acceso al datastore puede leerlos sin la clave. ProxMenux se apoya en este modelo y añade el <a href=\"#sobre-recuperacion\">sobre de recuperación</a> encima."
+        },
+        {
+          "id": "kdf-none",
+          "term": "--kdf none",
+          "also": "clave sin contraseña",
+          "def": "Opción de <code>proxmox-backup-client key create</code> que genera una clave sin contraseña asociada. La clave se puede usar directamente sin ningún diálogo, lo que es imprescindible para que los trabajos programados corran de forma desatendida. Es lo que ProxMenux usa por defecto al generar una clave nueva."
+        },
+        {
+          "id": "kdf-scrypt",
+          "term": "--kdf scrypt",
+          "also": "clave con contraseña",
+          "def": "Opción de <code>proxmox-backup-client key create</code> que genera una clave protegida con una <a href=\"#contrasena-keyfile\">contraseña de la clave</a>. Cada vez que se usa la clave hay que desbloquearla con esa contraseña. ProxMenux acepta este tipo de claves al importarlas y guarda la contraseña cifrada para que las copias programadas puedan correr sin intervención."
+        },
+        {
+          "id": "aes-256-cbc",
+          "term": "AES-256-CBC",
+          "def": "Algoritmo de cifrado simétrico estándar. ProxMenux lo utiliza (vía <code>openssl enc -aes-256-cbc</code>) para envolver la <a href=\"#clave-cifrado\">clave de cifrado</a> con la <a href=\"#passphrase-recuperacion\">passphrase de recuperación</a> y producir el <a href=\"#sobre-recuperacion\">sobre</a>."
+        },
+        {
+          "id": "pbkdf2",
+          "term": "PBKDF2",
+          "def": "Función criptográfica que transforma una contraseña escrita por una persona en una clave binaria adecuada para cifrar datos. Encarece los intentos de fuerza bruta aplicando muchas iteraciones. ProxMenux la usa con 600 000 iteraciones y sal aleatoria cuando cifra el sobre de recuperación."
+        }
+      ]
+    },
+    {
+      "title": "Estructura de la copia",
+      "intro": "Términos que describen lo que hay dentro de una copia, sea cual sea el destino.",
+      "entries": [
+        {
+          "id": "rootfs",
+          "term": "rootfs / sistema de archivos raíz",
+          "def": "Copia plana del sistema de ficheros del host de origen, producida por <code>rsync</code> sobre el <a href=\"#perfil-defecto\">perfil por defecto</a> más cualquier <a href=\"#rutas-personalizadas\">ruta personalizada</a>. No es una imagen del disco entero: solo se copian las rutas que contienen configuración o estado que Proxmox no puede regenerar por sí solo."
+        },
+        {
+          "id": "manifiesto",
+          "term": "Manifiesto (manifest.json)",
+          "def": "Documento JSON estructurado que describe el host de origen en el momento de la copia: hardware, almacenamiento, kernel, componentes instalados por ProxMenux e inventario de VMs y LXCs. Lo genera ProxMenux con seis colectores independientes. La restauración lo utiliza para comparar origen y destino."
+        },
+        {
+          "id": "staging",
+          "term": "Directorio de staging",
+          "def": "Directorio temporal donde ProxMenux ensambla los tres bloques (rootfs, metadata y manifiesto) antes de empaquetarlos y subirlos al destino. Se elimina automáticamente al terminar la copia, incluso si se aborta."
+        },
+        {
+          "id": "perfil-defecto",
+          "term": "Perfil por defecto",
+          "def": "Conjunto curado de rutas que ProxMenux copia por defecto en toda copia. Cubre configuración de PVE, red, SSH, kernel, apt, herramientas ProxMenux y otras. Está definido en el código y se documenta en la página <em>Cómo funciona</em>."
+        },
+        {
+          "id": "rutas-personalizadas",
+          "term": "Rutas personalizadas (custom paths)",
+          "def": "Rutas adicionales que el usuario añade al <a href=\"#perfil-defecto\">perfil por defecto</a>. Pueden ser persistentes (guardadas en <code>backup-extra-paths.txt</code>) o puntuales para una sola ejecución (marcadas en modo Custom)."
+        }
+      ]
+    },
+    {
+      "title": "Destinos y almacenamiento",
+      "intro": "Términos ligados al lugar donde acaba la copia — servidor PBS, archivo local o repositorio Borg — y a la forma en que PBS organiza los datos.",
+      "entries": [
+        {
+          "id": "repositorio-pbs",
+          "term": "Repositorio PBS",
+          "def": "Combinación de servidor Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + usuario al que se suben las copias. Se identifica con el formato <code>usuario@realm@host:datastore</code>. Un mismo servidor PBS puede alojar varios repositorios."
+        },
+        {
+          "id": "datastore",
+          "term": "Datastore",
+          "def": "Almacén concreto dentro de un servidor PBS donde se guardan las copias y sus chunks. Cada datastore vive sobre un sistema de ficheros del servidor PBS y tiene sus propios permisos y políticas."
+        },
+        {
+          "id": "chunk",
+          "term": "Chunk / deduplicación por chunks",
+          "def": "PBS divide cada copia en trozos (chunks) de tamaño variable, identifica cada trozo por su hash y solo guarda cada trozo una vez, aunque aparezca en muchas copias distintas. Esto hace que copias sucesivas del mismo host o entre hosts similares consuman muy poco espacio adicional."
+        },
+        {
+          "id": "fingerprint",
+          "term": "Fingerprint (huella)",
+          "def": "Huella criptográfica del certificado TLS del servidor PBS. Sirve para verificar que se está hablando con el servidor correcto sin depender de una autoridad certificadora pública. ProxMenux la pasa a <code>proxmox-backup-client</code> vía la variable <code>PBS_FINGERPRINT</code>."
+        },
+        {
+          "id": "grupo-copia",
+          "term": "Grupo de copia (backup group)",
+          "def": "Contenedor lógico dentro de PBS bajo el cual se acumulan todas las copias sucesivas del mismo activo. Cada nueva copia comparte deduplicación con las anteriores del mismo grupo. ProxMenux utiliza dos grupos por host cuando hay cifrado: uno para la copia del host y otro con sufijo <code>-keyrecovery</code> para el <a href=\"#sobre-recuperacion\">sobre de recuperación</a>."
+        },
+        {
+          "id": "backup-id",
+          "term": "Backup ID",
+          "def": "Nombre del <a href=\"#grupo-copia\">grupo de copia</a>. ProxMenux propone por defecto <code>hostcfg-HOSTNAME</code> y permite editarlo antes de la subida; los caracteres no admitidos se limpian automáticamente."
+        },
+        {
+          "id": "pxar",
+          "term": ".pxar",
+          "def": "Formato de archivo propio de PBS para directorios. Actúa como un tar optimizado para la deduplicación por chunks: en lugar de almacenar un fichero opaco, PBS descompone su contenido en chunks reusables."
+        }
+      ]
+    },
+    {
+      "title": "Ejecución y programación",
+      "intro": "Términos del sistema de trabajos programados de ProxMenux.",
+      "entries": [
+        {
+          "id": "runner",
+          "term": "Runner",
+          "def": "Script <code>run_scheduled_backup.sh</code> que ejecuta una copia programada. Lee la configuración del trabajo, lanza el backend correspondiente (Local, PBS o Borg), aplica la retención al terminar y envía las notificaciones configuradas."
+        },
+        {
+          "id": "trabajo-programado",
+          "term": "Trabajo programado",
+          "def": "Configuración persistida de una copia recurrente. Incluye destino, credenciales, cifrado, horario y retención. Se guarda en <code>/var/lib/proxmenux/backup-jobs/&lt;id&gt;.env</code>."
+        },
+        {
+          "id": "modo-adjunto",
+          "term": "Modo adjunto (attach mode)",
+          "def": "Trabajo programado que no lleva horario propio; se dispara automáticamente cada vez que una tarea <code>vzdump</code> de PVE existente se ejecuta. Hereda el horario y la retención de esa tarea padre. Solo compatible con destinos Local y PBS."
+        },
+        {
+          "id": "timer-systemd",
+          "term": "Timer systemd",
+          "def": "Mecanismo estándar de systemd para disparar un comando según un calendario. ProxMenux crea un timer por cada trabajo programado <em>independiente</em> (no adjunto); los trabajos adjuntos no usan timer porque se disparan desde el <a href=\"#modo-adjunto\">script-hook de PVE</a>."
+        },
+        {
+          "id": "retencion",
+          "term": "Retención (keep-last, keep-daily…)",
+          "def": "Política que decide qué copias antiguas se conservan y cuáles se eliminan. Se define por trabajo con parámetros como <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. El runner la aplica después de cada copia exitosa."
+        }
+      ]
+    },
+    {
+      "title": "Restauración",
+      "intro": "Términos del flujo de restauración.",
+      "entries": [
+        {
+          "id": "restauracion-universal",
+          "term": "Restauración universal",
+          "def": "La restauración de ProxMenux no se limita a extraer el sistema de ficheros: consulta el manifiesto para detectar diferencias entre origen y destino, reproduce la configuración del sistema y relanza los instaladores de los componentes propios. El objetivo es reproducir el host de origen, no solo el archivo."
+        },
+        {
+          "id": "hidratacion",
+          "term": "Hidratación (cross-kernel)",
+          "def": "Pasada de restauración que funde la configuración propia del usuario del origen (tokens IOMMU, IDs de dispositivos VFIO, quirks personalizadas, claves de GRUB) sobre la configuración de arranque fresca del destino, sin copiar verbatim los ficheros ligados al kernel del origen. Se ejecuta cuando el kernel del destino es más reciente que el de la copia."
+        },
+        {
+          "id": "cross-kernel",
+          "term": "Restauración cross-kernel",
+          "def": "Restauración en la que el kernel del destino es distinto (normalmente más nuevo) que el del origen. Requiere la pasada de <a href=\"#hidratacion\">hidratación</a> para no arrastrar ficheros incompatibles con el kernel del destino."
+        },
+        {
+          "id": "instalador-postboot",
+          "term": "Instalador post-arranque",
+          "def": "Componentes que se reinstalan tras el primer arranque del host restaurado (drivers NVIDIA, drivers Coral TPU, herramientas AMD GPU, herramientas Intel GPU). Cada instalador se ejecuta contra el kernel del destino, por lo que el host restaurado no depende de que el kernel del origen esté presente."
+        },
+        {
+          "id": "compatibility-check",
+          "term": "Compatibility check",
+          "def": "Comparación entre el manifiesto del origen y el estado del destino que ProxMenux realiza al principio de la restauración. Decide qué partes se copian verbatim, cuáles necesitan hidratación y cuáles se recrean desde el instalador."
+        },
+        {
+          "id": "equipo-recien-instalado",
+          "term": "Equipo recién instalado",
+          "also": "fresh install",
+          "def": "Host acabado de reinstalar desde cero, sin la <a href=\"#clave-cifrado\">clave de cifrado</a> local. Para restaurar copias cifradas hace falta primero recuperar la clave desde el <a href=\"#sobre-recuperacion\">sobre</a> almacenado en PBS, con la <a href=\"#passphrase-recuperacion\">passphrase de recuperación</a>."
+        }
+      ]
+    }
+  ],
+  "whereNext": {
+    "heading": "Dónde seguir",
+    "items": [
+      {
+        "label": "Cómo funciona",
+        "href": "/docs/backup-restore/how-it-works",
+        "tail": " — dónde encajan el rootfs, el manifiesto y el inventario de aplicaciones en cada copia."
+      },
+      {
+        "label": "Destino Proxmox Backup Server",
+        "href": "/docs/backup-restore/destinations/pbs",
+        "tail": " — dónde se explica en profundidad el cifrado del lado del cliente, la clave, la passphrase de recuperación y el sobre."
+      },
+      {
+        "label": "Restauración",
+        "href": "/docs/backup-restore/restoring",
+        "tail": " — flujo de la restauración y uso del manifiesto."
+      }
+    ]
+  }
+}

web/messages/es/docs/backup-restore/how-it-works.json

@@ -9,12 +9,12 @@
   },
   "header": {
     "title": "Cómo funciona",
-    "description": "Desglose interno de una copia de ProxMenux — sistema de ficheros, manifiesto e inventario de aplicaciones — y cómo la restauración consume los tres para reproducir el host de origen sobre un destino que puede no compartir el mismo kernel.",
+    "description": "Desglose interno de una copia de seguridad creada con ProxMenux — sistema de ficheros, manifiesto e inventario de aplicaciones — y cómo la restauración consume los tres para reproducir el host de origen sobre un destino que puede no compartir el mismo kernel.",
     "section": "Backup & Restore"
   },
   "intro": {
     "title": "Un archivo, tres bloques",
-    "body": "Cada copia produce un layout de directorio con tres bloques bien definidos bajo una única raíz de staging. El archivo que se sube al destino (archivo local <code>.tar.zst</code>, backup PBS o archivo Borg) contiene ese layout exacto. La restauración lee los tres bloques de forma independiente, en un orden concreto que garantiza la corrección: primero se copia el <strong>rootfs</strong> para colocar la configuración, después se consulta <strong>el manifiesto</strong> para detectar drift y decidir qué omitir, y finalmente <strong>el inventario de aplicaciones</strong> dirige la pasada de reinstalación post-arranque. No hay dependencias entre bloques — cada uno puede inspeccionarse o extraerse de forma independiente."
+    "body": "Cada copia produce un layout de directorio con tres bloques bien definidos bajo una única raíz de staging. El archivo que se sube al destino (archivo local <code>.tar.zst</code>, backup PBS o archivo Borg) contiene ese layout exacto. La restauración lee los tres bloques de forma independiente, en un orden concreto que garantiza la corrección: primero se copia el <strong>rootfs</strong> —el sistema de archivos raíz del host— para colocar la configuración, después se consulta <strong>el manifiesto</strong> para detectar drift y decidir qué omitir, y finalmente <strong>el inventario de aplicaciones</strong> dirige la pasada de reinstalación post-arranque. No hay dependencias entre bloques — cada uno puede inspeccionarse o extraerse de forma independiente."
   },
   "layout": {
     "heading": "Layout del archivo",
@@ -121,7 +121,7 @@
       }
     ],
     "schemaTitle": "Validación por esquema",
-    "schemaBody": "El manifiesto valida contra <code>scripts/backup_restore/schema/manifest.schema.json</code>. Ejecutar <code>build_manifest.sh --validate</code> dispara una validación JSON Schema por Python (requiere <code>python3</code> + <code>jsonschema</code>). Si el módulo no está presente, la comprobación se omite silenciosamente — la validación es principalmente una ayuda de desarrollo, no una dependencia en tiempo de ejecución."
+    "schemaBody": "ProxMenux incluye una plantilla que describe qué campos debe contener el manifiesto y qué forma tiene cada uno. Cuando se genera una copia se puede comprobar automáticamente que el manifiesto respeta esa plantilla, de modo que si un colector produjera un JSON malformado o con un campo mal escrito se detectaría en el momento. Es una comprobación destinada al desarrollo del propio ProxMenux: si el sistema no la tiene instalada, la copia sigue funcionando con normalidad y el manifiesto se genera igual."
   },
   "applications": {
     "heading": "El inventario de aplicaciones",

web/messages/es/docs/backup-restore/index.json

@@ -38,7 +38,7 @@
   },
   "restoreIsUniversal": {
     "heading": "La restauración reproduce el host de origen, no el archivo",
-    "body": "Restaurar una copia de ProxMenux no consiste solamente en extraer el sistema de ficheros. El flujo de restauración lee el manifiesto para detectar diferencias entre origen y destino (variaciones de hardware, renombrado de NICs, versión de kernel, identidad de la pool ZFS), reproduce el sistema de ficheros y lanza el instalador correspondiente a cada servicio que estuviera instalado en el origen (controlador NVIDIA, Coral TPU, herramientas AMD GPU, herramientas Intel GPU). Cada instalador se ejecuta contra el <strong>kernel actual del destino</strong>, por lo que el host restaurado no depende de que el kernel del origen esté presente. Cuando el kernel del destino es más reciente que el de la copia, una pasada de <strong>hidratación</strong> kernel-agnóstica funde la configuración propia del usuario (tokens IOMMU, IDs de dispositivos VFIO, quirks personalizadas, claves de GRUB) sobre la configuración de arranque fresca del destino, sin copiar verbatim los ficheros ligados al kernel."
+    "body": "Restaurar una copia de seguridad no consiste solamente en extraer el sistema de ficheros. El flujo de restauración lee el manifiesto para detectar diferencias entre origen y destino (variaciones de hardware, renombrado de NICs, versión de kernel, identidad de la pool ZFS), reproduce el sistema de ficheros y lanza el instalador correspondiente a cada servicio que estuviera instalado en el origen (controlador NVIDIA, Coral TPU, herramientas AMD GPU, herramientas Intel GPU). Cada instalador se ejecuta contra el <strong>kernel actual del destino</strong>, por lo que el host restaurado no depende de que el kernel del origen esté presente. Cuando el kernel del destino es más reciente que el de la copia, una pasada de <strong>hidratación</strong> kernel-agnóstica funde la configuración propia del usuario (tokens IOMMU, IDs de dispositivos VFIO, quirks personalizadas, claves de GRUB) sobre la configuración de arranque fresca del destino, sin copiar verbatim los ficheros ligados al kernel."
   },
   "twoInterfaces": {
     "heading": "Dos interfaces, un único backend",

web/messages/es/docs/backup-restore/scheduled-jobs.json

@@ -24,6 +24,10 @@
     "title": "Modo adjunto — recomendado cuando ya existe una tarea vzdump de PVE",
     "body": "Cuando ya hay una tarea de copia vzdump de PVE configurada para las VMs y los LXCs de este nodo, adjuntar la copia de host a esa tarea garantiza que la configuración del host se captura en la <strong>misma ventana</strong> que los invitados. En la restauración, las configuraciones de los invitados vienen de la copia de host (viven bajo <code>/etc/pve</code>), y los discos de los invitados vienen de la copia vzdump tomada al mismo tiempo — ambos conjuntos son consistentes entre sí, por lo que una recuperación completa del nodo puede reproducir el host y re-adjuntar cada invitado sin drift de versiones."
   },
+  "frequencyBadge": {
+    "title": "Frecuencia recomendada",
+    "body": "Para garantizar la máxima compatibilidad entre la copia y su posterior restauración se recomienda hacer copias de seguridad del host con frecuencia. Cuanto más reciente sea la copia respecto al estado actual del host, menor será la desviación de configuración, paquetes y componentes que la restauración tendrá que reconciliar."
+  },
   "modes": {
     "heading": "Los dos modos",
     "rows": [