Merge pull request #477 from jcastro/docs/review-backup-restore

docs: review backup and restore documentation in all seven translations

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

@@ -0,0 +1,220 @@
+{
+  "meta": {
+    "title": "Création de sauvegardes — flux de sauvegarde interactif ProxMenux",
+    "description": "Le processus de sauvegarde interactif de ProxMenux : deux points d’entrée (le menu TUI de Scripts et l’interface web de Monitor), trois destinations, deux modes de profil, une étape de préparation temporaire et une boîte de dialogue de confirmation. Cette page décrit la matrice de six options, les profils par défaut et personnalisé, et ce que voit l’utilisateur entre le choix d’une sauvegarde et l’enregistrement de l’archive à destination.",
+    "ogTitle": "Sauvegarde ProxMenux — création de sauvegardes",
+    "ogDescription": "Le processus de sauvegarde interactif avec trois destinations, deux profils et une étape commune de préparation temporaire.",
+    "twitterTitle": "Création de sauvegardes ProxMenux",
+    "twitterDescription": "Flux de sauvegarde interactif avec trois destinations et deux modes de profil."
+  },
+  "header": {
+    "title": "Création de sauvegardes",
+    "description": "Le processus de sauvegarde interactif : choisissez une destination et un profil, vérifiez le récapitulatif de confirmation et suivez l’enregistrement de l’archive. Les deux points d’entrée partagent le même backend et produisent des archives identiques.",
+    "section": "Sauvegarde et restauration"
+  },
+  "intro": {
+    "title": "Deux points d'entrée, fonctionnalité identique",
+    "body": "La TUI de Scripts et l’interface web de Monitor offrent <strong>exactement les mêmes fonctions</strong>. Chaque sauvegarde — manuelle ou programmée — utilise la même matrice de choix (trois destinations × deux profils) et appelle la même fonction backend par cellule (<code>_bk_pbs</code>, <code>_bk_borg</code> ou <code>_bk_local</code>). Les archives produites depuis les deux points d’entrée sont identiques. Le choix dépend des préférences : la TUI se prête à SSH et aux scripts ; Monitor permet une utilisation à la souris et regroupe les vues des notifications et du suivi des journaux."
+  },
+  "entryPoints": {
+    "heading": "Les deux points d'entrée",
+    "rows": [
+      {
+        "entry": "ProxMenux Scripts (TUI)",
+        "path": "menu → Utilities → Host Config Backup",
+        "detail": "Processus fondé sur des boîtes de dialogue, adapté à SSH. Le menu principal présente directement les six options. Utilise <code>backup_menu</code> dans <code>backup_host.sh</code>."
+      },
+      {
+        "entry": "ProxMenux Monitor (interface utilisateur Web)",
+        "path": "Backups tab → Create backup",
+        "detail": "Processus guidé par un assistant. Les six mêmes options sont présentées dans un formulaire en deux étapes (destination → profil). Les mêmes fonctions backend sont appelées via l’API Flask."
+      }
+    ]
+  },
+  "modes": {
+    "heading": "Sauvegardes manuelles ou programmées",
+    "body": "Les sauvegardes peuvent être produites en deux modes : <strong>manuel</strong> (le processus interactif décrit sur cette page — l'utilisateur choisit une destination et un profil à partir d'un menu et suit l’enregistrement de l’archive) ou <strong>programmé</strong> (un travail sans surveillance qui fonctionne sur un minuteur de style cron et applique la rétention configurée sur le travail). Les deux modes supportent les mêmes trois destinations et les mêmes deux profils, et les deux sont disponibles à partir des deux points d'entrée — le menu Scripts TUI et l'onglet Sauvegardes Monitor. Les tâches programmées utilisent les mêmes fonctions de backend que le flux manuel à travers <code>run_scheduled_backup.sh</code> ; les archives produites sont indistinguables.",
+    "seeAlso": "La page des tâches programmées décrit tout le processus, notamment la création d’une tâche, son association à un minuteur vzdump PVE existant et la configuration des valeurs de rétention.",
+    "monitorAlt": "L'onglet Sauvegardes ProxMenux Monitor affiche la boîte de dialogue Nouvelle sauvegarde programmée avec les champs destination, profil, calendrier et conservation.",
+    "monitorCaption": "Sauvegarde programmée — ProxMenux Monitor. La même boîte de dialogue de style assistant qui crée une sauvegarde manuelle porte les champs de planning et de rétention en bas pour le chemin sans surveillance."
+  },
+  "matrix": {
+    "heading": "La matrice de six options",
+    "intro": "Le choix détermine le backend exécuté et la stratégie de sélection des chemins. Consultez les pages de chaque destination pour connaître les détails de configuration de chaque cellule.",
+    "rows": [
+      {
+        "combo": "1",
+        "destination": "PBS",
+        "profile": "Par défaut",
+        "action": "Envoie le profil par défaut et les ajouts persistants vers un dépôt PBS configuré."
+      },
+      {
+        "combo": "2",
+        "destination": "Borg",
+        "profile": "Par défaut",
+        "action": "Crée une archive avec le profil par défaut plus des extras persistants dans le dépôt Borg sélectionné."
+      },
+      {
+        "combo": "3",
+        "destination": "Locale",
+        "profile": "Par défaut",
+        "action": "Écrit une archive <code>.tar.zst</code> avec le profil par défaut et des suppléments persistants à la cible locale configurée."
+      },
+      {
+        "combo": "4",
+        "destination": "PBS",
+        "profile": "Personnalisé",
+        "action": "Ouvre le sélecteur de chemins avant l’envoi vers PBS ; l’utilisateur coche les chemins et peut en ajouter."
+      },
+      {
+        "combo": "5",
+        "destination": "Borg",
+        "profile": "Personnalisé",
+        "action": "Ouvre le sélecteur de chemin avant la création de l'archive Borg."
+      },
+      {
+        "combo": "6",
+        "destination": "Locale",
+        "profile": "Personnalisé",
+        "action": "Ouvre le sélecteur de chemin avant d'écrire le <code>.tar.zst</code> local."
+      }
+    ]
+  },
+  "profiles": {
+    "heading": "Profil par défaut vs personnalisé",
+    "defaultTitle": "Profil par défaut",
+    "defaultBody": "Le profil par défaut est la liste prédéfinie de <code>hb_default_profile_paths</code> (documentée dans <em>Comment ça marche</em> sous <em>Catégories de chemins</em>) plus chaque entrée dans le fichier supplémentaire persistant <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code>. L'utilisateur confirme les options de destination et de chiffrement et la sauvegarde se déroule sans autre sélection de chemin.",
+    "customTitle": "Profil personnalisé",
+    "customBody": "Le profil personnalisé ouvre une liste à cocher avec tous les chemins du profil par défaut (décochés) et tous les ajouts persistants (précochés, avec le préfixe <code>[+]</code>). L’utilisateur coche les chemins pour cette exécution et peut cliquer sur <em>Ajouter un chemin personnalisé</em> pour ajouter un chemin absolu. Tout chemin ainsi ajouté est enregistré dans <code>backup-extra-paths.txt</code> afin que les sauvegardes suivantes l’incluent automatiquement. Décocher un ajout persistant l’exclut de cette exécution sans le supprimer du fichier — la suppression se fait séparément par <em>Gérer les chemins personnalisés</em>, en dehors du processus de sauvegarde.",
+    "customPickerAlt": "Liste de contrôle de profil personnalisé montrant les chemins de profil par défaut (non coché) et les extras persistants (pré coché avec un préfixe [+]), ainsi que des boutons pour ajouter un nouveau chemin ou confirmer la sélection.",
+    "customPickerCaption": "Profil personnalisé — le sélecteur de chemins. Les chemins du profil par défaut sont décochés ; les ajouts persistants sont précochés avec le préfixe [+]. L’utilisateur coche les chemins pour cette exécution.",
+    "manageCustomAlt": "Menu de gestion des chemins personnalisés montrant les ajouts persistants et les options pour les ajouter, les supprimer ou les modifier.",
+    "manageCustomCaption": "Gérer les chemins personnalisés — le point d'entrée où des extras persistants sont ajoutés ou supprimés. Chaque chemin listé ici est automatiquement inclus dans les sauvegardes en mode Défaut sans avoir à ouvrir le sélecteur personnalisé."
+  },
+  "commonPipeline": {
+    "heading": "Ce qui s’exécute quelle que soit la destination",
+    "intro": "Une fois le profil défini, chaque backend suit le même processus de préparation temporaire avant de passer à sa propre méthode d’envoi. <code>hb_prepare_staging</code> assemble l’arborescence de l’archive dans <code>/tmp/proxmenux-DESTINATION-stage.XXXXXX</code> et remplit chacun des trois blocs de données.",
+    "steps": [
+      {
+        "step": "1",
+        "name": "Assemblage du rootfs",
+        "detail": "Exécute <code>rsync -a</code> pour chaque chemin sélectionné dans <code>staging_root/rootfs/</code>. La base de données pmxcfs de <code>/var/lib/pve-cluster/config.db</code> est capturée séparément via <code>sqlite3 .backup</code> pour produire un instantané cohérent sans arrêter le cluster, et les sidecars <code>.db-wal</code> / <code>.db-shm</code> sont exclus du rsync; lorsque <code>sqlite3</code> n'est pas disponible, un fichier <code>config.db.raw-fallback</code> est créé puis utilisé comme base de données lors de l’importation. Les sous-chemins volatils (historique bash, caches, poubelles) sont exclus du <code>/root/</code>. Les chemins absents de la source sont enregistrés dans <code>metadata/missing_paths.txt</code> sans arrêter la sauvegarde."
+      },
+      {
+        "step": "2",
+        "name": "Génération de manifestes",
+        "detail": "<code>build_manifest.sh</code> coordonne les six collecteurs et écrit <code>manifest.json</code> à la racine du répertoire temporaire. Si un collecteur échoue, la section concernée reçoit une valeur vide par défaut documentée ; le manifeste reste valide."
+      },
+      {
+        "step": "3",
+        "name": "Inventaire des paquets",
+        "detail": "<code>apt-mark showmanual</code> est capté mot à mot dans <code>metadata/packages.manual.list</code>. L'état des composants est déjà à l'intérieur des rootfs restauré (<code>components_status.json</code>) car <code>/usr/local/share/proxmenux/</code> fait partie du profil par défaut."
+      },
+      {
+        "step": "4",
+        "name": "Informations sur l’exécution",
+        "detail": "<code>metadata/run_info.env</code> enregistre l'identité d'exécution de sauvegarde — nom d'hôte, horodatage, version du noyau — utilisée par la vérification de compatibilité de la restauration pour déterminer la direction du cross-kernel."
+      },
+      {
+        "step": "5",
+        "name": "Notification (démarrage)",
+        "detail": "<code>hb_notify_lifecycle \"start\"</code> est déclenché. Si les notifications sont configurées dans Monitor, un événement <em>Sauvegarde de l’hôte démarrée</em> est envoyé à l’utilisateur. Aucun envoi si aucun canal n’est configuré."
+      }
+    ]
+  },
+  "included": {
+    "heading": "Ce qui entre et ce qui reste en dehors",
+    "intro": "Chaque chemin dans le profil résolu (par défaut + suppléments persistants + sélection en mode personnalisé) est copié avec <code>rsync -aAXH --numeric-ids</code>. Une liste d'exclusion partagée s'applique à chaque chemin, et deux répertoires comportent d'autres exclusions spécifiques au chemin.",
+    "globalTitle": "Les exclusions globales (appliquées à chaque voie)",
+    "globalItems": [
+      "<code>images/</code> — images de disque exportées.",
+      "<code>dump/</code> — sorties vzdump.",
+      "<code>tmp/</code> — fichiers temporaires.",
+      "<code>*.log</code> — fichiers journaux."
+    ],
+    "rootTitle": "Exclusions de <code>/root/</code>",
+    "rootBody": "<code>/root/</code> fait partie du profil par défaut, de sorte que les scripts utilisateur et la configuration se trouvent dans l'archive. Les sous-chemins volatils sont abandonnés:",
+    "rootItems": [
+      "<code>.bash_history</code>",
+      "<code>.cache/</code>",
+      "<code>tmp/</code>",
+      "<code>.local/share/Trash/</code>"
+    ],
+    "proxmenuxTitle": "Exclusions de <code>/usr/local/share/proxmenux/</code>",
+    "proxmenuxBody": "Ce répertoire ne livre que l'état utilisateur — <code>components_status.json</code>, préférences, cache post-installation. Code que la destination aura déjà de sa propre installation ProxMenux est exclu de sorte qu'une restauration n'écrase pas les binaires actuels de la cible avec les plus anciens:",
+    "proxmenuxItems": [
+      "<code>restore-pending/</code>, <code>scripts/</code>, <code>web/</code>",
+      "<code>monitor-app/</code>, <code>monitor-app.*/</code>, <code>AppImage/</code>",
+      "<code>images/</code>, <code>json/</code>",
+      "<code>utils.sh</code>, <code>helpers_cache.json</code>",
+      "<code>ProxMenux-Monitor.AppImage*</code>, <code>install_proxmenux*.sh</code>"
+    ],
+    "notInProfileTitle": "Chemins en dehors du profil",
+    "notInProfileBody": "Tout ce qui n'est pas listé dans <code>hb_default_profile_paths</code> et qui n'est pas ajouté en tant qu'extra personnalisé ou persistant ne fait pas partie de la sauvegarde. Exemples notables:",
+    "notInProfileItems": [
+      "<strong>Disques des VM et des LXC</strong> — manipulés par <code>vzdump</code>, pas par cette fonctionnalité. Les fichiers de configuration invités sous <code>/etc/pve/nodes/*/qemu-server/*.conf</code> et <code>lxc/*.conf</code> sont capturés (ils vivent sous <code>/etc/pve</code>) de sorte que la restauration reproduit l'inventaire; les disques eux-mêmes sont ré-attachés à partir d'une sauvegarde existante vzdump/PBS.",
+      "<strong><code>/boot</code> et <code>/boot/efi</code></strong> — les binaires du noyau, les initramfs et la partition ESP UEFI sont régénérés par les propres <code>update-initramfs</code>, <code>update-grub</code> ou <code>proxmox-boot-tool refresh</code> après la restauration. Le chargeur de démarrage n’est jamais recopié à l’identique.",
+      "<strong>Les systèmes de fichiers de noyau et d'exécution du système</strong> — <code>/proc</code>, <code>/sys</code>, <code>/dev</code> et <code>/run</code> sont des pseudo-systèmes de fichiers produits par le noyau et l'udev; ils ne persistent nulle part.",
+      "<strong>Binaires des paquets sous <code>/usr/bin</code>, <code>/usr/lib</code>, <code>/lib</code>, <code>/sbin</code></strong> — réinstallés par APT sur la cible à partir de <code>packages.manual.list</code>.",
+      "<strong><code>/var/log/</code>, <code>/var/tmp/</code>, <code>/var/cache/</code></strong> — état d'exécution par hôte, non restauré.",
+      "<strong><code>/home/USER</code></strong> — pas dans le profil par défaut. Ajoutez-le comme un chemin personnalisé lorsqu'un système transporte des répertoires d'utilisateur qui doivent survivre à une restauration."
+    ],
+    "customPathsTitle": "Comment les chemins personnalisés sont gérés",
+    "customPathsBody": "Un chemin personnalisé ajouté en ligne en mode personnalisé ou maintenu dans <code>backup-extra-paths.txt</code> passe par le même pipeline <code>rsync</code> que les chemins de profil par défaut. Les exclusions globales s'appliquent. Si le chemin personnalisé se trouve sous <code>/root/</code> ou <code>/usr/local/share/proxmenux/</code>, les exclusions spécifiques au chemin ci-dessus s'appliquent toujours. Chaque chemin archivé — par défaut ou personnalisé — est enregistré dans <code>metadata/paths_archived.txt</code>. Les chemins qui n'existent pas sur la source sont enregistrés dans <code>metadata/missing_paths.txt</code> sans arrêter la sauvegarde."
+  },
+  "archiveStructure": {
+    "heading": "Structure des archives",
+    "intro": "Le répertoire de préparation temporaire produit par chaque moteur suit la même disposition quelle que soit la destination. L'archive tarball, PBS <code>.pxar</code> ou Borg stocke cet arbre dans son intégralité.",
+    "tree": "backup-[timestamp]/\n├── manifest.json                  # structured host state (kernel_params, hardware, storage, guests, components, source_host)\n├── metadata/\n│   ├── packages.manual.list       # output of apt-mark showmanual\n│   ├── run_info.env               # hostname, timestamp, kernel version, pmxcfs method\n│   ├── paths_archived.txt         # exact list of paths that reached rootfs/\n│   └── missing_paths.txt          # paths from the profile absent on source\n└── rootfs/\n    ├── etc/                       # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, /etc/apt, ...\n    ├── root/                      # /root without volatile subpaths\n    ├── usr/local/                 # /usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux (state only)\n    └── var/                       # /var/lib/pve-cluster (config.db via sqlite3 .backup), /var/spool/cron/crontabs"
+  },
+  "confirmation": {
+    "heading": "Résumé de la confirmation",
+    "body": "Avant que le moteur n'écrive quoi que ce soit à la destination, ProxMenux affiche une boîte de dialogue de résumé avec la destination, l’identifiant de sauvegarde ou le nom de l’archive, l'état de chiffrement et la liste des chemins copiés. Annuler ici avorte la sauvegarde proprement — le répertoire temporaire est supprimé par le gestionnaire <code>trap</code> défini dans la fonction backend et aucune donnée partielle n'arrive à destination."
+  },
+  "writing": {
+    "heading": "Écrire à la destination",
+    "intro": "Après confirmation, chaque backend exécute sa propre étape d’écriture. Les pages des destinations en décrivent le fonctionnement ; les éléments communs sont le journal, le fichier annexe et la notification de fin.",
+    "rows": [
+      {
+        "topic": "Fichier journal",
+        "detail": "Chaque moteur écrit sa sortie complète sur <code>/tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log</code> et, en cas d'échec, propose de l'ouvrir dans une boîte de dialogue défilante. Le chemin du journal n'est imprimé dans le résumé d'achèvement que lorsque le fichier contient du contenu."
+      },
+      {
+        "topic": "Sidecar (local seulement)",
+        "detail": "<code>hb_write_archive_sidecar</code> dépose un <code>*.proxmenux.json</code> à côté de l'archive locale afin que le moniteur l'identifie comme une sauvegarde d'hôte ProxMenux même après des déplacements ou des renoms."
+      },
+      {
+        "topic": "Notification (réussite/échec)",
+        "detail": "<code>hb_notify_lifecycle \"complete\"</code> ou <code>\"fail\"</code> est déclenché avec la durée, la taille de l’archive et — en cas d’échec — la dernière ligne du journal qui ressemble à une erreur."
+      }
+    ]
+  },
+  "finishedScreens": {
+    "heading": "A quoi ressemble une sauvegarde terminée",
+    "intro": "Le même événement d'achèvement est présenté par les deux points d'entrée. Le TUI écrit un bloc de résumé au terminal; l'onglet Sauvegardes de Monitor affiche l'exécution dans la liste des archives avec la taille, la durée et les badges d'état.",
+    "scriptsAlt": "ProxMenux Scripts TUI montrant une sauvegarde d'hôte terminée — destination, ID de sauvegarde, chemin instantané, taille des données, durée et état de chiffrement.",
+    "scriptsCaption": "Sauvegarde terminée — ProxMenux Scripts (TUI). Le bloc d'achèvement imprime la destination, l'ID de sauvegarde, le nom d'instantané ou d'archive, la taille des données, la durée et l'état de chiffrement.",
+    "monitorAlt": "Onglet de sauvegarde ProxMenux Monitor montrant une entrée de sauvegarde d'hôte terminée avec taille, durée, badge de méthode et indicateur de chiffrement.",
+    "monitorCaption": "Sauvegarde terminée — onglet Sauvegardes ProxMenux Monitor. La nouvelle sauvegarde apparaît dans la liste des archives avec le badge de la méthode de destination, la taille, la durée et, le cas échéant, l'indicateur de verrouillage de chiffrement."
+  },
+  "whereNext": {
+    "heading": "Où aller ensuite?",
+    "items": [
+      {
+        "label": "Destinations",
+        "href": "/docs/backup-restore/destinations",
+        "tail": "— détails de configuration pour Local, PBS et Borg."
+      },
+      {
+        "label": "Tâches programmées",
+        "href": "/docs/backup-restore/scheduled-jobs",
+        "tail": " — exécuter la même sauvegarde sans intervention selon un calendrier, plutôt que de façon interactive."
+      },
+      {
+        "label": "Restauration",
+        "href": "/docs/backup-restore/restoring",
+        "tail": "— le flux qui consomme ce que cette page produit."
+      }
+    ]
+  }
+}

