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

{
  "meta": {
    "title": "Proxmox Backup Server destination — repository, encryption, recovery | ProxMenux",
    "description": "The PBS destination writes ProxMenux host backups as PBS backups. Documents repository auto-discovery from /etc/pve/storage.cfg, manual PBS configuration, the .pxar upload command, the client-side keyfile encryption model with optional passphrase-wrapped escrow, and the multi-source keyfile recovery on a fresh host.",
    "ogTitle": "ProxMenux Backup — Proxmox Backup Server destination",
    "ogDescription": "How ProxMenux writes host backups to Proxmox Backup Server with client-side keyfile encryption and recovery escrow.",
    "twitterTitle": "PBS backup destination | ProxMenux",
    "twitterDescription": "Proxmox Backup Server destination with keyfile encryption and recovery passphrase escrow."
  },
  "header": {
    "title": "Proxmox Backup Server",
    "description": "The PBS destination uploads the staging root as a single .pxar backup to a Proxmox Backup Server datastore, with optional client-side keyfile encryption and an optional passphrase-wrapped keyfile escrow uploaded next to each backup.",
    "section": "Backup & Restore"
  },
  "recommendedBadge": "Recommended destination",
  "aboutPbs": {
    "heading": "What Proxmox Backup Server is",
    "body": "Proxmox Backup Server (PBS) is Proxmox's own backup server product, developed and maintained by the same team that authors Proxmox VE. It is a dedicated backup server designed to receive backups from Proxmox VE hosts (VMs, LXCs and — via <code>proxmox-backup-client</code> — arbitrary host directories) with chunk-based deduplication, client-side encryption, and retention policies applied server-side. ProxMenux uses PBS as one of the three destinations for host backups; every PBS-specific mechanism described on this page (backup groups, <code>.pxar</code> archives, <code>--backup-id</code>, keyfile encryption) is standard PBS behaviour."
  },
  "intro": {
    "title": "One backup per run, chunk-level dedup",
    "body": "A PBS backup produces a single backup entry in the datastore, grouped under the backup ID <code>host/hostcfg-HOSTNAME/BACKUP-TIME</code>. The payload is a <code>.pxar</code> archive containing the same three-block layout described in <em>How it works</em>. PBS deduplicates at the chunk level across all backups in the datastore, so subsequent backups of the same host transfer and store only the chunks that changed. Retention is applied by ProxMenux itself for scheduled jobs — <code>run_scheduled_backup.sh</code> runs <code>proxmox-backup-client prune</code> with <code>--keep-last</code> / <code>--keep-daily</code> / <code>--keep-weekly</code> after each successful run using the values configured on the job."
  },
  "repoSelection": {
    "heading": "Repository selection",
    "intro": "ProxMenux discovers PBS repositories from two sources on every backup. The user picks one from a unified menu; for that run, the choice determines which server and datastore the backup is sent to, the password it authenticates with and the <em>fingerprint</em> that validates the certificate.",
    "sourceRows": [
      {
        "source": "Proxmox storage.cfg (auto-discovered)",
        "path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
        "content": "Any <code>pbs:</code> stanza in Proxmox's own storage config is picked up automatically. Server, datastore, username and fingerprint come from the stanza. The password is read from Proxmox's own credentials directory. No re-entry needed on the ProxMenux side — the repository is available as soon as it is configured in Proxmox."
      },
      {
        "source": "ProxMenux manual config",
        "path": "/usr/local/share/proxmenux/pbs-manual-configs.txt + pbs-pass-NAME.txt + pbs-fingerprint-NAME.txt",
        "content": "Added from <em>Configure backup destinations → PBS destinations → Add PBS</em>. Prompts for a name, username (<code>root@pam</code> or <code>user@pbs!token</code>), host or IP, datastore and password. The password re-prompts on empty input — an empty save would otherwise persist silently and every subsequent backup would fail with an opaque authentication error. This path is used when the target PBS is not registered as Proxmox storage."
      }
    ],
    "menuTitle": "Selection menu",
    "menuBody": "Both sources are shown in a single menu, each row tagged with its origin (<code>[proxmox]</code> or <code>[manual]</code>). Entries whose password could not be resolved are tagged with a <code>⚠ no password</code> warning — selecting one triggers a password re-entry before the backup starts. The fingerprint is passed to <code>proxmox-backup-client</code> via the <code>PBS_FINGERPRINT</code> environment variable; when absent, the client asks the user to accept the server certificate interactively on the first backup."
  },
  "backupCommand": {
    "heading": "The backup command",
    "intro": "The upload is a single invocation of <code>proxmox-backup-client backup</code>. ProxMenux uses <code>env</code> to pass the password, encryption password and fingerprint to the client as environment variables.",
    "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": "Backup ID naming",
    "backupIdBody": "The default backup ID is <code>hostcfg-HOSTNAME</code>. The user is asked to confirm or edit it before the upload; any characters outside <code>[A-Za-z0-9_-]</code> are stripped and trailing dashes are trimmed. Reusing the same ID across runs is intentional — PBS treats the ID as a <em>group</em>, and every subsequent backup appears as a new backup inside that group, sharing dedup with prior runs.",
    "pxarTitle": "Why the source is the full staging root",
    "pxarBody": "The <code>.pxar</code> archive packs the whole working directory: the host filesystem (<code>rootfs/</code>), the metadata (<code>metadata/</code>) and the manifest (<code>manifest.json</code>). On restore, ProxMenux compares the manifest with the target host to tell whether they are equivalent, whether the hardware changed or whether it is a different machine, and adjusts the process accordingly. Older backups, made by earlier ProxMenux versions that packed only the filesystem, still restore correctly: the restore detects that legacy format and rearranges it automatically."
  },
  "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, whether to also upload a passphrase-wrapped copy of the keyfile to PBS as a recovery escrow is an explicit yes/no choice the user 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 user 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",
    "modesIntro": "Both operating models are supported and neither is enforced — the choice belongs to the user based on how their fleet is organised.",
    "modesPerHostTitle": "Per-host keyfile (default)",
    "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 user decides",
    "recoveryBody": "Right after the keyfile is chosen, ProxMenux asks a single explicit question — <em>Upload key to PBS?</em> — with two answers. <strong>No recovery artifact is uploaded to PBS until the operator answers Yes.</strong> The default is <em>No, keep local only</em>: the keyfile stays at the canonical local path, ProxMenux uploads no recovery artifact to PBS, 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 is sent to PBS during these uploads. 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 answer 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?",
    "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 user 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 the PBS client 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 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 user is asked for the recovery passphrase to decrypt it. Third, when neither of the above works or the user 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 user can identify which keyfile to import to open that specific backup.",
    "monitorManagementTitle": "Managing the keyfile from the Monitor",
    "monitorManagementBody": "The Monitor shows the keyfile controls in each PBS destination row of the backup configuration page. The row has three actions: <em>Download</em> exports the current keyfile to the user's browser, <em>Upload</em> replaces the installed keyfile with one supplied by the user (the previous file is overwritten only after the new one has arrived correctly at its path), and <em>Delete</em> removes the keyfile from the host. Right next to them is the switch of the recovery envelope: a Yes/No for <em>Upload key to PBS?</em>, a passphrase field that appears when Yes is selected, and a button that follows the current state: <em>Start uploading</em>, <em>Stop uploading</em> or <em>Update passphrase</em>. The Monitor controls and the shell dialog do the same underneath, so the result on disk and on PBS is identical whichever one is used."
  },
  "restoreAccess": {
    "heading": "Retrieval on the restore side",
    "body": "The restore flow discovers ProxMenux host backups on PBS by listing backup groups under the configured repository and filtering by backup ID pattern. The Monitor's Backups tab renders the same list. Selecting a backup triggers <code>proxmox-backup-client restore</code> with the same repository + password + fingerprint (and <code>--keyfile</code> when the backup was encrypted), extracting the <code>.pxar</code> into a staging directory that <code>_rs_check_layout</code> then feeds to the standard restore pipeline. For manual retrieval outside ProxMenux, the same command extracts the archive to any path — the resulting tree can be inspected or fed to a hand-driven restore."
  },
  "references": {
    "heading": "References",
    "intro": "Official Proxmox Backup Server documentation for the components ProxMenux relies on.",
    "items": [
      {
        "label": "Proxmox Backup Server documentation",
        "href": "https://pbs.proxmox.com/docs/",
        "tail": " — main entry point covering installation, administration, storage, users and roles."
      },
      {
        "label": "proxmox-backup-client",
        "href": "https://pbs.proxmox.com/docs/backup-client.html",
        "tail": " — the command-line tool ProxMenux invokes for every backup and restore. Covers backup IDs, backup types, archives, repository syntax and environment variables."
      },
      {
        "label": "Client-side encryption",
        "href": "https://pbs.proxmox.com/docs/backup-client.html#encryption",
        "tail": " — keyfile creation, --kdf modes, the encryption model that ProxMenux extends with a passphrase escrow."
      },
      {
        "label": "Datastore management",
        "href": "https://pbs.proxmox.com/docs/storage.html",
        "tail": " — creating and managing the datastores that receive host backups, including chunk-store layout and permissions."
      },
      {
        "label": "Pruning and garbage collection",
        "href": "https://pbs.proxmox.com/docs/maintenance.html#pruning",
        "tail": " — the retention model behind --keep-last / --keep-daily / --keep-weekly that ProxMenux applies per scheduled job, plus how PBS reclaims chunks after prune."
      }
    ]
  }
}