web/messages/fr/docs/backup-restore/cross-kernel.json

@@ -0,0 +1,170 @@
+{
+  "meta": {
+    "title": "Restauration entre noyaux différents — détection, filtrage et adaptation | ProxMenux",
+    "description": "Comment ProxMenux restaure une sauvegarde d’hôte sur une version principale différente du noyau. Détection du sens de l’écart, filtre des chemins critiques si la cible utilise un noyau plus récent et adaptation en quatre phases pour réappliquer IOMMU, ID VFIO et paramètres de ligne de commande sans recopier tels quels les fichiers liés au noyau.",
+    "ogTitle": "ProxMenux Backup — restauration entre versions du noyau et adaptation",
+    "ogDescription": "Restauration entre versions du noyau tenant compte du sens du changement, avec filtrage sûr et adaptation indépendante du noyau.",
+    "twitterTitle": "Restauration entre noyaux différents | ProxMenux",
+    "twitterDescription": "Comment ProxMenux gère une restauration lorsque le noyau cible diffère de celui de la sauvegarde."
+  },
+  "header": {
+    "title": "Restauration entre versions du noyau",
+    "description": "Comment ProxMenux gère une restauration lorsque l'hôte cible exécute un noyau différent de celui enregistré dans la sauvegarde, surtout lorsque la cible exécute un noyau plus récent. Explique comment la différence est détectée, comment les chemins critiques de démarrage qui pourraient briser la cible sont filtrés, et comment la configuration propre de l'utilisateur est réappliquée sans copier les fichiers liés au noyau mot pour mot.",
+    "section": "Sauvegarde et restauration"
+  },
+  "intro": {
+    "title": "Chaque saut du noyau est géré différemment",
+    "body": "Le noyau d'un hôte Proxmox est identifié par une chaîne de version comme <code>6.17.13-2-pve</code>. Les deux premiers nombres (<strong>6.17</strong> dans cet exemple) définissent la version principale : lorsqu'ils changent, certains fichiers de configuration écrits pour le noyau précédent peuvent ne pas être valides sur le nouveau. Lorsque la restauration détecte que la sauvegarde et la cible ont différentes versions majeures du noyau, les branches de flux basées sur la direction du saut — que la sauvegarde soit plus ancienne ou plus récente que la cible — parce que les deux cas ont des modes de défaillance opposés. Les sauvegardes plus récentes que la cible restaurent proprement comme-est (vérifiées sur plusieurs sauts du noyau). Les sauvegardes plus anciennes que la cible ont besoin d'un filtre pour éviter de casser le démarrage de la cible avec une configuration écrite pour un noyau qui a depuis changé."
+  },
+  "directionCheck": {
+    "heading": "Le contrôle de direction",
+    "intro": "Lors de la vérification de compatibilité, <code>hb_compat_check</code> compare le noyau enregistré dans le manifeste de sauvegarde au noyau courant de la cible (<code>uname -r</code>) et classifie la restauration dans l'un des trois cas, stockés dans la variable interne <code>HB_COMPAT_KERNEL_DIRECTION</code>:",
+    "rows": [
+      {
+        "direction": "same",
+        "condition": "La version principale du noyau correspond entre la sauvegarde et la cible.",
+        "behavior": "Le flux complet de restauration est inchangé. Pas de filtre supplémentaire, pas d'hydratation, pas de notice spéciale dans l'interface utilisateur."
+      },
+      {
+        "direction": "bk_newer",
+        "condition": "Le noyau de la sauvegarde est PLUS RÉCENT que celui de la cible (exemple : sauvegarde sous 7.0, cible sous 6.17).",
+        "behavior": "Le processus complet reste inchangé, comme pour <code>same</code>, sans filtre. Les essais rapportés ont montré la réinstallation des pilotes pour le noyau cible, l’application de la configuration IOMMU et le démarrage des VM avec passthrough GPU."
+      },
+      {
+        "direction": "bk_older",
+        "condition": "Le noyau de la sauvegarde est PLUS ANCIEN que celui de la cible (exemple : sauvegarde sous 6.17, cible sous 7.0).",
+        "behavior": "Le filtre sous-ensemble et l'hydratation en quatre phases ci-dessous sont activés. Le processus de restauration — la cible reproduit la source, mais les fichiers critiques de démarrage ne sont pas copiés mot à mot."
+      }
+    ]
+  },
+  "whyBkNewerIsSafe": {
+    "heading": "Pourquoi une sauvegarde avec un noyau plus récent que la cible restaure inchangé",
+    "body": "Lorsque la restauration s'exécute contre une cible avec un noyau <em>plus ancien</em> que celui enregistré dans la sauvegarde, chaque mécanisme dont dépend la restauration est indépendant de la version du noyau. Les installateurs de pilotes GPU et d'autres installateurs PCI détectent le noyau en cours d'exécution avec <code>uname -r</code> et compilent DKMS contre tout ce que la cible a. Le paquet APT installe tire des binaires construits pour la distribution de la cible. Les jetons IOMMU cmdline comme <code>intel_iommu=on</code> sont stables dans les principales versions du noyau. La sauvegarde porte des chemins écrits sous un noyau plus récent, mais ces chemins (module blacklists, GRUB par défaut, initramfs config) sont toujours valides sur l'ancien — les noyaux ignorent les jetons qu'ils ne reconnaissent pas au lieu d'échouer. Ce cas est équivalent en pratique à une restauration du même noyau, et ProxMenux le traite comme tel."
+  },
+  "safeSubsetFilter": {
+    "heading": "Le filtre de sous-ensemble de sécurité (uniquement lorsque le noyau cible est plus récent)",
+    "intro": "Lorsque le noyau cible est plus récent que celui de la sauvegarde, la vérification de compatibilité ajoute des chemins critiques de démarrage 16 de <code>hb_unsafe_paths_cross_version</code> à <code>RS_SKIP_PATHS</code>. Ces chemins sont exclus de la restauration parce que l'écriture d'une version d'un noyau plus ancien sur une cible en cours d'exécution d'un nouveau a causé des paniques du noyau dans les tests de banc. Les chemins couvrent cinq catégories:",
+    "categoryRows": [
+      {
+        "category": "Chargeur d'amorçage",
+        "paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
+        "reason": "GRUB est lié à l'ordre du noyau précédent, et à l'état proxmox-boot-tool (cmdline, ESP UUIDs, crochets) qui fait référence aux chemins et aux identifiants de l'ancienne installation."
+      },
+      {
+        "category": "Modules de noyau et artefacts de démarrage",
+        "paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
+        "reason": "Autoload listes qui peuvent renvoyer des modules rebaptisés entre les majors du noyau, options de module qui peuvent ne pas s'appliquer, initramfs crochets écrits pour l'ancien noyau."
+      },
+      {
+        "category": "Empilement de stockage et identité du système de fichiers",
+        "paths": "<code>/etc/fstab</code>, <code>/etc/multipath</code>, <code>/etc/iscsi</code>, <code>/etc/udev/rules.d</code>, <code>/etc/zfs</code>",
+        "reason": "UUID qui peuvent ne pas exister sur cette installation, pilotes multipath qui changent entre les noyaux, paramètres iSCSI qui évoluent, règles udev qui peuvent se lier à des sous-systèmes inexistants, état ZFS (<code>zpool.cache</code> + <code>hostid</code>) qui peuvent verrouiller le pool comme étranger."
+      },
+      {
+        "category": "Sources APT",
+        "paths": "<code>/etc/apt</code>",
+        "reason": "Les suites sources APT peuvent déclencher une dégradation des paquets critiques lors de la prochaine mise à jour."
+      },
+      {
+        "category": "systemd",
+        "paths": "<code>/etc/systemd/system</code>, <code>/etc/systemd/journald.conf</code>, <code>/etc/systemd/logind.conf</code>, <code>/etc/systemd/system.conf</code>, <code>/etc/systemd/user.conf</code>",
+        "reason": "Surcharges d’unités et liens .wants liés à une ancienne version majeure de systemd ; clés de configuration pouvant être invalides pour une version plus récente."
+      }
+    ],
+    "outroBody": "Le filtre fonctionne AVANT la boîte de dialogue de confirmation afin que l'utilisateur voit la liste exacte des chemins qui seront ignorés, catégorisé par la raison. La restauration continue — tout le reste (configuration VM/LXC, réseau, /etc/pve, utilisateurs, cron, état ProxMenux, paquets, pilotes, /root) est restauré normalement."
+  },
+  "hydration": {
+    "heading": "Hydratation du noyau-agnostique",
+    "intro": "Le filtre omet les fichiers critiques ; l’adaptation réapplique certains réglages : paramètres IOMMU, ID VFIO, <code>GRUB_TIMEOUT</code> personnalisé et listes de blocage nvidia. Elle s’exécute si le noyau cible est plus récent. La fusion cmdline conserve les clés de la cible et ajoute les modules manquants. Les valeurs GRUB et fichiers autorisés peuvent remplacer un contenu cible différent. Répéter les mêmes entrées est idempotent.",
+    "phaseRows": [
+      {
+        "phase": "1a — Voie GRUB",
+        "detail": "Pour les hôtes GRUB (installations ext4/lvm). <code>_rs_hyd_grub</code> fusionne les paramètres de <code>manifest.kernel_params.cmdline_extra</code> de la sauvegarde dans <code>GRUB_CMDLINE_LINUX_DEFAULT</code> de la cible, en ignorant les clés déjà présentes. Il reprend ensuite les clés autorisées <code>GRUB_*</code> (<code>GRUB_TIMEOUT</code>, <code>GRUB_TIMEOUT_STYLE</code>, <code>GRUB_DEFAULT</code>, <code>GRUB_TERMINAL</code>, <code>GRUB_DISABLE_OS_PROBER</code>, <code>GRUB_SERIAL_COMMAND</code>, <code>GRUB_GFXMODE</code>, <code>GRUB_GFXPAYLOAD_LINUX</code>) depuis <code>/etc/default/grub</code> de la sauvegarde si leurs valeurs diffèrent de la cible."
+      },
+      {
+        "phase": "1b — systemd-boot / ZFS",
+        "detail": "Pour systemd-boot (souvent ZFS à la racine). <code>_rs_hyd_kernel_cmdline</code> fusionne les paramètres utilisateur de <code>cmdline_extra</code> dans <code>/etc/kernel/cmdline</code> de la cible tout en préservant ses paramètres de démarrage <code>root=</code>, <code>boot=</code> et <code>rootflags=</code>."
+      },
+      {
+        "phase": "2 — Fusion /etc/modules",
+        "detail": "<code>_rs_hyd_modules</code> ajoute des modules de <code>manifest.kernel_params.modules_loaded_at_boot</code> qui sont dans la liste blanche (<code>vfio</code>, <code>vfio_pci</code>, <code>vfio_iommu_type1</code>, <code>vfio_virqfd</code>, <code>kvm</code>, <code>kvm_intel</code>, <code>kvm_amd</code>, <code>nvidia</code>, <code>nvidia_drm</code>, <code>nvidia_modeset</code>, <code>nvidia_uvm</code>, <code>i915</code>, <code>xe</code>) ET n'est pas déjà présent dans la cible <code>/etc/modules</code>."
+      },
+      {
+        "phase": "3 — Copie des fichiers figurant sur la liste blanche",
+        "detail": "<code>_rs_hyd_files</code> copie les fichiers rédigés par l’utilisateur depuis les rootfs jusqu'à la cible en direct lorsque le contenu diffère. La liste blanche couvre les fichiers VFIO/nvidia/blacklist sous <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code>, et la règle de liaison ProxMenux VFIO + règles nvidia udev sous <code>/etc/udev/rules.d</code>. Les fichiers appartenant à des Distro (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) sont délibérément exclus — leur contenu évolue entre les versions."
+      },
+      {
+        "phase": "4 — Forcer la régénération après démarrage",
+        "detail": "Les quatre phases écrivent directement à la cible en direct EN DEHORS DE le pipeline normal de restauration. Pour que les paramètres/modules/fichiers fusionnés prennent effet sur le prochain boot, <code>HB_HYDRATION_APPLIED=1</code> se propage via <code>plan.env</code> vers <code>apply_pending_restore.sh</code>, ce qui force <code>NEEDS_INITRAMFS=1</code> et <code>NEEDS_GRUB=1</code> indépendamment de ce qui était dans la liste d'application. Le répartiteur post-démarrage régénère ensuite les initramfs et rafraîchit le chargeur."
+      }
+    ]
+  },
+  "planCommit": {
+    "heading": "Plan vs commit — l'utilisateur voit d'abord un aperçu",
+    "body": "L'hydratation fonctionne en deux modes. Avant la boîte de dialogue de confirmation, ProxMenux exécute <code>_rs_apply_bk_older_hydration</code> en mode <code>plan</code> : il calcule exactement ce qui serait fusionné, peuple <code>RS_HYDRATION_SUMMARY</code> avec un bloc vert listant chaque action, et retourne sans écrire. La boîte de dialogue de confirmation montre que le bloc vert à côté de la liste orange des chemins exclus, de sorte que l'utilisateur voit À L’AVANCE ce qui sera ré-appliqué automatiquement. Après que l'utilisateur ait confirmé, ProxMenux réexécute le même helper en mode <code>commit</code> — mêmes phases, même logique, mais cette fois chaque phase écrit à la cible en direct. L'annulation de la boîte de dialogue de confirmation laisse la cible intacte."
+  },
+  "flowDiagram": {
+    "heading": "Le flux lorsque le noyau cible est plus récent que celui de la sauvegarde",
+    "intro": "Les étapes ajoutées lorsque le noyau cible est plus récent s'assoient à l'intérieur du flux normal de restauration. Tout le reste — application chaude, préparation en attente, installation de paquets, répartiteur post-démarrage — fonctionne identiquement à une restauration du même noyau.",
+    "diagram": "  ┌────────────────────────────────────────────────────────────┐\n  │ hb_compat_check                                             │\n  │   HB_COMPAT_KERNEL_DIRECTION = bk_older                     │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ Add 16 boot-critical paths to RS_SKIP_PATHS                 │\n  │   /etc/default/grub, /etc/kernel, /etc/modules-load.d, ...  │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ _rs_apply_bk_older_hydration \"plan\"                         │\n  │   Compute what would be merged                              │\n  │   Populate RS_HYDRATION_SUMMARY (green block)               │\n  │   No writes                                                 │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ Confirmation dialog                                         │\n  │   Amber: paths skipped by safe-subset filter                │\n  │   Green: tokens/files reapplied by hydration                │\n  │   User accepts or cancels                                   │\n  └───────────────────────────┬────────────────────────────────┘\n                              │ (accepted)\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ _rs_apply_bk_older_hydration \"commit\"                       │\n  │   Phase 1a/1b: merge cmdline tokens + GRUB keys             │\n  │   Phase 2: append modules to /etc/modules                   │\n  │   Phase 3: copy whitelisted vfio/nvidia files               │\n  │   Set HB_HYDRATION_APPLIED=1                                │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ Rest of the restore runs normally                           │\n  │   _rs_apply hot (skips RS_SKIP_PATHS)                       │\n  │   _rs_prepare_pending_restore (writes plan.env with         │\n  │     HB_HYDRATION_APPLIED=1)                                 │\n  │   packages.manual.list install                              │\n  │   Reboot                                                    │\n  │   apply_pending_restore.sh (forces NEEDS_INITRAMFS=1,       │\n  │     NEEDS_GRUB=1 because of the hydration flag)             │\n  │   apply_cluster_postboot.sh                                 │\n  │     update-initramfs -u -k all                              │\n  │     update-grub / proxmox-boot-tool refresh                 │\n  │     component --auto-reinstall                              │\n  └────────────────────────────────────────────────────────────┘"
+  },
+  "concreteExamples": {
+    "heading": "Exemples concrets",
+    "intro": "Le passe d'hydratation n'est pas abstrait — il produit des résultats observables et corrects pour des scénarios communs. Deux exemples que l'hydratation gère automatiquement :",
+    "rows": [
+      {
+        "scenario": "Passage de GPU (VFIO)",
+        "detail": "La source avait le <code>intel_iommu=on iommu=pt</code> dans la ligne cmd, le <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> dans le <code>/etc/modules</code>, un <code>/etc/modprobe.d/vfio.conf</code> avec le <code>options vfio-pci ids=10de:2216</code> et un <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. L'hydratation fusionne les jetons cmdline dans le GRUB de la cible ou le noyau cmdline, ajoute les modules vfio au <code>/etc/modules</code>, et copie les deux fichiers modprobe rédigés par l’utilisateur. Sur le prochain démarrage, IOMMU est actif, les modules VFIO chargent, le GPU est lié à vfio-pci et le VM est livré avec le travail de passage."
+      },
+      {
+        "scenario": "Par défaut du GRUB personnalisé",
+        "detail": "Source : <code>GRUB_TIMEOUT=1</code> et <code>GRUB_DISABLE_OS_PROBER=true</code>. L'hydratation lit les deux clés de la sauvegarde <code>/etc/default/grub</code>, voit qu'elles diffèrent des valeurs par défaut de la nouvelle installation, et réécrit ces deux lignes dans le fichier de la cible (en laissant tout le reste, y compris <code>GRUB_DISTRIBUTOR</code>, intact)."
+      }
+    ]
+  },
+  "callout": {
+    "warningTitle": "Ce que l'hydratation ne réapplique pas lorsque le noyau cible est plus récent",
+    "warningBody": "L'hydratation ne réapplique que la configuration ProxMenux sait être sûre dans toutes les versions du noyau : jetons IOMMU, ID VFIO, clés GRUB sur liste blanche et modules d'une liste fixe (<code>vfio*</code>, <code>nvidia*</code>, <code>i915</code>, <code>xe</code>, <code>kvm*</code>). Tout ce qui se trouve à l'extérieur de cet ensemble — les crochets initramfs personnalisés sous <code>/etc/initramfs-tools/hooks/</code>, les fichiers non inscrits sur la liste blanche sous <code>/etc/modprobe.d/</code>, les surcharges d’unités systemd rédigées par l’utilisateur — reste exclu. La raison en est concrète : ces fichiers peuvent appeler des interfaces internes au noyau (API modulaires, mise en page <code>/sys</code>, crochets <code>udev</code>) qui changent entre les versions principales, et les appliquer mot à mot sur le nouveau noyau peut empêcher la cible de démarrer. Lorsque la reproduction exacte de la chaîne de démarrage est requise, la restauration doit être exécutée sur un hôte avec la même version principale du noyau que la sauvegarde."
+  },
+  "codeReference": {
+    "heading": "Où vivent les mécanismes",
+    "intro": "Pour les développeurs qui cherchent à tracer ou à étendre le comportement du cross-kernel:",
+    "rows": [
+      {
+        "component": "Détection de la direction",
+        "location": "<code>hb_compat_check</code> dans <code>lib_host_backup_common.sh</code>. Définit <code>HB_COMPAT_KERNEL_DIRECTION</code>."
+      },
+      {
+        "component": "Liste des chemins de sous-ensembles sécurisés",
+        "location": "<code>hb_unsafe_paths_cross_version</code> dans <code>lib_host_backup_common.sh</code>. Émet <code>path\\treason</code> lignes utilisées à la fois par le filtre CLI et le point de terminaison Web <code>/api/host-backups/restore/prepare</code>."
+      },
+      {
+        "component": "Phases d'hydratation",
+        "location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> dans <code>backup_host.sh</code>. Ordonné par <code>_rs_apply_bk_older_hydration</code>."
+      },
+      {
+        "component": "Régénération forcée après démarrage",
+        "location": "<code>apply_pending_restore.sh</code> lit <code>HB_HYDRATION_APPLIED</code> de <code>plan.env</code> et force <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>."
+      },
+      {
+        "component": "Aperçu du Web",
+        "location": "<code>/api/host-backups/restore/prepare</code> dans <code>flask_server.py</code>. Charge la bibliothèque d'aide, exécute <code>_rs_apply_bk_older_hydration</code> en mode plan, renvoie les actions au mode Web."
+      }
+    ]
+  },
+  "whereNext": {
+    "heading": "Où aller ensuite?",
+    "items": [
+      {
+        "label": "Restauration",
+        "href": "/docs/backup-restore/restoring",
+        "tail": " — le processus complet de restauration qui intègre les mécanismes de cette page."
+      },
+      {
+        "label": "Comment ça marche",
+        "href": "/docs/backup-restore/how-it-works",
+        "tail": " — le manifeste et les collecteurs qui produisent le bloc <code>kernel_params</code> lu par l’adaptation."
+      }
+    ]
+  }
+}

web/messages/fr/docs/backup-restore/destinations/borg.json

@@ -0,0 +1,234 @@
+{
+  "meta": {
+    "title": "Destination Borg — types de dépôts, authentification SSH, chiffrement | ProxMenux",
+    "description": "La destination Borg enregistre les sauvegardes d’hôte ProxMenux dans un dépôt local, sur un disque externe monté ou sur un serveur distant via SSH. Cette page décrit la recherche de l’exécutable borg, les quatre options initiales de clé SSH, le chiffrement repokey, la configuration des destinations enregistrées et la rétention par tâche planifiée.",
+    "ogTitle": "Sauvegarde ProxMenux — Destination borg",
+    "ogDescription": "Comment ProxMenux enregistre les sauvegardes d’hôte dans des dépôts Borg avec authentification SSH et chiffrement repokey.",
+    "twitterTitle": "Destination de sauvegarde Borg: ProxMenux",
+    "twitterDescription": "Dépôts Borg locaux, USB et SSH pour les sauvegardes hôtes."
+  },
+  "header": {
+    "title": "Borg",
+    "description": "La destination Borg écrit des sauvegardes d'hôte dans un dépôt Borg. Trois types de dépôt sont pris en charge : chemin du système de fichiers local, disque externe monté ou serveur distant via SSH. Déduplication au niveau du chunk dans toutes les archives du dépôt et cryptage facultatif des repokey.",
+    "section": "Sauvegarde et restauration"
+  },
+  "aboutBorg": {
+    "heading": "Ce que Borg est",
+    "body": "Borg, aussi appelé BorgBackup, est un outil de sauvegarde libre avec déduplication, maintenu par la communauté Borg Backup. Il stocke chaque archive sous forme de blocs de longueur variable dans un dépôt. Les blocs sont partagés entre archives : sauvegarder à nouveau des données inchangées ne consomme presque aucun espace supplémentaire. Borg est indépendant de Proxmox et sert dans de nombreux environnements. ProxMenux l’utilise comme l’une des trois destinations de sauvegarde d’hôte ; les mécanismes décrits ici (types de dépôts, borg-serve via SSH, chiffrement repokey, prune) sont ceux de Borg."
+  },
+  "intro": {
+    "title": "Déduplication par blocs avec dépôts locaux ou accessibles via SSH",
+    "body": "Un dépôt Borg stocke des blocs partagés entre toutes ses archives. Sauvegarder à nouveau un fichier inchangé ne transfère ni ne stocke de nouvelles données. ProxMenux utilise <code>borg create</code> pour sauvegarder et <code>borg extract</code> pour restaurer. Le dépôt peut se trouver sur le même système de fichiers que la source, sur un disque externe monté ou sur un hôte distant accessible via SSH."
+  },
+  "binarySourcing": {
+    "heading": "Le binaire borg",
+    "intro": "Borg n'est pas une dépendance de base de l'installateur ProxMenux. Lorsqu'une sauvegarde s'exécute, <code>hb_ensure_borg</code> résout le binaire à partir de quatre sources dans l'ordre et retourne le premier qui fonctionne :",
+    "rows": [
+      {
+        "priority": "1",
+        "source": "Système <code>borg</code>",
+        "detail": "Si l'hôte a déjà <code>borg</code> installé via APT (<code>which borg</code> résout), ce binaire est utilisé."
+      },
+      {
+        "priority": "2",
+        "source": "Cache du répertoire d’état",
+        "detail": "<code>/usr/local/share/proxmenux/borg</code> — conservé d'un téléchargement préalable de GitHub sur cet hôte."
+      },
+      {
+        "priority": "3",
+        "source": "Paquet AppImage du moniteur",
+        "detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> — le AppImage regroupe un borg-linux64 signé. C'est le chemin hors ligne sécurisé : un hôte sans internet a toujours un <code>borg</code> fonctionnant."
+      },
+      {
+        "priority": "4",
+        "source": "Téléchargement GitHub",
+        "detail": "<code>wget</code> contre l'URL <code>borg-linux64</code> épinglée sous <code>github.com/borgbackup/borg/releases/</code>, vérifiée contre une constante SHA-256 dans <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). En cas de somme de contrôle incorrecte, le binaire est rejeté et la sauvegarde avorte. Le fichier téléchargé est mis en cache dans l'état dir afin que les sauvegardes suivantes utilisent le chemin 2."
+      }
+    ]
+  },
+  "repoTypes": {
+    "heading": "Types de dépôts",
+    "intro": "Le type de dépôt est choisi lorsqu'une cible est ajoutée. Chaque type résout une URL de dépôt différente que Borg comprend.",
+    "rows": [
+      {
+        "type": "remote",
+        "url": "ssh://USER@HOST/RPATH",
+        "detail": "Le dépôt vit sur un serveur distant qui exécute <code>borg serve</code>. Nécessite une connexion SSH à ce serveur."
+      },
+      {
+        "type": "usb",
+        "url": "/mnt/MOUNTPOINT/borgbackup",
+        "detail": "Le dépôt vit sur un disque externe monté (habituellement USB). Le montage est résolu via <code>hb_prompt_mounted_path</code>, qui détecte, monte ou formate les partitions USB au besoin."
+      },
+      {
+        "type": "local",
+        "url": "/backup/borgbackup (any absolute path)",
+        "detail": "Le dépôt vit dans un répertoire local. Signifiant seulement lorsque le répertoire cible est sur un disque physique séparé — un dépôt sur le même disque que la source protège contre l'erreur de l'opérateur mais pas contre la défaillance du disque."
+      }
+    ]
+  },
+  "serverSetup": {
+    "heading": "Préparation du serveur Borg (côté serveur)",
+    "intro": "Le type de dépôt <code>remote</code> nécessite un serveur Borg fonctionnel accessible via SSH. ProxMenux ne configure pas le serveur lui-même : il autorise seulement une clé sur un compte existant. Cette section décrit les prérequis du serveur.",
+    "hostChoicesTitle": "Où le serveur peut vivre",
+    "hostChoicesBody": "Tout hôte Linux avec accès SSH se qualifie. Configurations communes :",
+    "hostChoicesItems": [
+      "Un NAS dédié ou une boîte de sauvegarde (Debian, Ubuntu, TrueNAS SCALE avec un shell).",
+      "Un conteneur LXC à l'intérieur d'un nœud Proxmox. Petite empreinte, isolée de l'hôte exécutant les sauvegardes.",
+      "Un autre hôte Proxmox sur le même LAN, ou un VM n'importe où accessible sur SSH."
+    ],
+    "lxcWarningTitle": "LXC comme serveur Borg",
+    "lxcWarningBody": "Si le serveur Borg est dans un LXC, generate-auto nécessite un compte acceptant l’authentification SSH par mot de passe pour installer la clé. Sinon, utilisez l’installation manuelle ou l’alternative generate-pct via l’hôte PVE.",
+    "requirementsTitle": "Exigences sur le serveur",
+    "requirementsRows": [
+      {
+        "requirement": "Exécutable borg dans <code>/usr/bin/borg</code>",
+        "detail": "La ligne <code>command=\"/usr/bin/borg serve ...\"</code> écrite par ProxMenux dans <code>authorized_keys</code> utilise ce chemin fixe. L’installation APT (<code>apt install borgbackup</code>) y place l’exécutable. Pour un binaire autonome, créez un lien symbolique à <code>/usr/bin/borg</code>."
+      },
+      {
+        "requirement": "Un compte utilisateur dédié (généralement <code>borg</code>)",
+        "detail": "Possède le répertoire du dépôt et reçoit les connexions SSH entrantes. N'a pas besoin d'accès sudo ou shell — la ligne authorized_keys désactive de toute façon les shells interactifs."
+      },
+      {
+        "requirement": "Un répertoire de dépôt en écriture",
+        "detail": "Le chemin que l'opérateur donne à ProxMenux (par exemple <code>/backup/borgbackup</code>) doit exister sur le serveur et être la propriété de l'utilisateur borg."
+      },
+      {
+        "requirement": "SSH démon acceptant l'utilisateur borg",
+        "detail": "<code>PubkeyAuthentication yes</code> (par défaut). L'authentification par mot de passe n'est nécessaire que pour le flux <em>generate-auto</em>, une fois la clé installée, le serveur peut désactiver complètement le mot de passe auth."
+      }
+    ],
+    "minimalSetupTitle": "Configuration minimale du serveur",
+    "minimalSetupBody": "Sur un serveur Debian ou Ubuntu Borg, une référence de travail est quatre commandes comme root:",
+    "minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
+    "minimalSetupNote": "Une fois le serveur préparé et l’authentification SSH par mot de passe disponible, <code>generate-auto</code> installe la clé via un compte pouvant écrire dans authorized_keys de l’utilisateur borg. Les sauvegardes suivantes utilisent cette clé, limitée à <code>borg serve</code> au chemin configuré. Sans connexion par mot de passe, installez-la manuellement ou via l’hôte PVE."
+  },
+  "sshAuth": {
+    "heading": "authentification SSH (côté client)",
+    "intro": "Les dépôts distants Borg sont accessibles sur SSH. La connexion passe de l'hôte ProxMenux à un compte utilisateur sur le serveur Borg qui exécute <code>borg serve</code>. Cet utilisateur s'appelle généralement <code>borg</code>, PAS l'utilisateur admin/root du serveur — la ligne de commande borg-serve verrouille la connexion à ce chemin de dépôt spécifique (voir les stratégies clés ci-dessous).",
+    "strategiesTitle": "Stratégies de clé SSH",
+    "strategiesIntro": "Lors de l’ajout d’une destination distante, ProxMenux demande l’utilisateur SSH, l’hôte, le port et le chemin distant, puis propose quatre choix d’authentification. L’alternative generate-pct est proposée si l’authentification par mot de passe est refusée. Voici les modes :",
+    "strategyRows": [
+      {
+        "mode": "generate-auto",
+        "label": "Recommandé",
+        "detail": "ProxMenux crée ou réutilise une paire de clés ed25519 dans <code>~/.ssh/borg_proxmenux_HOST_ed25519</code>, puis utilise <code>sshpass</code> pour tester la connexion et installer la clé publique dans <code>~borg/.ssh/authorized_keys</code>. Le mot de passe est celui d’un compte autorisé à écrire ce fichier, généralement root ou borg. Il sert pendant la configuration et n’est pas enregistré."
+      },
+      {
+        "mode": "generate-manual",
+        "label": "Pas de mot de passe admin sur cet hôte",
+        "detail": "ProxMenux génère la paire de clés comme ci-dessus, mais affiche la ligne complète <code>authorized_keys</code> pour que l'opérateur colle manuellement dans le serveur. Le mot de passe administrateur ne quitte jamais l'hôte ProxMenux car il n'est jamais demandé."
+      },
+      {
+        "mode": "generate-pct",
+        "label": "Le serveur Borg est un PVE LXC",
+        "detail": "Le serveur Borg fonctionne à l'intérieur d'un LXC sur un nœud PVE. ProxMenux autorise la clé via <code>pct exec</code> de l'hôte PVE — root sur l'hôte PVE écrit dans le LXC de <code>~borg/.ssh/authorized_keys</code> sans avoir besoin de SSH dans le LXC lui-même."
+      },
+      {
+        "mode": "existing",
+        "label": "Utiliser une clé existante",
+        "detail": "ProxMenux recherche dans <code>/root/.ssh/</code> et <code>$HOME/.ssh/</code> les clés privées ed25519/RSA qu’il peut lire, puis les liste. L’opérateur en choisit une ou indique manuellement un chemin non standard."
+      },
+      {
+        "mode": "none",
+        "label": "Config par défaut SSH",
+        "detail": "Aucune clé personnalisée — Borg s'appuie sur la configuration par défaut de l'hôte SSH (généralement <code>~/.ssh/id_rsa</code> ou un agent SSH)."
+      }
+    ],
+    "restrictTitle": "La ligne authorized_keys",
+    "restrictBody": "Pour chaque clé générée, la ligne <code>authorized_keys</code> écrite par ProxMenux sur le serveur limite la clé à cet appel borg-serve sur le chemin configuré du dépôt :",
+    "restrictLine": "command=\"/usr/bin/borg serve --restrict-to-path RPATH\",restrict PUBKEY",
+    "restrictNote": "Le <code>command=</code> force chaque session SSH en utilisant cette clé pour exécuter seulement la commande borg-serve; <code>restrict</code> désactive le renvoi de port, le renvoi d'agent, le renvoi de X11 et l'allocation de PTY. La clé ne peut pas être utilisée pour ouvrir un shell interactif sur le serveur ou pour accéder à tout autre chemin de dépôt, même si le compte a des privilèges plus larges."
+  },
+  "savedTargets": {
+    "heading": "Objectifs enregistrés",
+    "intro": "Une destination enregistrée conserve la configuration du dépôt sous un nom lisible pour éviter de ressaisir les détails. Fichiers dans le répertoire d’état ProxMenux :",
+    "rows": [
+      {
+        "file": "borg-targets.txt",
+        "content": "Une ligne par destination : <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. <code>hb_collect_borg_configs</code> la lit pour remplir le menu de sélection des destinations."
+      },
+      {
+        "file": "borg-pass-NAME.txt",
+        "content": "Phrase secrète de la destination nommée NAME ci-dessus (<code>chmod 600</code>). Présente uniquement si le chiffrement repokey a été choisi."
+      }
+    ],
+    "outro": "Enregistrer la destination est facultatif. Refuser omet la configuration nommée, mais ne supprime pas une clé SSH générée. Si le chiffrement repokey est activé sans destination enregistrée, ProxMenux conserve tout de même la phrase secrète dans l’ancien fichier borg-pass.txt."
+  },
+  "encryption": {
+    "heading": "Cryptage",
+    "body": "Les dépôts sont initialisés avec un mode de chiffrement via <code>hb_borg_init_if_needed</code>: le <code>borg repo-create -e MODE</code> moderne quand disponible, ou le <code>borg init --encryption=MODE</code> hérité. ProxMenux expose deux modes : <code>repokey</code> (par défaut) et <code>none</code>. En mode <code>repokey</code> Borg stocke la clé de cryptage à l'intérieur du dépôt lui-même ; l'accès nécessite une phrase de passe, que ProxMenux invite pour deux fois avec vérification de concordance et enregistre dans <code>borg-pass-NAME.txt</code> pour une destination enregistrée, sinon dans l’ancien fichier décrit plus haut. Une boîte de dialogue de reconnaissance obligatoire s'affiche après l'enregistrement de la phrase de passe : la phrase de passe est la seule façon d'accéder aux archives chiffrées, et la perdre rend chaque archive du dépôt inrécupérable."
+  },
+  "runtimeEnv": {
+    "heading": "Environnement d'exécution",
+    "intro": "ProxMenux exporte les variables d'environnement suivantes avant d'invoquer <code>borg</code>. Ils configurent la connexion et déverrouillent le dépôt sans intégrer de secrets dans la ligne de commande.",
+    "rows": [
+      {
+        "var": "BORG_RSH",
+        "value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
+        "purpose": "Commande distante utilisée par Borg pour les dépôts SSH. Une clé sélectionnée ajoute les options d’identité. Quand une destination est ajoutée avec un port non standard, ProxMenux ajoute aussi -p PORT ; les destinations enregistrées, les tâches planifiées et le Monitor utilisent plutôt le port de l’URL ssh://. Sans clé personnalisée, et pour une nouvelle destination avec le port par défaut, la variable reste non définie et Borg utilise la configuration SSH de l’hôte."
+      },
+      {
+        "var": "BORG_PASSPHRASE",
+        "value": "(Passphrase de borg-pass-NAME.txt)",
+        "purpose": "Débloque le repokey. Définir uniquement lorsque la cible utilise le chiffrement <code>repokey</code>. N'apparaît jamais dans la liste des arguments du processus."
+      },
+      {
+        "var": "BORG_ENCRYPT_MODE",
+        "value": "repokey | none",
+        "purpose": "Utilisé par <code>hb_borg_init_if_needed</code> lors de l'initialisation d'un dépôt qui n'existe pas encore. Ignoré par <code>borg create</code> sur les dépôts existants."
+      },
+      {
+        "var": "BORG_RELOCATED_REPO_ACCESS_IS_OK",
+        "value": "yes",
+        "purpose": "Supprime la confirmation interactive demandée par Borg lorsque l’URL du dépôt diffère de celle utilisée initialement, par exemple après avoir renommé un point de montage ou changé l’adresse du serveur SSH."
+      },
+      {
+        "var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK",
+        "value": "yes",
+        "purpose": "Supprime l'invite interactive Borg soulève la première fois qu'un dépôt non chiffré est accessible depuis un nouveau client."
+      }
+    ]
+  },
+  "archiveFormat": {
+    "heading": "Nom et conservation des archives",
+    "intro": "Chaque sauvegarde crée une nouvelle archive dans le dépôt.",
+    "namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS",
+    "retentionBody": "Pour les tâches programmées, <code>run_scheduled_backup.sh</code> exécute <code>borg prune</code> contre le dépôt après chaque sauvegarde réussie avec les valeurs de conservation configurées sur le travail (<code>--keep-last</code>, <code>--keep-daily</code>, <code>--keep-weekly</code>). Les sauvegardes interactives ne se prunent pas."
+  },
+  "restoreAccess": {
+    "heading": "Récupération du côté restauration",
+    "body": "Le flux de restauration liste les archives avec <code>borg list REPO</code> et extrait celui sélectionné avec <code>borg extract REPO::ARCHIVE-NAME</code> dans un répertoire de mise en scène que <code>_rs_check_layout</code> alimente dans le pipeline de restauration standard. Pour la récupération manuelle à l'extérieur de ProxMenux les mêmes commandes fonctionnent; l'arborescence extraite est la mise en page standard à trois payload décrite dans <em>Comment ça marche</em>."
+  },
+  "references": {
+    "heading": "Références",
+    "intro": "Documentation officielle de Borg pour les composants utilisés par ProxMenux.",
+    "items": [
+      {
+        "label": "Documentation borg",
+        "href": "https://borgbackup.readthedocs.io/",
+        "tail": "— point d'entrée principal couvrant les concepts, le déploiement, le démarrage rapide et chaque commande."
+      },
+      {
+        "label": "borg create",
+        "href": "https://borgbackup.readthedocs.io/en/stable/usage/create.html",
+        "tail": " — la commande utilisée par ProxMenux pour chaque sauvegarde, avec toutes les options prises en charge."
+      },
+      {
+        "label": "Chiffrement des dépôts",
+        "href": "https://borgbackup.readthedocs.io/en/stable/usage/init.html#encryption-mode",
+        "tail": "— les modes de cryptage pris en charge par Borg, y compris la repokey que ProxMenux utilise par défaut."
+      },
+      {
+        "label": "borg serve et déploiement via SSH",
+        "href": "https://borgbackup.readthedocs.io/en/stable/deployment/central-backup-server.html",
+        "tail": " — configuration d’un serveur Borg central accessible via SSH, avec la commande borg-serve et l’option restrict-to-path inscrites par ProxMenux dans authorized_keys."
+      },
+      {
+        "label": "borg prune",
+        "href": "https://borgbackup.readthedocs.io/en/stable/usage/prune.html",
+        "tail": " — le modèle de rétention de --keep-last / --keep-daily / --keep-weekly appliqué par ProxMenux à chaque tâche planifiée."
+      }
+    ]
+  }
+}

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

@@ -0,0 +1,110 @@
+{
+  "meta": {
+    "title": "Destinations des sauvegardes — archive locale, Proxmox Backup Server et Borg | ProxMenux",
+    "description": "Trois moteurs de stockage reçoivent la même charge utile de sauvegarde ProxMenux : une archive locale .tar.zst sur tout système de fichiers accessible en écriture, une sauvegarde PBS dans un datastore Proxmox Backup Server ou une archive Borg dans un dépôt Borg local ou distant. Chaque moteur a ses propres caractéristiques de compression, de déduplication, de chiffrement et de réseau.",
+    "ogTitle": "Destinations de sauvegarde ProxMenux",
+    "ogDescription": "Local, Proxmox Backup Server et Borg — trois moteurs de stockage pour la même charge utile de sauvegarde d'hôte.",
+    "twitterTitle": "Destinations de sauvegarde ProxMenux | ProxMenux",
+    "twitterDescription": "Archives locales, moteurs Proxmox Backup Server et Borg pour les sauvegardes d'hôte."
+  },
+  "header": {
+    "title": "Destinations",
+    "description": "Trois backends de stockage pris en charge par ProxMenux Backup: archive locale, Proxmox Backup Server (recommandé) et Borg. Chacun reçoit la même archive à trois charges; ils diffèrent en format de stockage, déduplication, modèle de chiffrement et exigences du réseau.",
+    "section": "Sauvegarde et restauration"
+  },
+  "intro": {
+    "title": "Même charge utile, trois moteurs",
+    "body": "Chaque sauvegarde produit les mêmes trois charges utiles (rootfs, manifeste, applications). Ce qui change entre les destinations, c'est comment ces charges sont stockées et comment l'opérateur les récupère pour une restauration. Chaque moteur est implémenté comme une fonction séparée dans <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — mais les trois partagent la même étape de préparation temporaire (<code>hb_prepare_staging</code>) et le même chemin de code de restauration. Le choix de la destination n'affecte que l'écriture et la récupération ; il ne change pas ce qu'une restauration fait ou comment elle consomme l'archive."
+  },
+  "comparison": {
+    "heading": "Comparaison des caractéristiques",
+    "intro": "Le tableau suivant répertorie les différences concrètes entre les trois backends tels qu'ils se comportent dans ProxMenux aujourd'hui. Toutes les valeurs décrivent le comportement observé du backend lui-même, et non des recommandations éditoriales.",
+    "rows": [
+      {
+        "feature": "Format de stockage",
+        "local": "Un seul fichier <code>.tar.zst</code> (ou <code>.tar.gz</code> si <code>zstd</code> est absent).",
+        "pbs": "Sauvegarde PBS (blocs <code>.pxar</code> dans le datastore).",
+        "borg": "Archive Borg à l'intérieur d'un dépôt Borg (fichiers de segments)."
+      },
+      {
+        "feature": "Compression",
+        "local": "zstd (niveau par défaut) via <code>tar --zstd</code>. Repli sur gzip.",
+        "pbs": "Gérée par proxmox-backup-client. ProxMenux ne modifie pas les paramètres de compression.",
+        "borg": "Compression intégrée à Borg. ProxMenux appelle borg create sans modifier les paramètres de compression."
+      },
+      {
+        "feature": "Déduplication",
+        "local": "Aucune. Chaque sauvegarde est une archive indépendante complète.",
+        "pbs": "Déduplication complète de niveau chunk sur toutes les sauvegardes dans le datastore.",
+        "borg": "Déduplication complète au niveau des blocs entre toutes les archives du dépôt."
+      },
+      {
+        "feature": "Chiffrement au repos",
+        "local": "Aucun (dépend de la protection au niveau du système de fichiers).",
+        "pbs": "Chiffrement facultatif côté client avec un fichier de clé. Si activé, le blob de récupération est envoyé dans un groupe de sauvegarde distinct.",
+        "borg": "Chiffrement facultatif des repokey (clé stockée dans la repo, déverrouillée par une phrase de passe)."
+      },
+      {
+        "feature": "Rétention / purge",
+        "local": "Appliquée par tâche programmée via <code>KEEP_LAST</code>. Les anciennes archives sont supprimées avec leurs fichiers annexes et journaux d’exécution. Les sauvegardes interactives ne font pas de purge.",
+        "pbs": "Appliquée par tâche programmée via <code>proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly</code>. Les sauvegardes interactives ne font pas de purge.",
+        "borg": "Appliquée par tâche programmée via <code>borg prune --keep-last / --keep-daily / --keep-weekly</code>. Les sauvegardes interactives ne font pas de purge."
+      },
+      {
+        "feature": "Réseau",
+        "local": "Aucune. Écrit à un point de montage local (généralement un disque interne ou un lecteur USB).",
+        "pbs": "TCP vers le serveur PBS (port par défaut 8007). Nécessite des identifiants PBS + empreinte du certificat.",
+        "borg": "Chemin du système de fichiers local ou tunnel SSH vers un hôte Borg distant."
+      },
+      {
+        "feature": "Dépendances",
+        "local": "<code>tar</code>, <code>zstd</code> (présent sur Proxmox par défaut).",
+        "pbs": "Paquet <code>proxmox-backup-client</code> (fourni avec Proxmox VE 8+).",
+        "borg": "<code>borg</code> binaire. Auto-provisionné par ProxMenux à partir du paquet Moniteur AppImage quand il manque."
+      },
+      {
+        "feature": "Accès pour restaurer",
+        "local": "Tout hôte avec tar+zstd peut extraire l'archive. Pas de PBS/Borg nécessaire.",
+        "pbs": "Nécessite <code>proxmox-backup-client</code>, les identifiants PBS et le fichier de clé (si la sauvegarde est chiffrée).",
+        "borg": "Nécessite <code>borg</code> + le chemin du dépôt + la phrase de passe (si chiffrée)."
+      }
+    ],
+    "captionCode": "feature",
+    "captionLocal": "Locale",
+    "captionPbs": "Proxmox Backup Server (recommandé)",
+    "captionBorg": "Borg"
+  },
+  "sameArchive": {
+    "heading": "La disposition des archives ne change pas avec la destination",
+    "body": "A l'intérieur de l'une des trois destinations, la même disposition <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> décrite dans <em>Comment ça marche</em> est présente. Un <code>.tar.zst</code> extrait d'une archive locale, un <code>.pxar</code> restauré de PBS et une archive Borg extraite de <code>borg extract</code> donnent tous un arbre de répertoire identique. Le chemin du code de restauration (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) lit les mêmes trois charges utiles sans savoir de quelle destination elles proviennent."
+  },
+  "extractStandalone": {
+    "heading": "Extraire une sauvegarde à l'extérieur de ProxMenux",
+    "intro": "N'importe lequel des trois formats d'archive peut être lu avec des outils standard sans ProxMenux installé sur l'hôte de lecture. Les commandes ci-dessous produisent le même arbre de répertoire qu'une restauration consomme en interne.",
+    "localCmd": "# From a local .tar.zst archive:\ntar --zstd -xf hostcfg-HOST-TIMESTAMP.tar.zst\n\n# From a .tar.gz fallback:\ntar -xzf hostcfg-HOST-TIMESTAMP.tar.gz",
+    "pbsCmd": "# From a PBS backup (requires proxmox-backup-client):\nproxmox-backup-client restore \\\n    --repository USER@REALM@HOST:DATASTORE \\\n    host/hostcfg-HOST/BACKUP-TIME \\\n    hostcfg.pxar /tmp/hostcfg\n\n# Add --keyfile KEY-PATH when the backup is encrypted.",
+    "borgCmd": "# Depuis une archive Borg (nécessite borg et la phrase de passe des dépôts chiffrés) :\nborg extract REPO-PATH::ARCHIVE-NAME\n\n# Sur un dépôt distant accessible par SSH :\nborg extract ssh://USER@HOST:PORT/REPO-PATH::ARCHIVE-NAME",
+    "note": "L'arbre extrait peut ensuite être inspecté manuellement ou alimenté à une restauration manuelle. Consultez les pages de destination individuelles pour connaître le processus de récupération exact que ProxMenux utilise sous le capot."
+  },
+  "whereNext": {
+    "heading": "Détails par destination",
+    "intro": "Chaque destination a sa propre page couvrant le flux de configuration, le format sur disque et la commande de récupération utilisée par la restauration.",
+    "items": [
+      {
+        "label": "Archives locales",
+        "href": "/docs/backup-restore/destinations/local",
+        "tail": "— pré-configuration d'une cible locale, montage d'un lecteur USB, vérification de sécurité contre l'écriture de l'archive en soi, le sidecar JSON qui permet au moniteur d'identifier le fichier."
+      },
+      {
+        "label": "Proxmox Backup Server (recommandé)",
+        "href": "/docs/backup-restore/destinations/pbs",
+        "tail": " — choix du datastore, identifiants et empreinte du certificat, cycle de vie du fichier de clé, phrase de passe de récupération et envoi du blob de récupération à PBS pour restaurer après une nouvelle installation."
+      },
+      {
+        "label": "Borg",
+        "href": "/docs/backup-restore/destinations/borg",
+        "tail": " — dépôts locaux ou accessibles par SSH, provenance du binaire Borg (système / cache / paquet AppImage de Monitor / téléchargement GitHub), initialisation du dépôt, gestion des phrases de passe et configuration des clés SSH pour les dépôts distants."
+      }
+    ]
+  }
+}

web/messages/fr/docs/backup-restore/destinations/local.json

@@ -0,0 +1,75 @@
+{
+  "meta": {
+    "title": "Destination d'archive locale — tar.zst sur un système de fichiers ou un lecteur USB ProxMenux",
+    "description": "La destination de sauvegarde locale écrit une seule archive .tar.zst dans n'importe quel répertoire accessible en écriture : un disque interne, un point de montage Proxmox, un partage NFS ou un lecteur USB. Cette page décrit le processus de configuration, la détection USB et la logique de montage, le contrôle de sécurité contre l'écriture de l'archive dans un chemin en cours de sauvegarde, et le sidecar JSON qui identifie le fichier.",
+    "ogTitle": "Sauvegarde ProxMenux — Destination des archives locales",
+    "ogDescription": "Comment ProxMenux écrit des sauvegardes locales comme archives .tar.zst et comment configurer le répertoire de destination ou le lecteur USB.",
+    "twitterTitle": "Destination de sauvegarde locale ProxMenux",
+    "twitterDescription": "Comment ProxMenux écrit des sauvegardes locales comme des archives .tar.zst sur un système de fichiers ou un lecteur USB."
+  },
+  "header": {
+    "title": "Archives locales",
+    "description": "La destination locale écrit une seule archive tar compressée dans n'importe quel répertoire accessible en écriture sur l'hôte : un disque interne, un montage NFS ou SMB ou un lecteur USB.",
+    "section": "Sauvegarde et restauration"
+  },
+  "intro": {
+    "title": "Un fichier autonome",
+    "body": "Une sauvegarde locale produit un seul fichier <code>hostcfg-HOST-TIMESTAMP.tar.zst</code> (ou <code>.tar.gz</code> lorsque <code>zstd</code> est absent). Le fichier contient l'arborescence entière de l'archive — <code>manifest.json</code>, <code>metadata/</code> et <code>rootfs/</code> — et peut être restauré sur n'importe quel hôte Proxmox avec le flux de restauration ProxMenux ou extrait manuellement avec <code>tar --zstd -xf</code> sur n'importe quel système Linux. Pas de serveur, pas d’initialisation de dépôt, pas de dépendance externe. C'est la destination avec le chemin de récupération le plus court lorsque ni PBS ni Borg n'est disponible."
+  },
+  "targetConfig": {
+    "heading": "Configuration du répertoire cible",
+    "intro": "La destination locale est un <strong>unique répertoire cible enregistré durablement</strong> — pas une liste. ProxMenux stocke le choix de l'opérateur chez <code>/usr/local/share/proxmenux/local-target.conf</code> et le lit sur chaque sauvegarde. Lorsqu'aucune cible n'a été configurée, le <code>HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump</code> par défaut est utilisé (le même répertoire que Proxmox utilise pour ses propres sorties <code>vzdump</code>). La cible est configurée à partir de <em>Configurer les destinations de sauvegarde → Destinations locales</em>:",
+    "options": [
+      "<strong>Utilisez par défaut (<code>/var/lib/vz/dump</code>).</strong> Le stockage local Proxmox. Présent sur chaque install Proxmox ; l'archive se trouve à côté des sorties vzdump et est captée automatiquement par l'onglet Sauvegardes du moniteur.",
+      "<strong>Entrez un chemin personnalisé.</strong> Tout chemin absolu du système de fichiers peut être utilisé : un montage NFS, un partage SMB monté via <code>fstab</code>, un jeu de données ZFS dédié, un deuxième disque interne. ProxMenux valide que le chemin existe et est un répertoire avant de l’enregistrer.",
+      "<strong>Choisissez un lecteur USB.</strong> Ouvre le sous-menu USB (ci-dessous), qui détecte les appareils amovibles et propose de monter ou de formater un périphérique."
+    ]
+  },
+  "usbFlow": {
+    "heading": "Détection et montage du lecteur USB",
+    "intro": "Le sous-menu USB énumère les partitions sur les périphériques amovibles signalées par <code>lsblk</code>. Chaque partition est présentée avec sa taille, l'étiquette du système de fichiers et l'état actuel. L'état détermine l'action ProxMenux offre.",
+    "statesTitle": "Les trois états de l'appareil",
+    "stateRows": [
+      {
+        "state": "monté",
+        "shown": "Taille · étiquette · [fstype] · → /mount/point",
+        "action": "La partition est déjà montée quelque part. La sélection enregistre le point de montage actuel en tant que cible locale. Aucun montage n'est effectué."
+      },
+      {
+        "state": "non monté",
+        "shown": "Taille · étiquette · [fstype] · (non monté — sera monté)",
+        "action": "Un système de fichiers est présent mais n'est pas monté. Lors de la confirmation, ProxMenux exécute <code>hb_mount_usb_partition</code> : crée <code>/mnt/backup-LABEL</code> (ou un chemin basé sur UUID s'il n'y a pas d'étiquette), monte la partition et persiste le point de montage comme cible locale."
+      },
+      {
+        "state": "vide",
+        "shown": "Taille · disque USB brut — aucun système de fichiers (sera FORMATÉ)",
+        "action": "Le périphérique n’a pas de système de fichiers. Cette opération destructive est protégée par deux confirmations. Une boîte de dialogue Oui/Non avertit d’abord que le disque sera effacé. Ensuite, un champ exige de <strong>saisir le chemin exact du périphérique</strong> (par exemple <code>/dev/sdb</code>) avant que ProxMenux crée une nouvelle table GPT avec une partition ext4 et la monte."
+      }
+    ],
+    "notMountedFallback": "Lorsqu'aucun périphérique USB n'est détecté, le sous-menu revient à une boîte d'entrée simple. L'opérateur peut entrer un chemin de point de montage arbitraire ; si le chemin n'est pas un point de montage enregistré, une boîte de dialogue de confirmation avertit avant de procéder."
+  },
+  "safetyCheck": {
+    "heading": "Contrôle de sécurité — destination dans un chemin de sauvegarde",
+    "body": "Avant d'écrire l'archive, <code>_bk_local</code> vérifie que le répertoire de destination n'est <strong>pas</strong> un sous-chemin d'un répertoire en cours de sauvegarde. Une erreur courante consisterait à ajouter <code>/root</code> au profil et à choisir <code>/root/backups</code> comme destination — l'archive s'inclurait alors elle-même, produisant soit une archive corrompue, soit s'agrandissant sans limite jusqu'à ce que le disque se remplisse. La vérification résout les deux chemins avec <code>readlink -m</code>, les compare et, en cas de conflit, abandonne la sauvegarde avec une boîte de dialogue qui nomme le chemin en conflit et répertorie trois façons de le résoudre : choisissez une destination en dehors du chemin en conflit, supprimez l'entrée personnalisée qui contient la destination ou utilisez le mode personnalisé pour décocher le chemin en conflit pour cette exécution."
+  },
+  "archiveFormat": {
+    "heading": "Format d'archives et compression",
+    "intro": "Le nom du fichier contient le nom d’hôte source et l’horodatage de la sauvegarde, afin de permettre un tri chronologique dans un répertoire contenant plusieurs archives et d’identifier chaque fichier.",
+    "namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS.tar.zst",
+    "compressionTitle": "Compression",
+    "compressionBody": "Le chemin primaire utilise <code>tar --zstd -cf</code> — un pipeline à commande unique qui compresse au niveau par défaut de zstd. Lorsque <code>zstd</code> n'est pas présent sur la source (rare sur Proxmox mais possible sur des installations minimales), ProxMenux revient à <code>gzip</code>. Dans le chemin de repli, si <code>pv</code> est disponible, une barre de progression est ajoutée au pipeline afin que l'opérateur voit la taille des archives croître en temps réel; sans <code>pv</code>, <code>tar -czf</code> est utilisé en silence.",
+    "sourceTitle": "Ce qui va dans l'archive",
+    "sourceBody": "La commande tar est appelée avec <code>-C \"$staging_root\" .</code>, ce qui archive <strong>toute la racine du répertoire temporaire</strong> : <code>rootfs/</code>, <code>metadata/</code> et <code>manifest.json</code>. Les trois blocs de données se trouvent côte à côte à la racine de l’archive tar. L’extraction produit exactement l’arborescence utilisée par le code de restauration."
+  },
+  "sidecar": {
+    "heading": "Le sidecar JSON",
+    "intro": "Chaque sauvegarde locale réussie produit un fichier compagnon : <code>HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json</code>, écrit à côté de l'archive par <code>hb_write_archive_sidecar</code>. Ce petit fichier JSON permet au ProxMenux Monitor d'identifier l'archive comme une sauvegarde d'hôte ProxMenux même s'il est déplacé, rebaptisé ou archivé ailleurs.",
+    "contentTitle": "Contenu du sidecar",
+    "contentBody": "Le sidecar stocke la version du schéma, que la sauvegarde soit issue d'une opération interactive ou d'un travail programmé (<code>kind</code>), l'ID de travail pour les opérations programmées, le mode de profil utilisé (<code>default</code> ou <code>custom</code>), le nom d'hôte source, le nom de base d'archive original, un horodatage de création ISO-8601 et la taille des archives en octets.",
+    "whyBody": "L'onglet Sauvegardes du moniteur scanne les répertoires locaux configurés pour les sidecars <code>*.proxmenux.json</code> — pas pour les fichiers <code>*.tar.zst</code> — parce qu'un <code>.tar.zst</code> sans sidecar pourrait ne pas être une sauvegarde ProxMenux du tout. Le scan est rapide (les fichiers JSON sont minuscules) et l'appariement est stable à travers les renoms de l'archive aussi longtemps que le sidecar est renommé pour correspondre."
+  },
+  "restoreAccess": {
+    "heading": "Restauration à partir d'une archive locale",
+    "body": "Le flux de restauration ProxMenux découvre les archives locales en scannant la cible locale configurée pour les sidecars et en les affichant dans la liste des archives. La sélection d’une archive déclenche <code>_rs_check_layout</code>, qui extrait le tarball dans un répertoire de préparation temporaire et confirme la mise en page à trois payload avant de procéder. Pour l'extraction manuelle à l'extérieur de ProxMenux, <code>tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg</code> donne le même arbre que le code de restauration consommé."
+  }
+}

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

@@ -0,0 +1,113 @@
+{
+  "meta": {
+    "title": "Proxmox Backup Server destination — dépôt, chiffrement, récupération ProxMenux",
+    "description": "La destination PBS enregistre les sauvegardes d’hôte ProxMenux au format PBS. Cette page décrit la détection des dépôts dans /etc/pve/storage.cfg, la configuration manuelle, l’envoi des archives .pxar, le chiffrement côté client avec un fichier clé et sa copie de secours facultative protégée par une phrase secrète, ainsi que sa récupération depuis plusieurs sources sur un hôte réinstallé.",
+    "ogTitle": "ProxMenux Sauvegarde — Proxmox Backup Server destination",
+    "ogDescription": "Comment ProxMenux écrit des sauvegardes d'hôte à Proxmox Backup Server avec le cryptage de fichier clé côté client et la récupération séquestre.",
+    "twitterTitle": "PBS destination de sauvegarde ProxMenux",
+    "twitterDescription": "Destination Proxmox Backup Server avec chiffrement par fichier clé et copie de récupération protégée par une phrase secrète."
+  },
+  "header": {
+    "title": "Proxmox Backup Server",
+    "description": "La destination PBS envoie tout le répertoire de préparation sous forme d’une seule sauvegarde .pxar vers un datastore Proxmox Backup Server. Le chiffrement côté client avec un fichier clé est facultatif, tout comme l’envoi, à côté de chaque sauvegarde, d’une copie de récupération de la clé protégée par une phrase secrète.",
+    "section": "Sauvegarde et restauration"
+  },
+  "recommendedBadge": "Destination recommandée",
+  "aboutPbs": {
+    "heading": "Qu'est-ce que Proxmox Backup Server",
+    "body": "Proxmox Backup Server (PBS) est le propre produit serveur de sauvegarde de Proxmox, développé et entretenu par la même équipe que les auteurs Proxmox VE. Il s'agit d'un serveur de sauvegarde dédié conçu pour recevoir des sauvegardes des hôtes Proxmox VE (VMs, LXCs et — via <code>proxmox-backup-client</code> — répertoires d'hôtes arbitraires) avec déduplication basée sur le chunk, chiffrement côté client et politiques de rétention appliquées côté serveur. ProxMenux utilise le PBS comme l'une des trois destinations pour les sauvegardes d'hôtes; chaque mécanisme spécifique au PBS décrit sur cette page (groupes de sauvegarde, archives <code>.pxar</code>, <code>--backup-id</code>, cryptage de fichiers clés) est le comportement standard du PBS."
+  },
+  "intro": {
+    "title": "Une sauvegarde par exécution, déduplication par blocs",
+    "body": "Une sauvegarde PBS crée une seule entrée dans le datastore, sous l’identifiant <code>host/hostcfg-HOSTNAME/BACKUP-TIME</code>. Les données sont une archive <code>.pxar</code> contenant la même structure en trois blocs que celle décrite dans <em>Fonctionnement</em>. PBS déduplique les blocs entre toutes les sauvegardes du datastore : les suivantes ne transfèrent et ne stockent que les blocs modifiés de cet hôte. Pour les tâches planifiées, ProxMenux applique lui-même la rétention : après chaque exécution réussie, <code>run_scheduled_backup.sh</code> lance <code>proxmox-backup-client prune</code> avec <code>--keep-last</code> / <code>--keep-daily</code> / <code>--keep-weekly</code> et les valeurs configurées pour la tâche."
+  },
+  "repoSelection": {
+    "heading": "Sélection du dépôt",
+    "intro": "ProxMenux découvre des dépôts PBS de deux sources sur chaque sauvegarde. L'opérateur en choisit un dans un menu unifié; le choix détermine <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> et <code>HB_PBS_FINGERPRINT</code> pour l'exécution.",
+    "sourceRows": [
+      {
+        "source": "storage.cfg de Proxmox (détection automatique)",
+        "path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
+        "content": "Toute stanza <code>pbs:</code> dans la configuration de stockage propre de Proxmox est captée automatiquement. Serveur, datastore, nom d'utilisateur et empreinte digitale viennent de la stanza. Le mot de passe est lu dans le propre répertoire d'identification de Proxmox. Aucune réentrée nécessaire du côté ProxMenux — le dépôt est disponible dès qu'il est configuré dans Proxmox."
+      },
+      {
+        "source": "Configuration manuelle ProxMenux",
+        "path": "/usr/local/share/proxmenux/pbs-manual-configs.txt + pbs-pass-NAME.txt + pbs-fingerprint-NAME.txt",
+        "content": "Ajouté de <em>Configurer les destinations de sauvegarde → PBS destinations → Ajouter PBS</em>. Prompts pour un nom, nom d'utilisateur (<code>root@pam</code> ou <code>user@pbs!token</code>), hôte ou IP, datastore et mot de passe. Le mot de passe reprend sur l'entrée vide — une sauvegarde vide persisterait silencieusement et chaque sauvegarde ultérieure échouerait avec une erreur d'authentification opaque. Ce chemin est utilisé lorsque la cible PBS n'est pas enregistrée comme stockage Proxmox."
+      }
+    ],
+    "menuTitle": "Menu de sélection",
+    "menuBody": "Les deux sources sont affichées dans un menu unique, chaque ligne marquée avec son origine (<code>[proxmox]</code> ou <code>[manual]</code>). Les entrées dont le mot de passe n'a pas pu être résolu sont marquées d'un avertissement <code>⚠ no password</code> – la sélection d'une entrée déclenche une réentrée de mot de passe avant le début de la sauvegarde. L'empreinte digitale est transmise à <code>proxmox-backup-client</code> via la variable d'environnement <code>PBS_FINGERPRINT</code>; en cas d'absence, le client demande à l'opérateur d'accepter le certificat serveur de manière interactive lors de la première sauvegarde."
+  },
+  "backupCommand": {
+    "heading": "La commande de sauvegarde",
+    "intro": "L’envoi se fait en un seul appel à <code>proxmox-backup-client backup</code>. ProxMenux utilise <code>env</code> pour transmettre au client le mot de passe, le mot de passe de chiffrement et l’empreinte sous forme de variables d’environnement.",
+    "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": "Nom de l'ID de sauvegarde",
+    "backupIdBody": "L’identifiant de sauvegarde par défaut est <code>hostcfg-HOSTNAME</code>. L’opérateur doit le confirmer ou le modifier avant l’envoi ; les caractères hors de <code>[A-Za-z0-9_-]</code> et les tirets finaux sont supprimés. Réutiliser le même identifiant est volontaire : PBS le considère comme un <em>groupe</em>. Chaque sauvegarde suivante devient une nouvelle entrée du groupe et partage la déduplication avec les précédentes.",
+    "pxarTitle": "Pourquoi la source est la racine de mise en scène complète",
+    "pxarBody": "La source <code>.pxar</code> est la totalité du <code>staging_root</code> — <code>rootfs/</code>, <code>metadata/</code> et <code>manifest.json</code> ensemble. Les versions antérieures ont passé le <code>$staging_root/rootfs</code> comme source; cela a laissé le <code>metadata/</code> hors de l'archive et la vérification de compatibilité de la restauration n'avait rien à lire, dégradant aux avertissements cross-host même sur les restaurations même-host. Les anciennes sauvegardes créées avec la source rootfs-only restaure toujours correctement via la branche case-<code>_rs_check_layout</code> de 3, qui enveloppe un arbre plat <code>etc/var/root/usr</code> dans une hiérarchie <code>rootfs/</code>."
+  },
+  "encryption": {
+    "heading": "Chiffrement côté client",
+    "glossaryHint": "Cette section emploie les termes <em>fichier clé</em>, <em>phrase secrète</em> et <em>enveloppe de récupération</em>. Le <glosarioLink>glossaire</glosarioLink> résume leurs différences en une phrase par terme.",
+    "intro": "Le chiffrement PBS côté client avec un fichier clé chiffre les blocs sur l’hôte source avant leur envoi. Dans ProxMenux, il est facultatif. Une fois activé, l’opérateur choisit explicitement, par oui ou non lors de la configuration, s’il faut aussi déposer sur PBS une copie de récupération du fichier clé protégée par une phrase secrète ; ce choix reste modifiable dans le moniteur. Le fichier clé se trouve toujours au chemin canonique <code>/usr/local/share/proxmenux/pbs-key.conf</code> et est réutilisé sans nouvelle demande pour chaque sauvegarde chiffrée suivante.",
+    "keyfileTitle": "Configuration du fichier de clés",
+    "keyfileBody": "Le dialogue de chiffrement apparaît lors de la première sauvegarde chiffrée de l’hôte. Il demande d’abord s’il faut chiffrer la sauvegarde : <em>Non</em> poursuit sans chiffrement, <em>Oui</em> passe à la deuxième étape. Celle-ci dépend de la présence d’un fichier clé dans <code>/usr/local/share/proxmenux/pbs-key.conf</code>. S’il existe, il est réutilisé sans nouvelle demande et la sauvegarde continue ; les suivantes ne reposent pas la question. Sinon, un menu propose deux options. <em>Générer un nouveau fichier clé</em> exécute <code>proxmox-backup-client key create --kdf none</code>. <em>Utiliser un fichier clé existant</em> détecte automatiquement une clé gérée par PVE : si le dépôt PBS choisi est enregistré dans Proxmox avec une clé de chiffrement dans <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, ce fichier est copié sans demande au chemin canonique ProxMenux. Si aucune clé PVE ne correspond au dépôt, le dialogue demande le chemin absolu où l’opérateur a déjà placé le fichier clé sur cet hôte. Dans les deux cas, le fichier est installé au chemin canonique avec <code>chmod 600</code>.",
+    "modesTitle": "Fichier clé par hôte ou partagé",
+    "modesIntro": "Les deux modes sont pris en charge, sans en imposer un : l’opérateur choisit selon l’organisation de son parc.",
+    "modesPerHostTitle": "Fichier de clés par hôte (par défaut)",
+    "modesPerHostBody": "Chaque hôte génère son propre fichier de clé la première fois qu'il permet le cryptage PBS. L'isolement est maximal : compromettre le fichier clé d'un hôte n'expose les sauvegardes d'aucun autre. Recommandé pour les flottes de production et pour les environnements où les hôtes ont différents propriétaires ou limites de conformité.",
+    "modesSharedTitle": "Fichier de clés partagé (import sur chaque hôte)",
+    "modesSharedBody": "Un fichier clé principal généré une fois et installé sur chaque hôte via l’option <em>Utiliser un fichier clé existant</em>. La gestion est plus simple: un seul secret à sauvegarder, et tout hôte peut déchiffrer les archives de n'importe quel autre (utile pour la consolidation, les exercices de restauration cross-host ou la vérification centralisée de sauvegarde). Le compromis est qu'une fuite du fichier de clés partagé expose chaque hôte à la fois. Recommandé pour les labos et les flottes où tous les hôtes ont le même propriétaire et la même limite de confiance.",
+    "recoveryTitle": "Déposer la clé sur PBS : l’opérateur décide",
+    "recoveryBody": "Juste après le choix du fichier clé, ProxMenux pose une question explicite, <em>Déposer la clé sur PBS ?</em>, avec deux réponses. <strong>Aucun élément de récupération n’est envoyé à PBS tant que l’opérateur n’a pas répondu Oui.</strong> Le choix par défaut est <em>Non, conserver uniquement en local</em> : le fichier clé reste au chemin canonique local, ProxMenux n’envoie aucun élément de récupération à PBS et l’opérateur gère lui-même la copie hors site. Le bouton <em>Télécharger le fichier clé</em> du moniteur, dans la ligne du dépôt PBS, permet de l’obtenir à la demande. Choisir <em>Oui, envoyer</em> demande deux saisies identiques d’une phrase secrète de récupération. ProxMenux protège le fichier clé avec cette phrase par AES-256-CBC et PBKDF2 (600 000 itérations, sel aléatoire), produisant <code>pbs-key.recovery.enc</code>. Chaque sauvegarde chiffrée suivante envoie cette enveloppe à PBS dans un groupe de sauvegarde associé. Ces envois ne transmettent à PBS ni la phrase secrète ni le fichier clé en clair. Le choix reste modifiable à tout moment dans le moniteur : le contrôle de la ligne PBS permet Oui ou Non et applique immédiatement Démarrer l’envoi, Arrêter l’envoi ou Modifier la phrase secrète selon l’état courant.",
+    "blobUploadTitle": "Groupe de sauvegarde associé sur PBS",
+    "blobUploadBody1": "Lorsque le mode de dépôt est <em>Oui, envoyer</em>, ProxMenux envoie l’enveloppe de récupération à PBS après chaque sauvegarde chiffrée, dans un second groupe associé. Son nom reprend celui du groupe de l’hôte avec le suffixe <code>-keyrecovery</code>. Les deux groupes se trouvent côte à côte dans le datastore : l’un pour les sauvegardes de l’hôte, l’autre pour les enveloppes de récupération. <strong>L’enveloppe ne quitte jamais l’hôte en clair</strong> : le chiffrement se fait sur l’hôte avec AES-256-CBC et PBKDF2 avant toute transmission (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS ne reçoit que l’enveloppe déjà chiffrée.",
+    "envelopeSecurityTitle": "Le téléchargement du fichier de récupération de clé vers PBS est-il un risque de sécurité?",
+    "envelopeSecurityBody": "Le fichier de récupération des clés est chiffré en transit et au repos. Le mot de passe de récupération ne quitte jamais l'hôte : le chiffrement se produit localement avant le téléchargement, et PBS ne voit que le résultat déjà chiffré. Un administrateur PBS — ou toute personne ayant accès à la datastore — peut télécharger le fichier de récupération de clé, mais sans la phrase de récupération, ils ne peuvent pas lire le fichier de clé à l'intérieur : c'est un chiffrement opaque. Reconstruire le fichier de clés nécessite les deux pièces à la fois, le fichier de récupération de clés et la phrase de passe, et seul l'opérateur détient les deux.",
+    "blobUploadConstraintTitle": "Pourquoi deux groupes au lieu d'un seul crypté",
+    "blobUploadConstraintBody": "Un seul appel à <code>proxmox-backup-client backup</code> chiffre toutes ses archives avec le même fichier clé, ou aucune : il ne permet pas de mélanger les deux. La sauvegarde de l’hôte doit être chiffrée avec sa clé, mais l’enveloppe de récupération ne peut pas être envoyée dans le même appel : elle serait alors chiffrée avec le fichier clé qu’elle contient. Sur un hôte réinstallé, il serait impossible de l’ouvrir, puisqu’il faudrait la clé pour déchiffrer cette même clé. Les deux éléments sont donc envoyés indépendamment et apparaissent dans deux groupes. Le client PBS chiffre la sauvegarde de l’hôte avec le fichier clé ; ProxMenux chiffre l’enveloppe avec la phrase secrète avant son envoi. Deux couches de chiffrement distinctes protègent deux éléments différents.",
+    "blobUploadImageAlt": "PBS UI montrant les groupes de sauvegarde hostcfg-HOSTNAME et hostcfg-HOSTNAME-keyrecovery adjacents à la liste datastore.",
+    "blobUploadImageCaption": "PBS UI — les groupes de sauvegarde appariés. Le groupe principal détient les sauvegardes de l'hôte; le groupe -keyrecovery détient le fichier de clés enveloppé de la phrase de passe.",
+    "recoverTitle": "Récupération sur un hôte frais",
+    "recoverBody": "Lorsque le fichier clé manque au chemin canonique, après une réinstallation ou une suppression explicite, la restauration essaie trois sources dans l’ordre et retient la première clé utilisable. D’abord, si une clé gérée par PVE correspond au dépôt PBS choisi dans <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, elle est copiée sans demande au chemin canonique. Ensuite, si un groupe <code>-keyrecovery</code> existe sur PBS, son instantané le plus récent est téléchargé et la phrase secrète de récupération est demandée pour le déchiffrer. Enfin, si les deux options échouent ou sont refusées, le dialogue demande le chemin absolu du fichier clé sur cet hôte et le copie au chemin canonique. Le moniteur propose le même import dans la fenêtre de détail de la sauvegarde. Un panneau ambre apparaît en haut lorsque Restaurer, Télécharger ou Voir le contenu nécessite une clé absente. Si une clé est installée mais ne correspond pas à celle du chiffrement, PBS renvoie <code>wrong key — manifest's key XX does not match provided key YY</code>. Les mêmes trois actions affichent alors un panneau structuré mettant en évidence l’empreinte exigée par le manifeste, afin de déterminer quelle clé importer pour ouvrir cette sauvegarde.",
+    "monitorManagementTitle": "Gestion du fichier clé depuis le moniteur",
+    "monitorManagementBody": "Le moniteur affiche les commandes du fichier clé directement dans chaque ligne de destination PBS de la page de configuration des sauvegardes. Trois actions sont proposées : <em>Télécharger</em> exporte le fichier actuel vers le navigateur ; <em>Envoyer</em> remplace le fichier installé par celui fourni par l’opérateur, l’ancien n’étant écrasé qu’après l’installation réussie du nouveau au chemin canonique ; <em>Supprimer</em> retire le fichier de l’hôte. À côté figure le contrôle du dépôt de récupération : un choix Oui/Non pour <em>Déposer la clé sur PBS ?</em>, un champ de phrase secrète si Oui est choisi et un bouton d’application contextuel indiquant <em>Démarrer l’envoi</em>, <em>Arrêter l’envoi</em> ou <em>Modifier la phrase secrète</em>. Chaque action utilise les mêmes points d’accès Flask que l’interface de terminal : l’effet sur disque et l’état sur PBS sont donc identiques depuis les deux interfaces."
+  },
+  "restoreAccess": {
+    "heading": "Récupération du côté restauration",
+    "body": "La restauration repère les sauvegardes d’hôte ProxMenux sur PBS en listant les groupes du dépôt configuré puis en filtrant leur identifiant. L’onglet Sauvegardes du moniteur affiche la même liste. Choisir une sauvegarde lance <code>proxmox-backup-client restore</code> avec le même dépôt, mot de passe et empreinte, ainsi que <code>--keyfile</code> si elle est chiffrée. L’archive <code>.pxar</code> est extraite dans un répertoire de préparation que <code>_rs_check_layout</code> transmet au processus de restauration standard. Hors de ProxMenux, la même commande extrait l’archive à l’emplacement souhaité pour examiner l’arborescence ou effectuer une restauration manuelle."
+  },
+  "references": {
+    "heading": "Références",
+    "intro": "Documentation officielle de Proxmox Backup Server pour les composants utilisés par ProxMenux.",
+    "items": [
+      {
+        "label": "Documentation Proxmox Backup Server",
+        "href": "https://pbs.proxmox.com/docs/",
+        "tail": "— point d'entrée principal couvrant l'installation, l'administration, le stockage, les utilisateurs et les rôles."
+      },
+      {
+        "label": "proxmox-backup-client",
+        "href": "https://pbs.proxmox.com/docs/backup-client.html",
+        "tail": " — l’outil en ligne de commande appelé par ProxMenux pour chaque sauvegarde et restauration. Décrit les identifiants et types de sauvegarde, les archives, la syntaxe des dépôts et les variables d’environnement."
+      },
+      {
+        "label": "Chiffrement côté client",
+        "href": "https://pbs.proxmox.com/docs/backup-client.html#encryption",
+        "tail": " — création du fichier clé, modes --kdf et modèle de chiffrement que ProxMenux complète par une copie de récupération protégée par une phrase secrète."
+      },
+      {
+        "label": "Gestion des Datastore",
+        "href": "https://pbs.proxmox.com/docs/storage.html",
+        "tail": " — création et gestion des datastores qui reçoivent les sauvegardes d’hôte, avec la structure du stockage des blocs et les permissions."
+      },
+      {
+        "label": "Élagage des sauvegardes et récupération d’espace",
+        "href": "https://pbs.proxmox.com/docs/maintenance.html#pruning",
+        "tail": " — le modèle de rétention de --keep-last / --keep-daily / --keep-weekly que ProxMenux applique par tâche planifiée, et la récupération des blocs inutilisés par PBS après l’élagage."
+      }
+    ]
+  }
+}

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

@@ -0,0 +1,230 @@
+{
+  "meta": {
+    "title": "Glossaire — Sauvegarde et restauration ProxMenux",
+    "description": "Glossaire des termes et définitions de la pile de sauvegarde et de restauration ProxMenux: chiffrement, fichier de clés, mots de passe, enveloppe de récupération, PBS, morceaux, rootfs, manifeste, hydratation coureur et cross-kernel.",
+    "ogTitle": "Glossaire de la sauvegarde et de la restauration | ProxMenux",
+    "ogDescription": "Définitions claires des termes utilisés dans la documentation de sauvegarde et de restauration ProxMenux.",
+    "twitterTitle": "Glossaire de la sauvegarde et de la restauration | ProxMenux",
+    "twitterDescription": "Phrase de passe, fichier clé, enveloppe de récupération, rootfs, manifeste, PBS, morceaux — tous définis en un seul endroit."
+  },
+  "header": {
+    "title": "Glossaire",
+    "description": "Termes utilisés dans la documentation de sauvegarde et de restauration, avec leur définition.",
+    "section": "Sauvegarde et restauration"
+  },
+  "intro": {
+    "body": "Les termes sont regroupés par thème. Chaque entrée donne le terme et une courte définition."
+  },
+  "groups": [
+    {
+      "title": "Chiffrement et récupération des clés",
+      "intro": "Vocabulaire pour le bloc de chiffrement PBS. Il implique deux secrets distincts: un fichier de clés binaires et une phrase de passe écrite.",
+      "entries": [
+        {
+          "id": "passphrase-recuperacion",
+          "term": "Phrase secrète de récupération",
+          "def": "Mot de passe texte choisi par l'utilisateur pour protéger l’<a href=\"#sobre-recuperacion\">enveloppe de récupération</a>. Il est demandé deux fois avec une vérification de correspondance, et n'est utilisé que pour chiffrer l'enveloppe et la déchiffrer si le fichier clé a besoin d'être récupéré. <strong>Ce n'est pas la phrase de passe qui déverrouille le fichier clé lui-même</strong>, et il n'est jamais envoyé à PBS. Pendant une sauvegarde normale, il ne quitte jamais l'hôte."
+        },
+        {
+          "id": "clave-cifrado",
+          "term": "Fichier-clé (clé de chiffrement)",
+          "def": "Fichier de clé utilisé par proxmox-backup-client pour chiffrer les <a href=\"#chunk\">blocs</a> avant leur envoi à PBS. Sans la clé correspondante, les données chiffrées sont illisibles. ProxMenux le stocke dans <code>/usr/local/share/proxmenux/pbs-key.conf</code> avec le mode <code>600</code>. Protégez-le : l’<a href=\"#sobre-recuperacion\">enveloppe de récupération</a> permet de le récupérer en cas de perte."
+        },
+        {
+          "id": "contrasena-keyfile",
+          "term": "Phrase de passe du fichier clé (phrase de passe KDF)",
+          "def": "Phrase de passe optionnelle que le fichier clé lui-même peut porter, distincte de la <a href=\"#passphrase-recuperacion\">phrase de passe de récupération</a>. Il n'existe que lorsque le fichier clé a été créé avec <code>--kdf scrypt</code> (généralement un fichier clé importé). Sans cela, le fichier clé ne peut pas être déverrouillé pour utilisation. ProxMenux le maintient sous forme chiffrée sur l'hôte afin que les sauvegardes programmées puissent fonctionner sans une demande interactive."
+        },
+        {
+          "id": "sobre-recuperacion",
+          "term": "Enveloppe de récupération",
+          "def": "Le fichier <a href=\"#clave-cifrado\">keyfile</a> enveloppé dans une couche supplémentaire: il est crypté avec la <a href=\"#passphrase-recuperacion\">phrase de passe de récupération</a> utilisant <a href=\"#aes-256-cbc\">AES-256-CBC</a> et <a href=\"#pbkdf2\">PBKDF2</a> avant de quitter l'hôte. C'est ce qui est téléchargé sur PBS en tant que groupe <code>-keyrecovery</code>. Sans la phrase de passe, l'enveloppe est opaque : le téléchargement de PBS ne révèle pas le fichier de clés."
+        },
+        {
+          "id": "cifrado-cliente",
+          "term": "Chiffrement côté client",
+          "def": "Modèle de chiffrement dans lequel les données sont chiffrées sur l'hôte source avant d'être téléchargées. PBS ne reçoit et stocke que du texte codé; même un administrateur PBS avec accès datastore ne peut pas le lire sans le fichier clé. ProxMenux s'appuie sur ce modèle et ajoute l’<a href=\"#sobre-recuperacion\">enveloppe de récupération</a> sur le dessus."
+        },
+        {
+          "id": "kdf-none",
+          "term": "--kdf none",
+          "def": "Option de <code>proxmox-backup-client key create</code> qui produit un fichier de clés sans phrase de passe jointe. Le fichier de clés peut être utilisé directement sans une prompte, ce qui est essentiel pour les travaux programmés qui ne sont pas surveillés. C'est ce que ProxMenux utilise par défaut lors de la génération d'un nouveau fichier clé."
+        },
+        {
+          "id": "kdf-scrypt",
+          "term": "--kdf scrypt",
+          "def": "Option pour <code>proxmox-backup-client key create</code> qui produit un fichier clé protégé par une <a href=\"#contrasena-keyfile\">phrase de passe du fichier de clé</a>. Chaque utilisation du fichier clé nécessite de le déverrouiller avec cette phrase de passe. ProxMenux accepte ce style de keyfile sur l'importation et stocke la phrase de passe cryptée afin que les sauvegardes programmées puissent toujours fonctionner sans surveillance."
+        },
+        {
+          "id": "aes-256-cbc",
+          "term": "AES-256-CBC",
+          "def": "Chiffrement symétrique standard. ProxMenux l’utilise via <code>openssl enc -aes-256-cbc</code> pour protéger le <a href=\"#clave-cifrado\">fichier de clé</a> avec la <a href=\"#passphrase-recuperacion\">phrase de passe de récupération</a> et produire l’<a href=\"#sobre-recuperacion\">enveloppe</a>."
+        },
+        {
+          "id": "pbkdf2",
+          "term": "PBKDF2",
+          "def": "Fonction cryptographique qui transforme une phrase de passe de type humain en une clé binaire adaptée au chiffrement. Il ralentit les tentatives de force brute en appliquant de nombreuses itérations. ProxMenux l'utilise avec des itérations 600 000 et un sel aléatoire lors du chiffrement de l'enveloppe de récupération."
+        }
+      ]
+    },
+    {
+      "title": "Structure de sauvegarde",
+      "intro": "Termes décrivant ce qui vit dans une sauvegarde, quelle que soit la destination.",
+      "entries": [
+        {
+          "id": "rootfs",
+          "term": "rootfs / système de fichiers racine",
+          "def": "Copie des fichiers de l’hôte source réalisée par <code>rsync</code> selon le <a href=\"#perfil-defecto\">profil par défaut</a> et les <a href=\"#rutas-personalizadas\">chemins personnalisés</a>. Ce n’est pas une image de disque complet : seuls sont copiés les chemins contenant la configuration ou l’état que Proxmox ne peut pas recréer seul."
+        },
+        {
+          "id": "manifiesto",
+          "term": "Manifeste (manifest.json)",
+          "def": "Document structuré JSON décrivant l'hôte source au moment de la sauvegarde : matériel, stockage, noyau, composants installés par ProxMenux et inventaire des VM et des LXC. Il est produit par six collecteurs indépendants. Le flux de restauration l'utilise pour comparer la source et la cible."
+        },
+        {
+          "id": "staging",
+          "term": "Répertoire de préparation",
+          "def": "Répertoire temporaire où ProxMenux assemble les trois blocs (rootfs, métadonnées et manifeste) avant de les emballer et de les télécharger vers la destination. Il est supprimé automatiquement lorsque la sauvegarde se termine, même sur avorter."
+        },
+        {
+          "id": "perfil-defecto",
+          "term": "Profil par défaut",
+          "def": "Ensemble sélectionné de chemins copiés par défaut dans chaque sauvegarde : configuration PVE, réseau, SSH, noyau, apt, outils ProxMenux et plus encore. Défini dans le code et documenté sur la page <em>Comment ça marche</em>."
+        },
+        {
+          "id": "rutas-personalizadas",
+          "term": "Chemins personnalisés",
+          "def": "Les chemins supplémentaires que l'utilisateur ajoute au dessus du <a href=\"#perfil-defecto\">profil par défaut</a>. Soit persistante (conservée en <code>backup-extra-paths.txt</code>) soit per-run (en mode personnalisé)."
+        }
+      ]
+    },
+    {
+      "title": "Destinations et stockage",
+      "intro": "Termes liés à l'emplacement de la sauvegarde — serveur PBS, archive locale ou dépôt Borg — et comment PBS organise les données.",
+      "entries": [
+        {
+          "id": "repositorio-pbs",
+          "term": "Dépôt PBS",
+          "def": "Combinaison de Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + utilisateur qui reçoit la sauvegarde. Identifié par la chaîne <code>user@realm@host:datastore</code>. Un seul serveur PBS peut héberger plusieurs dépôts."
+        },
+        {
+          "id": "datastore",
+          "term": "Banque de données",
+          "def": "Espace de stockage précis dans un serveur PBS contenant les sauvegardes et leurs blocs. Chaque datastore repose sur un système de fichiers du serveur PBS avec ses propres permissions et politiques."
+        },
+        {
+          "id": "chunk",
+          "term": "Bloc (chunk) / déduplication par blocs",
+          "def": "PBS divise chaque sauvegarde en morceaux de taille variable, identifie chaque morceau par son hachage et ne stocke chaque morceau qu'une seule fois, même s'il apparaît dans de nombreuses sauvegardes différentes. Cela signifie que les sauvegardes successives d'un même hôte — ou d'un hôte similaire — prennent très peu d'espace supplémentaire."
+        },
+        {
+          "id": "fingerprint",
+          "term": "Empreinte",
+          "def": "Empreinte cryptographique du certificat du serveur PBS TLS Il permet au client de vérifier qu'il parle au serveur prévu sans compter sur une autorité de certification publique. ProxMenux le transmet à <code>proxmox-backup-client</code> via la variable d'environnement <code>PBS_FINGERPRINT</code>."
+        },
+        {
+          "id": "grupo-copia",
+          "term": "Groupe de sauvegarde",
+          "def": "Conteneur logique à l'intérieur de PBS sous lequel les sauvegardes successives du même actif s'accumulent. Chaque nouvelle sauvegarde partage la déduplication avec les précédentes dans le même groupe. ProxMenux utilise deux groupes par hôte lorsque le chiffrement est activé : un pour la sauvegarde de l'hôte et un avec un suffixe <code>-keyrecovery</code> pour l’<a href=\"#sobre-recuperacion\">enveloppe de récupération</a>."
+        },
+        {
+          "id": "backup-id",
+          "term": "ID de sauvegarde",
+          "def": "Nom du groupe <a href=\"#grupo-copia\">backup</a>. ProxMenux par défaut sur <code>hostcfg-HOSTNAME</code> et permet à l'utilisateur de l'éditer avant le téléchargement; les caractères non pris en charge sont supprimés automatiquement."
+        },
+        {
+          "id": "pxar",
+          "term": ".pxar",
+          "def": "Format d'archive native PBS pour les répertoires. Il se comporte comme un tar optimisé pour la déduplication des morceaux : au lieu de stocker un fichier opaque, PBS brise son contenu en morceaux réutilisables."
+        }
+      ]
+    },
+    {
+      "title": "Exécution et calendrier",
+      "intro": "Termes utilisés par le système ProxMenux emploi programmé.",
+      "entries": [
+        {
+          "id": "runner",
+          "term": "Processus d'exécution",
+          "def": "Le script <code>run_scheduled_backup.sh</code> qui exécute une sauvegarde programmée. Il lit la configuration du travail, lance le moteur correspondant (Local, PBS ou Borg), applique la conservation sur le succès et envoie les notifications configurées."
+        },
+        {
+          "id": "trabajo-programado",
+          "term": "Tâche planifiée",
+          "def": "Configuration permanente d'une sauvegarde récurrente. Tient destination, identifiants, chiffrement, calendrier et conservation. Vit à <code>/var/lib/proxmenux/backup-jobs/&lt;id&gt;.env</code>."
+        },
+        {
+          "id": "modo-adjunto",
+          "term": "Mode rattaché",
+          "def": "Tâche sans timer propre. Un hook job-end de PVE <code>vzdump</code> la déclenche après les sauvegardes des invités si le stockage correspond. La tâche parent fournit la destination et la conservation, relue depuis la tâche parent à chaque exécution, mais le hook compare le stockage, pas l’ID parent. Une autre tâche sur ce stockage peut aussi la déclencher. Uniquement Local et PBS."
+        },
+        {
+          "id": "timer-systemd",
+          "term": "Systemd minuterie",
+          "def": "Mécanisme standard systemd qui déclenche une commande sur un calendrier. ProxMenux crée une minuterie par <em>indépendant</em> emploi programmé; <a href=\"#modo-adjunto\"> mode rattaché</a> emplois n'utilisent pas de minuterie, ils fonctionnent via le script PVE-hook."
+        },
+        {
+          "id": "retencion",
+          "term": "Conservation (keep-last, keep-daily…)",
+          "def": "Politique qui décide quelles sauvegardes plus anciennes à conserver et à pruner. Défini par travail avec des paramètres comme <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. Appliquée par le processus d’exécution après chaque sauvegarde réussie."
+        }
+      ]
+    },
+    {
+      "title": "Restaurer",
+      "intro": "Termes du flux de restauration.",
+      "entries": [
+        {
+          "id": "restauracion-universal",
+          "term": "Restauration universelle",
+          "def": "Le flux de restauration ProxMenux n'extrait pas seulement le système de fichiers : il lit le manifeste pour repérer les différences entre la source et la cible, reproduit la configuration du système et réexécute les installateurs des composants gérés par ProxMenux. Le but est de reproduire l'hôte source, pas seulement l'archive."
+        },
+        {
+          "id": "hidratacion",
+          "term": "Hydratation entre versions du noyau",
+          "def": "Étape de restauration qui fusionne les réglages de l’utilisateur depuis la source (paramètres IOMMU, ID VFIO, particularités et clés GRUB) avec la configuration de démarrage neuve de la cible, sans recopier tels quels les fichiers liés au noyau source. S’exécute si le noyau cible est plus récent que celui de la sauvegarde."
+        },
+        {
+          "id": "cross-kernel",
+          "term": "Restaurer le cross-kernel",
+          "def": "Restaurer où le noyau de la cible diffère de (habituellement est plus récent que) celui de la source. Nécessite le passage <a href=\"#hidratacion\">hydration</a> pour éviter de traîner le long de fichiers incompatibles avec le noyau de la cible."
+        },
+        {
+          "id": "instalador-postboot",
+          "term": "Installation après démarrage",
+          "def": "Composants réinstallés après le premier démarrage de l'hôte restauré (drivers NVIDIA, drivers Coral TPU, outils AMD GPU, outils Intel GPU). Chaque installateur fonctionne contre le noyau de la cible, de sorte que l'hôte restauré ne dépend pas de la présence du noyau de la source."
+        },
+        {
+          "id": "compatibility-check",
+          "term": "Vérification de compatibilité",
+          "def": "Comparaison entre le manifeste source et l'état de la cible que ProxMenux effectue au début de la restauration. Il décide quelles parties sont copiées mot à mot, qui ont besoin d'hydratation et qui sont recréées par un installateur."
+        },
+        {
+          "id": "equipo-recien-instalado",
+          "term": "Installation fraîche",
+          "def": "Hôte juste réinstallé à partir de zéro, sans fichier local <a href=\"#clave-cifrado\">key</a>. La restauration d'une sauvegarde chiffrée nécessite d'abord la récupération du fichier clé à partir de l’<a href=\"#sobre-recuperacion\">enveloppe</a> stockée sur PBS, en utilisant la phrase de passe <a href=\"#passphrase-recuperacion\">de récupération</a>."
+        }
+      ]
+    }
+  ],
+  "whereNext": {
+    "heading": "Où après",
+    "items": [
+      {
+        "label": "Comment ça marche",
+        "href": "/docs/backup-restore/how-it-works",
+        "tail": " — où se placent rootfs, le manifeste et l’inventaire des applications dans une sauvegarde."
+      },
+      {
+        "label": "Destination Proxmox Backup Server",
+        "href": "/docs/backup-restore/destinations/pbs",
+        "tail": "— où le cryptage côté client, le fichier clé, la phrase de récupération et l'enveloppe sont documentés en profondeur."
+      },
+      {
+        "label": "Restauration",
+        "href": "/docs/backup-restore/restoring",
+        "tail": " — procédure de restauration et utilisation du manifeste."
+      }
+    ]
+  }
+}

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

@@ -0,0 +1,205 @@
+{
+  "meta": {
+    "title": "Comment ProxMenux Sauvegarde fonctionne en interne — rootfs, manifeste, applications",
+    "description": "Description détaillée de ce qu'une sauvegarde ProxMenux contient : les rootfs produits par rsync du profil de chemin par défaut, le manifeste structuré construit par six collecteurs indépendants, et l'inventaire d'applications qui entraîne la réinstallation automatique des paquets et des composants après une restauration.",
+    "ogTitle": "Comment la sauvegarde ProxMenux fonctionne en interne",
+    "ogDescription": "Les trois parties d’une sauvegarde ProxMenux : rootfs, manifeste et applications.",
+    "twitterTitle": "Fonctionnement des sauvegardes ProxMenux | ProxMenux",
+    "twitterDescription": "Les trois charges utiles d'une sauvegarde ProxMenux et comment la restauration reproduit l'hôte source à partir d'eux."
+  },
+  "header": {
+    "title": "Comment ça marche",
+    "description": "La structure interne d’une sauvegarde ProxMenux — système de fichiers, manifeste et inventaire des applications — et leur utilisation pour recréer l’hôte source sur une destination dont le noyau peut être différent.",
+    "section": "Sauvegarde et restauration"
+  },
+  "intro": {
+    "title": "Une archive, trois charges utiles",
+    "body": "Chaque sauvegarde crée trois parties bien définies dans un même répertoire de préparation. L’archive envoyée à la destination (<code>.tar.zst</code> local, sauvegarde PBS ou archive Borg) conserve cette structure. La restauration utilise les trois : <strong>le manifeste</strong> est consulté avant toute modification pour détecter les différences et déterminer les exclusions ; <strong>rootfs</strong> fournit les fichiers de configuration, appliqués à chaud ou après redémarrage ; <strong>l’inventaire des applications</strong> guide l’installation des paquets et la réinstallation des composants après démarrage. Chaque partie peut être examinée ou extraite indépendamment."
+  },
+  "layout": {
+    "heading": "Mise en page des archives",
+    "intro": "Chaque archive suit la même disposition de l'arbre, quelle que soit la destination. Le sous-répertoire <code>metadata/</code> détient les charges utiles structurées; le sous-répertoire <code>rootfs/</code> détient la copie du système de fichiers.",
+    "treeCaption": "Le répertoire de mise en scène a été établi lors d'une sauvegarde. Chaque destination reçoit le même arbre (adapté à son format natif: tar pour local, PBS morceaux pour PBS, segments borg pour Borg).",
+    "tree": "backup-[timestamp]/\n├── manifest.json                  # structured host state\n├── metadata/\n│   ├── packages.manual.list       # apt-mark showmanual\n│   ├── run_info.env               # backup run identity + kernel version + pmxcfs method\n│   ├── paths_archived.txt         # exact list of paths that reached rootfs/\n│   └── missing_paths.txt          # paths from the profile absent on source\n└── rootfs/\n    ├── etc/                       # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, …\n    ├── root/                      # /root (with volatile subdirs excluded)\n    ├── usr/local/                 # /usr/local/bin, /usr/local/share/proxmenux, …\n    └── var/                       # /var/lib/pve-cluster (config.db via sqlite3 .backup), /var/spool/cron/…"
+  },
+  "rootfs": {
+    "heading": "La partie rootfs",
+    "intro": "L’arborescence <code>rootfs/</code> est une <strong>simple copie du système de fichiers</strong>, créée par <code>rsync</code> depuis l’hôte source. Elle contient un <strong>profil par défaut</strong> sélectionnant les chemins nécessaires à une restauration Proxmox, ainsi que les <strong>chemins personnalisés</strong> ajoutés à la tâche ou à la session interactive. La sélection est volontairement limitée aux chemins qui <em>contiennent de la configuration</em> ou <em>conservent un état que Proxmox ne peut pas recréer seul</em>.",
+    "defaultProfileTitle": "Le profil par défaut",
+    "defaultProfileBody": "Le profil par défaut est défini par <code>hb_default_profile_paths</code> dans <code>lib_host_backup_common.sh</code>. Il couvre huit catégories fixes, plus l’état ZFS si nécessaire, qui décrivent ensemble un hôte Proxmox fonctionnel :",
+    "categoriesTitle": "Catégories de chemins",
+    "categoryRows": [
+      {
+        "category": "Noyau PVE",
+        "paths": "/etc/pve, /var/lib/pve-cluster, /etc/vzdump.conf",
+        "why": "Contenus du système de fichiers cluster et vzdump par défaut. La base de données pmxcfs (<code>config.db</code>) est capturée comme un instantané cohérent via <code>sqlite3 .backup</code> sans arrêter le cluster, et les sidecars <code>.db-wal</code> / <code>.db-shm</code> sont exclus du rsync. Lorsque <code>sqlite3</code> n'est pas disponible, un fichier <code>config.db.raw-fallback</code> est créé puis utilisé automatiquement comme base lors de la restauration."
+      },
+      {
+        "category": "Identité de l'hôte & réseau",
+        "paths": "/etc/hostname, /etc/hosts, /etc/timezone, /etc/resolv.conf, /etc/network, /etc/systemd/network",
+        "why": "Les éléments nécessaires pour retrouver le réseau avec la même identité. Les fichiers <code>.link</code> dans <code>/etc/systemd/network</code> associent le nom des interfaces à leur adresse MAC, afin de conserver les noms lors des réinstallations et des changements matériels."
+      },
+      {
+        "category": "Accès et authentification",
+        "paths": "/etc/ssh, /etc/sudoers, /etc/sudoers.d, /etc/pam.d, /etc/security",
+        "why": "Clés SSH, règles sudo et configuration PAM. Les perdre peut empêcher l’utilisateur d’accéder à l’hôte restauré."
+      },
+      {
+        "category": "Noyau et démarrage",
+        "paths": "/etc/default/grub, /etc/kernel, /etc/modules, /etc/modules-load.d, /etc/modprobe.d, /etc/sysctl.conf, /etc/sysctl.d, /etc/udev/rules.d, /etc/fstab, /etc/iscsi, /etc/multipath",
+        "why": "IOMMU jetons, listes noires de module, ID de périphérique VFIO, table de montage, configuration de la pile de stockage."
+      },
+      {
+        "category": "Shell et paramètres régionaux",
+        "paths": "/etc/environment, /etc/bash.bashrc, /etc/inputrc, /etc/profile, /etc/profile.d, /etc/locale.gen, /etc/locale.conf",
+        "why": "Configuration shell à l'échelle du système, variables d'environnement, configuration de génération locale."
+      },
+      {
+        "category": "Gestion des paquets et cron",
+        "paths": "/etc/apt, /etc/cron.d, /etc/cron.{daily,hourly,weekly,monthly}, /etc/cron.allow, /etc/cron.deny, /var/spool/cron/crontabs",
+        "why": "Sources APT pour une résolution de paquets cohérente, tâches programmées définies par l'utilisateur."
+      },
+      {
+        "category": "État et outils ProxMenux",
+        "paths": "/etc/proxmenux, /etc/systemd/system, /etc/log2ram.conf, /etc/logrotate.conf, /etc/logrotate.d, /etc/lm-sensors, /etc/sensors3.conf, /etc/fail2ban, /etc/snmp, /etc/postfix, /etc/wireguard, /etc/openvpn, /etc/grafana, /etc/influxdb, /etc/prometheus, /etc/telegraf, /etc/zabbix",
+        "why": "Outillage facultatif mais courant Proxmox. Les chemins manquants sont notés dans <code>metadata/missing_paths.txt</code> sans arrêter la sauvegarde."
+      },
+      {
+        "category": "Exécutables ProxMenux et compte root",
+        "paths": "/usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux, /var/lib/proxmenux, /root (sous-dirs volatils exclus)",
+        "why": "Les binaires installés par ProxMenux et la configuration par utilisateur sous <code>/root</code>. Les chemins volatils (<code>.bash_history</code>, <code>.cache/</code>, <code>tmp/</code>, <code>.local/share/Trash/</code>) sont exclus de la copie. <code>/var/lib/proxmenux</code> détient les tâches de sauvegarde programmées et l'état de l'hôte conservé par ProxMenux; la mise en scène de restauration, les copies de retour et les marqueurs post-restauration sont exclus, parce qu'ils appartiennent à l'hôte qui exécute une restauration."
+      },
+      {
+        "category": "État ZFS (conditionnel)",
+        "paths": "/etc/zfs",
+        "why": "Seulement inclus lorsque l'hôte source exécute ZFS. Contient <code>zpool.cache</code> et <code>hostid</code>."
+      }
+    ],
+    "customTitle": "Extension du profil avec des chemins personnalisés",
+    "customBody": "Au-delà du profil par défaut, ProxMenux offre deux façons d'inclure des chemins supplémentaires dans une sauvegarde. Ils composent sans conflit et s'appliquent à la fois aux sauvegardes interactives et aux emplois programmés.",
+    "customExtrasTitle": "1. Extras persistants (fichier par hôte)",
+    "customExtrasBody": "Un fichier texte à <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code> contient une liste de chemins absolus que l'utilisateur a marqués comme « toujours inclure » sur cet hôte. Lorsqu'une sauvegarde fonctionne en mode <strong>Default</strong>, ProxMenux ajoute ces chemins au profil par défaut automatiquement sans demander. Le fichier est édité à partir de l'interface — pas d'édition manuelle nécessaire — et persiste à travers les reboots et les mises à jour. Un chemin absolu par ligne ; les commentaires <code>#</code> sont autorisés.",
+    "customModeTitle": "2. Mode personnalisé (par exécution)",
+    "customModeBody": "Lancer une sauvegarde en mode <strong>Custom</strong> remplace l'application automatique du profil par défaut par une liste de contrôle montrant chaque chemin : les entrées par défaut du profil et les extras persistants (préfixés avec <code>[+]</code> et pré-cochés). L'utilisateur coche ou désactive les entrées pour cette exécution spécifique, et peut également appuyer sur <em>Ajouter un chemin personnalisé</em> pour entrer un nouveau chemin — qui est ensuite maintenu dans le fichier extras pour les futures sauvegardes.",
+    "customMissingTitle": "Voies absentes de la source",
+    "customMissingBody": "Tout chemin du profil (par défaut ou ajouté) qui n'existe pas sur l'hôte source est enregistré dans <code>metadata/missing_paths.txt</code> à l'intérieur de l'archive. La sauvegarde n’échoue ni ne s'arrête — l'utilisateur voit un résumé des chemins archivés et des chemins manquants à la fin. En pratique, cela se produit pour les chemins optionnels d'outillage comme <code>/etc/wireguard</code> ou <code>/etc/prometheus</code> lorsque ces outils ne sont pas installés."
+  },
+  "manifest": {
+    "heading": "La partie manifeste",
+    "intro": "<code>manifest.json</code> est un document structuré JSON qui décrit l'hôte source au moment de la sauvegarde. Il est produit par <strong>six modules de collecte indépendants</strong> orchestrés par <code>build_manifest.sh</code>. Chaque collecteur est en lecture seule, produit un fragment JSON bien défini, et revient à une valeur par défaut vide s'il échoue – le manifeste est toujours utilisable si une section est incomplète.",
+    "orchestratorCaption": "Les six modules de collecte composent le manifeste. Chaque collecteur fonctionne dans son propre sous-processus; une défaillance d'un seul tombe à un défaut de sécurité documenté et avertit mais n'interrompt pas la sauvegarde.",
+    "collectorRows": [
+      {
+        "collector": "collect_source_host.sh",
+        "produces": "source_host",
+        "content": "Nom d'hôte, version PVE (<code>pveversion</code>), version PBS si l'hôte exécute le rôle de serveur de sauvegarde, noyau (<code>uname -r</code>), mode de démarrage (efi/bios), type de système de fichiers racine, modèle CPU + architecture, mémoire en KB."
+      },
+      {
+        "collector": "collect_hardware.sh",
+        "produces": "hardware_inventory",
+        "content": "GPU avec fabricant et correspondance avec l’installateur ProxMenux ; TPU Coral USB et M.2 détectés par <code>lsusb</code>/<code>lspci</code> ; interfaces réseau avec MAC, emplacement PCI et appartenance à un pont ; périphériques sans fil. Les entrées GPU comprennent l’heuristique <code>passthrough_eligible</code>."
+      },
+      {
+        "collector": "collect_storage.sh",
+        "produces": "storage_inventory",
+        "content": "ZFS pools (avec pool type + disques membres résolus à <code>/dev/disk/by-id/*</code>, <code>/dev/disk/by-partuuid/*</code> ou crus <code>/dev/sdX</code> chemins en fonction de la façon dont chaque pool a été créé à l'origine), LVM Groupes de volume + mince pools, disques physiques avec SMART capacité, PVE <code>storage.cfg</code> entrées, montages externes."
+      },
+      {
+        "collector": "collect_kernel.sh",
+        "produces": "kernel_params",
+        "content": "Paramètres ajoutés par l’opérateur dans <code>/proc/cmdline</code>, sans les éléments standard comme <code>BOOT_IMAGE=</code>, <code>root=</code>, <code>ro/rw</code>, <code>quiet</code> et <code>splash</code> ; modules chargés au démarrage depuis <code>/etc/modules</code> ; chemins des fichiers <code>/etc/modprobe.d/*.conf</code> contenant des directives effectives (<code>options</code>, <code>blacklist</code>, <code>install</code>, <code>alias</code>, <code>softdep</code>)."
+      },
+      {
+        "collector": "collect_proxmenux_state.sh",
+        "produces": "proxmenux_installed_components",
+        "content": "Lire <code>/usr/local/share/proxmenux/managed_installs.json</code> (enregistrement de tout ce que ProxMenux a installé) et <code>installed_tools.json</code>. Chaque entrée conserve le chemin d'installation (<code>menu_script</code>) afin que la restauration puisse déclencher le même flux d'installation."
+      },
+      {
+        "collector": "collect_guests.sh",
+        "produces": "vms_lxcs_at_backup",
+        "content": "Énumère les VM (<code>qm list</code>) et les LXC (<code>pct list</code>) présents au moment de la sauvegarde — VMID, nom, état actuel. Seul l'inventaire : les données des invités sont sous la responsabilité de <code>vzdump</code> / PBS."
+      }
+    ],
+    "schemaTitle": "Validation du schéma",
+    "schemaBody": "Le manifeste valide contre <code>scripts/backup_restore/schema/manifest.schema.json</code>. L'exécution du <code>build_manifest.sh --validate</code> déclenche une validation de schéma côté Python JSON (exige <code>python3</code> + <code>jsonschema</code>). Si le module n'est pas présent, la vérification est ignorée silencieusement — la validation est principalement une aide au développeur, et non une dépendance à l'exécution."
+  },
+  "applications": {
+    "heading": "L'inventaire des applications",
+    "intro": "Deux inventaires recensent les logiciels ajoutés aux paquets de base Proxmox VE : la liste des paquets dans <code>metadata/</code> et le registre des composants dans rootfs, détaillés ci-dessous. La restauration les utilise pour réinstaller les logiciels de l’utilisateur avec APT ou les installateurs ProxMenux selon leur mode d’installation initial.",
+    "packagesTitle": "packages.manual.list",
+    "packagesBody": "Une liste alphabétique en texte brut produite par <code>apt-mark showmanual</code>, avec les paquets APT <em>explicitement installés</em> sur l’hôte source. Les dépendances du système Proxmox VE de base sont exclues ; APT les réinstalle automatiquement sur la destination. Lors de la restauration, <code>_rs_run_complete_extras</code> lit la liste et applique un <em>filtre contre les suppressions en cascade</em> en trois passes : <code>dpkg -s</code> repère les paquets déjà installés, la détection des autres versions majeures vise les bibliothèques, et <code>apt-get install --simulate</code> vérifie le risque de suppression en cascade. Les paquets retenus sont installés avec <code>apt-get install -y</code>.",
+    "componentsTitle": "components_status.json (dans rootfs)",
+    "componentsBody": "Un registre JSON sous <code>/usr/local/share/proxmenux/</code> qui enregistre chaque composant ProxMenux a installé avec son état exact : version, drapeaux spécifiques ProxMenux (pour NVIDIA : <code>patched</code> booléen ; pour Coral : DKMS version). Ce fichier vit à l'intérieur des rootfs — pas dans <code>metadata/</code> — parce que c'est <em>lu après</em> la copie de rootfs vers la cible. Le répartiteur post-démarrage (<code>apply_cluster_postboot.sh</code>) itère ses entrées et exécute le crochet <code>--auto-reinstall</code> de chaque composant, qui lit l'état enregistré et reproduit l'installation contre le noyau courant de la cible.",
+    "componentInstallersTitle": "Installateurs de composants",
+    "componentInstallersBody": "Quatre installateurs ProxMenux exposent actuellement un point d'entrée <code>--auto-reinstall</code> :",
+    "installerRows": [
+      {
+        "component": "nvidia_driver",
+        "installer": "gpu_tpu/nvidia_installer.sh",
+        "action": "Lire <code>version</code> + <code>patched</code>. Télécharge exactement le même fichier d'exécution NVIDIA, construit des modules DKMS contre le noyau de la cible, réapplique le patch ProxMenux si la source l'avait."
+      },
+      {
+        "component": "coral_driver",
+        "installer": "gpu_tpu/install_coral.sh",
+        "action": "Lire la version du pilote Coral. Compile le module DKMS contre le noyau de la cible."
+      },
+      {
+        "component": "amdgpu_top",
+        "installer": "gpu_tpu/amd_gpu_tools.sh",
+        "action": "Lis la version enregistrée. Re-télécharge le <code>.deb</code> exact de la version GitHub."
+      },
+      {
+        "component": "intel_gpu_tools",
+        "installer": "gpu_tpu/intel_gpu_tools.sh",
+        "action": "APT-installe le paquet. Idépotent si déjà présent à partir de <code>packages.manual.list</code>."
+      }
+    ]
+  },
+  "restoreFlow": {
+    "heading": "Comment la restauration consomme les trois charges utiles",
+    "intro": "La restauration est un pipeline en six étapes. Chaque étape lit un sous-ensemble spécifique de l'archive et met à jour l'hôte cible. Aucune étape n'exige que l'hôte source soit accessible — l'archive est entièrement autonome.",
+    "stagesCaption": "L’étape 1 consulte le manifeste pour déterminer les modifications possibles. L’étape 2 copie les chemins rootfs applicables à chaud. L’étape 3 prépare les chemins à risque pour le prochain démarrage. L’étape 3b importe les pools ZFS de données ne contenant pas la racine et dont tous les disques sont présents. L’étape 4 installe les paquets. L’étape 5 réinstalle les composants après redémarrage pour le noyau de la destination.",
+    "stageRows": [
+      {
+        "stage": "1",
+        "name": "Vérification de compatibilité",
+        "reads": "manifest.json",
+        "action": "Exécute <code>hb_compat_check</code>. Comparer le matériel source par rapport au matériel cible (NIC, ID de stockage), la version PVE et la version principale du noyau. Ensembles <code>HB_COMPAT_KERNEL_DIRECTION</code> (<code>same</code>, <code>bk_newer</code> ou <code>bk_older</code>) et peuple <code>RS_SKIP_PATHS</code> avec des exclusions à la dérive matérielle et aux différences de noyau."
+      },
+      {
+        "stage": "2",
+        "name": "Appliquer à chaud",
+        "reads": "rootfs/ (chemins sûrs seulement)",
+        "action": "<code>_rs_apply … hot</code> copie les entrées de <code>hb_classify_path</code>=<code>hot</code> directement à la cible en direct. Tout ce qui est sous <code>/etc/pve</code>, <code>/etc/network</code> ou des chemins classés comme <em>reboot</em>/<em>dangerous</em> est reporté."
+      },
+      {
+        "stage": "3",
+        "name": "En attente de préparation",
+        "reads": "rootfs/ (redémarrage + chemins dangereux)",
+        "action": "<code>_rs_prepare_pending_restore</code> prépare les chemins à risque dans <code>/var/lib/proxmenux/pending-restore/</code>, écrit <code>plan.env</code>, <code>apply-on-boot.list</code> et <code>rs-skip-paths.txt</code>, puis active <code>proxmenux-restore-onboot.service</code> pour le prochain démarrage."
+      },
+      {
+        "stage": "3b",
+        "name": "Importation des pools de données",
+        "reads": "manifest.storage_inventory + état ZFS de la destination",
+        "action": "<code>_rs_import_data_pools</code> tente d’importer chaque pool ZFS ne contenant pas la racine et dont tous les disques sont présents sur la destination. Avec un hostid étranger, l’importation est retentée avec <code>zpool import -f</code>. Si un disque manque, le pool est ignoré avec un avertissement. Le résultat par pool est enregistré dans <code>/var/log/proxmenux/restore-datapools-&lt;timestamp&gt;.log</code>."
+      },
+      {
+        "stage": "4",
+        "name": "Installation du paquet",
+        "reads": "metadata/packages.manual.list",
+        "action": "<code>_rs_run_complete_extras</code> exécute le filtre sans risque de cascade et appelle <code>apt-get install -y</code> avec la liste des paquets survivants. La sortie complète va à <code>/var/log/proxmenux/restore-apt-*.log</code>."
+      },
+      {
+        "stage": "5",
+        "name": "Après le démarrage",
+        "reads": "rootfs (déjà appliqué) + components_status.json",
+        "action": "Après le redémarrage, <code>apply_pending_restore.sh</code> rejoue les chemins différés et <code>apply_cluster_postboot.sh</code> exécute <code>update-initramfs</code>, <code>update-grub</code> (ou <code>proxmox-boot-tool refresh</code>) et itère sur <code>components_status.json</code> en tirant le crochet <code>--auto-reinstall</code> de chaque composant."
+      }
+    ]
+  },
+  "whyItWorks": {
+    "heading": "Pourquoi séparer la sauvegarde en trois parties",
+    "body": "La séparation suit le <strong>cycle de vie</strong> des données. Le système de fichiers est transféré avec <code>rsync</code> : rapidement, de façon transparente et atomique par fichier. L’état de configuration à interpréter avant toute modification est du <strong>JSON structuré</strong>, lisible indépendamment, versionnable par schéma et comparable automatiquement à l’état de la destination. Les logiciels à réinstaller sont décrits dans un <strong>inventaire</strong> de noms et versions ; le gestionnaire de paquets et les installateurs ProxMenux choisissent les binaires adaptés. Chaque partie répond à son besoin. Leur combinaison vise une restauration cohérente tout en tolérant les échecs : un manifeste corrompu laisse rootfs récupérable, un paquet manquant n’empêche pas l’installation des composants et l’échec d’un installateur sur une entrée n’arrête pas la suivante."
+  }
+}

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

@@ -0,0 +1,93 @@
+{
+  "meta": {
+    "title": "ProxMenux Sauvegarde et restauration — Présentation | Sauvegarde et restauration complètes de l'hôte pour Proxmox VE",
+    "description": "La fonction de sauvegarde et de restauration de ProxMenux capture l'état complet d'un hôte Proxmox (système de fichiers, manifeste de configuration structuré et paquets/composants installés) et le reproduisent sur le même hôte ou sur un hôte différent. La sauvegarde et la restauration sont autonomes : aucune dépendance externe et les restaurations inter-noyaux sont prises en charge via un filtre de sous-ensemble sécurisé sensible à la direction et une hydratation indépendante du noyau.",
+    "ogTitle": "ProxMenux Sauvegarde et restauration – Présentation",
+    "ogDescription": "Sauvegarde et restauration complètes de l'hôte pour Proxmox VE avec manifeste structuré, liste de packages et réinstallateurs de composants.",
+    "twitterTitle": "ProxMenux Sauvegarde et restauration | ProxMenux",
+    "twitterDescription": "Sauvegarde et restauration complètes de l'hôte pour Proxmox VE avec manifeste structuré, liste de packages et réinstallateurs de composants."
+  },
+  "header": {
+    "title": "Sauvegarde et restauration",
+    "description": "Sauvegarde et restauration de l'hôte complet pour Proxmox VE. Capture le système de fichiers, la configuration et les composants installés dans une seule archive, et reproduit l'hôte sur la même installation Proxmox ou sur une autre installation Proxmox sans dépendances externes.",
+    "section": "Sauvegarde et restauration"
+  },
+  "intro": {
+    "title": "Qu'est-ce que c'est, en un seul paragraphe",
+    "body": "Une sauvegarde ProxMenux capture l’état complet d’un hôte Proxmox : <strong>le système de fichiers</strong>, avec les répertoires pertinents sous <code>/etc</code>, <code>/root</code> et <code>/var/lib/pve-cluster</code>, ainsi que les chemins personnalisés facultatifs ; <strong>un manifeste structuré</strong> en JSON décrivant le matériel détecté, les paramètres du noyau, la configuration réseau, l’état de ZFS, les utilisateurs et les entrées cron ; et <strong>un inventaire des applications</strong>, avec les paquets marqués comme installés manuellement par APT et les composants installés par ProxMenux, accompagnés de leurs versions exactes. Les trois destinations prises en charge — archive locale, Proxmox Backup Server (recommandé) et Borg — reçoivent le même contenu autonome. Chacune permet de reconstruire l’hôte cible sans que l’hôte source soit accessible pendant la restauration."
+  },
+  "video": {
+    "heading": "Présentation vidéo",
+    "intro": "Vous préférez regarder la sauvegarde et la restauration en action avant de la configurer ? Cette procédure pas à pas couvre une démonstration complète de bout en bout de la fonctionnalité dans ProxMenux.",
+    "title": "ProxMenux — Procédure pas à pas de sauvegarde et de restauration",
+    "caption": "Vidéo externe sur YouTube. Lecture en mode de confidentialité amélioré (pas de cookies jusqu'à ce que vous appuyiez sur play)."
+  },
+  "whatItIsNot": {
+    "heading": "Ce que ce n'est pas",
+    "intro": "Cette section couvre la sauvegarde et la restauration <strong>de l’hôte</strong> : l’installation Proxmox elle-même, et non les applications ou systèmes invités qui y fonctionnent.",
+    "items": [
+      "<strong>Ce n’est pas un outil de sauvegarde des VM/CT.</strong> Cette fonction ne capture ni les disques ni l’état de la RAM des invités ; c’est le rôle de <code>vzdump</code>. Les <strong>fichiers de configuration</strong> des invités (<code>/etc/pve/nodes/&lt;node&gt;/qemu-server/*.conf</code> et <code>lxc/*.conf</code>) sont <strong>bien</strong> sauvegardés. Après restauration, l’inventaire réapparaît et les disques peuvent être restaurés ou rattachés à partir d’une sauvegarde existante sur PBS ou en local.",
+      "<strong>Ce n’est pas une opération à l’échelle du cluster.</strong> Chaque nœud se sauvegarde lui-même. L’appartenance au cluster est enregistrée dans <code>/etc/pve</code> afin de pouvoir réintégrer un nœud restauré, mais la restauration de tout le cluster nécessite de coordonner les différents nœuds.",
+      "<strong>Ce n’est pas une image complète du disque.</strong> Les binaires du noyau, l’initramfs et la partition de démarrage ne sont pas sauvegardés. Lors de la restauration, ProxMenux utilise les fichiers de démarrage de l’hôte cible, régénérés automatiquement par <code>update-initramfs</code> et l’outil du chargeur d’amorçage, puis installe les pilotes adaptés au noyau en cours d’exécution sur la cible."
+    ]
+  },
+  "threePillars": {
+    "heading": "Les trois piliers d'une sauvegarde",
+    "intro": "Une archive ProxMenux est structurée autour de trois charges utiles autonomes. La restauration utilise les trois ensemble pour reproduire l'hôte source sur une cible sur laquelle le même noyau n'est peut-être même pas installé.",
+    "diagramCaption": "Chaque sauvegarde expédie les trois mêmes charges utiles, quelle que soit la destination. La restauration consomme les trois : rootfs pour déposer les fichiers, le manifeste pour détecter les dérives et les différences entre les noyaux, et l'inventaire des applications pour réinstaller les packages et les composants sur le propre noyau de la cible.",
+    "pillar1Label": "Système de fichiers",
+    "pillar1Detail": "rootfs/\n(rsync de /etc,\n/etc/systemd/network,\n/root, plus un\ninstantané sqlite3\nde /var/lib/pve-cluster,\n+ chemins facultatifs)",
+    "pillar2Label": "Manifeste",
+    "pillar2Detail": "manifest.json\n(matériel, paramètres\ndu noyau, réseau,\nZFS, utilisateurs, cron,\npools ZFS, stockage)",
+    "pillar3Label": "Applications",
+    "pillar3Detail": "packages.manual.list\n+ components_status.json\n(paquets APT manuels + installateurs\nProxMenux avec versions)"
+  },
+  "restoreIsUniversal": {
+    "heading": "La restauration reproduit l'hôte source, pas l'archive",
+    "body": "La restauration d'une sauvegarde ProxMenux ne se contente pas d'extraire le système de fichiers. Le flux de restauration lit le manifeste pour détecter la dérive entre la source et la cible (différences matérielles, renommages des cartes réseau, version du noyau, identité du pool ZFS), restaure le système de fichiers, puis déclenche le programme d'installation de composant correct pour chaque service installé sur la source (pilote NVIDIA, Coral TPU, outils GPU AMD, outils Intel GPU). Chaque programme d'installation s'exécute sur le <strong>noyau actuel de la cible</strong>, de sorte que l'hôte restauré ne dépend pas de la présence du noyau de la source. Lorsque le noyau de la cible est plus récent que celui de la sauvegarde, une passe d'<strong>hydratation</strong> indépendante du noyau fusionne les propres réglages de l'utilisateur (jetons IOMMU, ID de périphérique VFIO, adaptations particulières, clés GRUB) dans la nouvelle configuration de démarrage de la cible sans copier textuellement les fichiers liés au noyau."
+  },
+  "twoInterfaces": {
+    "heading": "Deux interfaces, un backend",
+    "intro": "Chaque étape du workflow de sauvegarde et de restauration est disponible à partir de deux points d'entrée. Les deux appellent la même bibliothèque shell, produisent des archives identiques et lisent le même registre de tâches.",
+    "cliLabel": "ProxMenux Scripts (TUI)",
+    "cliDetail": "menu → Utilitaires →\nSauvegarde / Restauration de l'hôte\n\nFlux basé sur le dialogue,\nCompatible avec SSH, scriptable\npour une utilisation sans surveillance.",
+    "webLabel": "ProxMenux Monitor (Web UI)",
+    "webDetail": "Onglet Sauvegardes dans\nl’interface web de Monitor.\n\nRestauration en un clic, suivi\ndes journaux en direct, intégré\naux notifications et à la vue\ndes différences de retour arrière."
+  },
+  "whereNext": {
+    "heading": "Où aller à partir d'ici",
+    "intro": "Chaque sous-section ci-dessous couvre en profondeur un aspect du flux de travail. Commencez par <em>Comment ça marche</em> si l'objectif est de comprendre ce que contient l'archive et pourquoi. Accédez à <em>Destinations</em> pour configurer la cible de la copie. Lisez <em>Restauration</em> et <em>Restauration inter-noyaux</em> pour le côté récupération.",
+    "items": [
+      {
+        "label": "Comment ça marche",
+        "href": "/docs/backup-restore/how-it-works",
+        "tail": "— les trois charges utiles (rootfs, manifeste, applications) en détail, avec les collecteurs qui les produisent et le format de chaque fichier."
+      },
+      {
+        "label": "Destinations",
+        "href": "/docs/backup-restore/destinations",
+        "tail": "— comparaison de local, Proxmox Backup Server (recommandé) et Borg, et comment configurer chacun d'eux."
+      },
+      {
+        "label": "Création de sauvegardes",
+        "href": "/docs/backup-restore/creating-backups",
+        "tail": "— sauvegardes ponctuelles, profil de chemin par défaut, ajout de chemins personnalisés, chiffrement pour PBS."
+      },
+      {
+        "label": "Tâches planifiées",
+        "href": "/docs/backup-restore/scheduled-jobs",
+        "tail": "— nouvelles tâches ou attachement à une tâche vzdump PVE existante, formats de planification, modal de détail de la tâche."
+      },
+      {
+        "label": "Restauration",
+        "href": "/docs/backup-restore/restoring",
+        "tail": "— les trois actions sur une archive (afficher, télécharger, restaurer), la restauration complète ou personnalisée, le répartiteur post-démarrage et pourquoi les dix dernières minutes sont importantes."
+      },
+      {
+        "label": "Restauration inter-noyaux",
+        "href": "/docs/backup-restore/cross-kernel",
+        "tail": " — comportement tenant compte du sens du changement de version lorsque le noyau cible diffère de celui de la sauvegarde, filtre de sous-ensemble sûr et quatre phases d’hydratation."
+      }
+    ]
+  }
+}

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

@@ -0,0 +1,152 @@
+{
+  "meta": {
+    "title": "Tâches planifiées — temporisateurs, mode attach et rétention | ProxMenux",
+    "description": "Tâches de sauvegarde d’hôte ProxMenux programmées. Deux modes de création (minuteur systemd propre ou association à une tâche vzdump PVE existante), règles de rétention appliquées par tâche avec proxmox-backup-client, Borg ou le nettoyage local, fichiers sous /var/lib/proxmenux/backup-jobs et script d’exécution produisant les mêmes archives que le processus interactif.",
+    "ogTitle": "Sauvegarde ProxMenux — tâches programmées",
+    "ogDescription": "Sauvegardes d'hôte programmées non surveillées avec mode de fixation, conservation, et les mêmes trois destinations que le flux interactif.",
+    "twitterTitle": "Tâches planifiées | ProxMenux",
+    "twitterDescription": "Tâches programmées de sauvegarde d’hôte sans intervention, avec mode d’association et rétention."
+  },
+  "header": {
+    "title": "Tâches programmées",
+    "description": "Tâches de sauvegarde d’hôte sans intervention. Deux modèles de création : une nouvelle tâche indépendante avec son propre calendrier, ou une tâche associée à une tâche vzdump PVE existante, dont elle reprend le calendrier et la rétention. Les deux produisent les mêmes archives que le processus interactif.",
+    "section": "Sauvegarde et restauration"
+  },
+  "intro": {
+    "title": "Les deux modèles de tâches programmées",
+    "body": "Une tâche programmée peut être créé selon l'un des deux modèles suivants :",
+    "modelsList": [
+      "<strong>Nouveau travail indépendant</strong> — ProxMenux définit lui-même l'horaire de travail avec sa propre minuterie systemd, indépendamment de toute autre tâche sur l'hôte. Compatible avec les trois destinations : Local, PBS et Borg.",
+      "<strong>Associer à une tâche vzdump PVE existante</strong> — la tâche n’a pas de calendrier propre ; elle s’exécute automatiquement quand la tâche vzdump parente sauvegarde les VM et LXC de cet hôte. Elle reprend son calendrier et sa rétention. Compatible avec les destinations locale et PBS (Borg n’est pas pris en charge, car PVE n’a pas de planificateur natif pour Borg)."
+    ]
+  },
+  "attachBadge": {
+    "title": "Mode d’association — recommandé si une tâche vzdump PVE existe déjà",
+    "body": "Lorsqu’une tâche de sauvegarde vzdump PVE est déjà configurée pour les VM et LXC du nœud, l’association de la sauvegarde hôte la fait exécuter après celle des invités, dans le <strong>même cycle de sauvegarde</strong>. À la restauration, les configurations des invités viennent de la sauvegarde hôte (sous <code>/etc/pve</code>) et leurs disques des sauvegardes vzdump du même cycle. Cela facilite la récupération coordonnée du nœud, sans constituer un instantané atomique : des modifications pendant le cycle peuvent créer des écarts entre la configuration hôte et l’état des disques des invités."
+  },
+  "frequencyBadge": {
+    "title": "Fréquence recommandée",
+    "body": "Pour maximiser la compatibilité entre une sauvegarde hôte et sa future restauration, sauvegardez fréquemment l’hôte. Plus la copie est proche de son état actuel, moins la restauration doit réconcilier d’écarts de configuration, de paquets et de composants."
+  },
+  "modes": {
+    "heading": "Les deux modes",
+    "rows": [
+      {
+        "mode": "Nouveau travail planifié",
+        "backends": "Local, PBS, Borg",
+        "schedule": "Propre expression <code>OnCalendar</code> (syntaxe du calendrier systemd — par exemple <code>daily</code>, <code>Mon..Fri 03:00</code>).",
+        "retention": "Demandée séparément: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Appliquée par le script d’exécution après chaque sauvegarde réussie."
+      },
+      {
+        "mode": "Associer à une tâche vzdump PVE",
+        "backends": "Local, PBS (Borg n'a pas de planificateur côté PVE)",
+        "schedule": "Hérité de la tâche PVE parente. Aucun minuteur systemd n’est installé côté ProxMenux.",
+        "retention": "Héritée de la configuration <code>prune-backups</code> de la tâche parente (associée une à une aux variables <code>KEEP_*</code> du script d’exécution via <code>hb_pve_prune_to_keep_env</code>)."
+      }
+    ]
+  },
+  "attachDetail": {
+    "heading": "Comment fonctionne le mode de fixation",
+    "intro": "PVE écrit les tâches <code>vzdump</code> dans <code>/etc/pve/jobs.cfg</code>, avec une section par tâche indiquant le stockage des sauvegardes VM et LXC. Le mode d’association exige un backend compris par ProxMenux (local ou PBS). La sauvegarde hôte s’exécute via le hook job-end après la fin de la tâche de sauvegarde des invités.",
+    "steps": [
+      {
+        "step": "1",
+        "detail": "Lors de la création de tâches, ProxMenux liste les tâches parent PVE compatibles via <code>hb_pve_list_vzdump_jobs_for_backend</code>. L'utilisateur en choisit un."
+      },
+      {
+        "step": "2",
+        "detail": "Le <code>.env</code> de l'emploi est écrit avec <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> et les valeurs de <code>KEEP_*</code> héritées; aucun minuteur systemd n'est créé."
+      },
+      {
+        "step": "3",
+        "detail": "<code>hb_install_vzdump_hook</code> enregistre un hook dans <code>/etc/vzdump.conf</code>. À la phase job-end de toute tâche vzdump, il compare le <code>$STOREID</code> reçu au <code>PVE_STORAGE</code> de chaque tâche associée activée et appelle le script d’exécution en cas de correspondance. L’association se fait par stockage, et non par identifiant de la tâche parente choisie."
+      },
+      {
+        "step": "4",
+        "detail": "L’archive est enregistrée dans le même stockage que les sauvegardes vzdump : <code>path/dump/</code> pour la destination locale ou le dépôt PBS configuré dans l’entrée de stockage PVE."
+      }
+    ],
+    "outroBody": "Le mode d’association n’a pas de minuteur propre. Désactiver ou supprimer la tâche PVE parente choisie arrête son déclenchement, mais une autre tâche vzdump utilisant le même stockage peut encore lancer la sauvegarde hôte. Désactivez ou supprimez la tâche ProxMenux elle-même pour l’empêcher. Lors d’une désactivation, son entrée reste sur disque pour permettre une réactivation ou une nouvelle association."
+  },
+  "storageLayout": {
+    "heading": "Fichiers qui constituent un travail",
+    "intro": "Chaque travail programmé est entièrement décrit par trois ou quatre fichiers sur disque. Les lire donne la configuration complète du travail sans compter sur l'interface.",
+    "rows": [
+      {
+        "path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env",
+        "content": "Backend, identifiant de sauvegarde ou destination, calendrier (nouvelle tâche) ou tâche PVE parente (association), indicateur d’activation, valeurs de rétention <code>KEEP_*</code> et références aux identifiants."
+      },
+      {
+        "path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths",
+        "content": "Un chemin absolu par ligne : la sélection figée à partir du profil lors de la création de la tâche. Modifier le fichier utilise la nouvelle sélection à la prochaine exécution du minuteur."
+      },
+      {
+        "path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service",
+        "content": "Nouveau mode seulement. Le service invoque <code>run_scheduled_backup.sh JOB_ID</code>. Le minuteur le planifie avec <code>Persistent=true</code> (exécutions manquées rattrapées au prochain démarrage) et un petit <code>RandomizedDelaySec=120</code> pour répartir la charge lorsque plusieurs tâches partagent la même expression OnCalendar."
+      },
+      {
+        "path": "/etc/vzdump.conf script-hook",
+        "content": "Mode d’association uniquement. Installé une fois par <code>hb_install_vzdump_hook</code> ; compare le <code>PVE_STORAGE</code> de chaque tâche associée au <code>$STOREID</code> transmis par PVE au hook."
+      }
+    ]
+  },
+  "runner": {
+    "heading": "Ce que fait une tâche à son déclenchement",
+    "intro": "Chaque travail — qu’il s’agisse d’une nouvelle tâche indépendante ou d’une tâche associée — comporte la même séquence en trois étapes:",
+    "steps": [
+      "<strong>Prépare la sauvegarde.</strong> Lit la configuration de travail (destination, profil, chemins) et assemble l'arborescence des archives exactement comme le flux interactif. Le résultat est la même archive qu'une sauvegarde manuelle avec ces paramètres produirait.",
+      "<strong>Écrire à la destination.</strong> Charge ou écrit l'archive vers la destination configurée — un fichier local <code>.tar.zst</code>, une sauvegarde PBS ou une archive Borg — en utilisant exactement les mêmes outils et identifiants qu’une sauvegarde manuelle vers la même destination.",
+      "<strong>Appliquer la rétention.</strong> Supprime les anciennes sauvegardes de la destination, en maintenant les nombres <code>keep-last</code> / <code>keep-daily</code> / <code>keep-weekly</code> configurés sur le travail. La purge est effectuée par la destination elle-même: PBS applique sa propre conservation, Borg exécute <code>borg prune</code>, et pour Local ProxMenux supprime les fichiers qui tombent en dehors de la fenêtre <code>keep-last</code>."
+    ]
+  },
+  "management": {
+    "heading": "Gestion des tâches",
+    "intro": "Le menu planificateur (Scripts TUI) et l'onglet Sauvegardes Monitor exposent les mêmes actions sur n'importe quel travail.",
+    "rows": [
+      {
+        "action": "Exécuter maintenant",
+        "detail": "Appelle immédiatement le script d’exécution, sans attendre le minuteur ou le hook vzdump. Utile pour vérifier la configuration sans attendre le prochain déclenchement."
+      },
+      {
+        "action": "Activer / Désactiver",
+        "detail": "Nouveau mode : <code>systemctl enable/disable --now</code> la minuterie. Attache le mode : retourne le drapeau <code>ENABLED</code> dans le travail env — le script hook l'honore au prochain déclenchement PVE."
+      },
+      {
+        "action": "Modifier",
+        "detail": "Rouvre les champs de destination, calendrier, profil et rétention et réécrit les fichiers de la tâche. Conserve son identifiant."
+      },
+      {
+        "action": "Supprimer",
+        "detail": "Supprime le fichier env, la liste des chemins et le minuteur et service systemd (nouvelle tâche), et désactive l’association au hook (mode d’association). Les archives déjà présentes à destination restent intactes."
+      },
+      {
+        "action": "Voir le journal",
+        "detail": "Affiche en continu <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code> : un fichier journal par exécution. Le programme d'exécution émet également une ligne d'état compacte à journald sous le service systemd."
+      }
+    ]
+  },
+  "notifications": {
+    "heading": "Notifications",
+    "body": "Chaque exécution programmée déclenche les mêmes événements <code>hb_notify_lifecycle</code> que le flux interactif (<code>start</code>, <code>complete</code>, <code>fail</code>). Si les canaux de notification sont configurés dans le moniteur, les tâches non surveillées présentent leurs résultats de la même manière que les sauvegardes manuelles, un utilisateur n'a pas besoin de vérifier le journal pour savoir si une tâche a réussi."
+  },
+  "whereNext": {
+    "heading": "Où aller ensuite?",
+    "items": [
+      {
+        "label": "Création de sauvegardes",
+        "href": "/docs/backup-restore/creating-backups",
+        "tail": "— le flux interactif qui partage le moteur avec le planificateur."
+      },
+      {
+        "label": "Destinations",
+        "href": "/docs/backup-restore/destinations",
+        "tail": "— configuration par moteur utilisée à la fois par le flux interactif et le planificateur."
+      },
+      {
+        "label": "Restauration",
+        "href": "/docs/backup-restore/restoring",
+        "tail": " — le processus qui utilise les sauvegardes produites par les tâches."
+      }
+    ]
+  }
+}