"title":"Restaurer une sauvegarde — flux complets et personnalisés ProxMenux",
"description":"Le processus complet de restauration : consulter, télécharger ou restaurer une sauvegarde, vérifier la compatibilité, choisir le mode complet ou personnalisé, classer les chemins appliqués à chaud ou après redémarrage, puis réinstaller les composants après le démarrage.",
"ogTitle":"Sauvegarde ProxMenux — restauration",
"ogDescription":"Restauration complète ou personnalisée avec contrôle de compatibilité, classification des chemins, traitement au démarrage et réinstallation après démarrage.",
"twitterTitle":"Restaurer une sauvegarde ProxMenux",
"twitterDescription":"Comment une sauvegarde d'hôte ProxMenux est transformée en un hôte Proxmox fonctionnant."
},
"header":{
"title":"Restaurer une sauvegarde",
"description":"Le workflow complet de restauration : de la sélection d'une archive à un hôte de travail. Documente la vérification de compatibilité, les deux modes de restauration, le répartiteur sur le démarrage, le passe de réinstallation post-démarrage, et les mécanismes qui rendent prévisible la restauration cross-host et cross-kernel.",
"section":"Sauvegarde et restauration"
},
"intro":{
"title":"La restauration reproduit la source, pas seulement les fichiers",
"body":"Restaurer une sauvegarde ProxMenux va au-delà de l’extraction des fichiers. Avant les modifications, la restauration consulte le manifeste pour détecter les différences, écarte les chemins pouvant compromettre le démarrage et adapte les réglages de l’utilisateur qui ne peuvent pas être copiés tels quels. Après le redémarrage nécessaire, elle tente de réinstaller les composants pris en charge enregistrés (pilote NVIDIA, Coral TPU, outils GPU) pour le noyau actif de la destination. Une seule archive pilote le contrôle de compatibilité, la classification des chemins et les traitements au démarrage puis après démarrage. Consultez les résultats par composant et les journaux pour vérifier le résultat."
},
"threeActions":{
"heading":"Trois actions sur une sauvegarde",
"intro":"La sélection d'une sauvegarde dans la liste ouvre un menu avec trois actions.",
"actionRows":[
{
"action":"Affichage",
"detail":"Ouvre une vue en lecture seule de l'archive : le contenu de manifest.json (nom d'hôte source, version PVE, noyau, matériel, composants installés), la liste des chemins à l'intérieur de <code>rootfs/</code>, et un diff de ce qui changerait sur l'hôte actuel si la sauvegarde était appliquée."
},
{
"action":"Télécharger",
"detail":"Exporte l'archive comme un fichier portable <code>.tar.zst</code> (tar compressé avec zstd). Il peut être extrait sur n'importe quel système Linux avec <code>tar --zstd -xf FILE.tar.zst</code>, ou sur macOS/Windows avec n'importe quel outil qui supporte zstd (7-Zip, PeaZip, Keka...). L'arbre extrait contient <code>manifest.json</code>, <code>metadata/</code> et <code>rootfs/</code> — exactement la même disposition que la restauration consomme. Utile pour une inspection hors ligne ou pour la restauration sur un hôte sans accès à la destination originale (PBS, Borg)."
},
{
"action":"Restaurer",
"detail":"Le chemin de l'écriture. Extrait l'archive dans un répertoire de mise en scène, effectue la vérification de compatibilité et présente le mode de sélection (complète ou personnalisée)."
}
]
},
"compatibilityCheck":{
"heading":"Le contrôle de compatibilité",
"intro":"Avant d'écrire un fichier, <code>hb_compat_check</code> compare l'état décrit dans le manifeste avec l'hôte cible. La vérification fonctionne en lecture seule et produit quatre sorties indépendantes qui conduisent le reste de la restauration.",
"outputRows":[
{
"output":"Drapeau de direction",
"detail":"<code>HB_COMPAT_KERNEL_DIRECTION</code> vaut <code>same</code>, <code>bk_newer</code> ou <code>bk_older</code> selon la comparaison des versions majeures du noyau de la sauvegarde et de la destination. Il pilote le filtre de chemins compatibles entre noyaux, actif uniquement pour <code>bk_older</code>, et l’adaptation des réglages décrite sur la page correspondante."
},
{
"output":"Liste des chemins exclus",
"detail":"<code>RS_SKIP_PATHS</code> — chaque chemin de restauration ne doit PAS s'appliquer. Populé par deux mécanismes : la dérive matérielle (manque de NIC, défaut d'identification de stockage, pool étranger ZFS) et — lorsque la direction est <code>bk_older</code> — la liste des sentiers dangereux à travers le noyau."
},
{
"output":"Plan de réaffectation des interfaces réseau",
"detail":"Lorsqu'un NIC sur la cible a le même MAC que celui sur la source mais un nom différent (typique après un swap de carte mère), la vérification de compatibilité enregistre un plan de renommer (<code>HB_NIC_REMAP</code>) qui réécrirea <code>/etc/network/interfaces</code> pendant la restauration."
},
{
"output":"Plan de restauration",
"detail":"Calculé par <code>compute_rollback_plan.sh</code>. Liste les VM, LXC et composants présents sur la destination mais absents de la sauvegarde. Le dialogue propose de supprimer les invités supplémentaires avant redémarrage. La suppression des composants reste manuelle et celle des invités peut échouer ; une correspondance exacte n’est donc pas garantie."
}
],
"reportBody":"Le contrôle émet également un rapport structuré (<code>HB_COMPAT_RESULTS</code>) classé PASS / INFO / WARN / FAIL. Les entrées WARN et FAIL sont présentes dans le panneau pré-restauration ; la restauration refuse de procéder seulement lorsqu'une FAIL est présente et que l'utilisateur ne peut pas résoudre en cliquant sur Continuer."
},
"twoModes":{
"heading":"Restauration complète vs restauration personnalisée",
"intro":"Après le contrôle de compatibilité, le menu de mode apparaît. Le choix détermine <em>ce qui</em> est appliqué, pas <em>comment</em> : les deux modes utilisent le même processus.",
"modeRows":[
{
"mode":"Restauration complète",
"detail":"Applique tous les chemins de l'archive qui survivent à la dérive et aux filtres de cross-kernel. Exécute également l'installation du paquet et le passe de réinstallation automatique du composant. C'est le choix par défaut et le choix recommandé — le but est de reproduire la source, pas de choisir des morceaux."
},
{
"mode":"Restauration personnalisée",
"detail":"Ouvre une liste de contrôle montrant chaque chemin que porte l'archive. L'utilisateur coche un sous-ensemble. Les chemins bloqués par le filtre croisé apparaissent grisés et ne peuvent être sélectionnés. L'installation du paquet et l'auto-réinstallation du composant sont ignorées par défaut en mode Custom — l'utilisateur indique qu'il veut une application partielle, pas une reproduction complète."
}
]
},
"pathClassification":{
"heading":"Comment les chemins sont classés",
"intro":"Chaque chemin sélectionné pour la restauration est classé par <code>hb_classify_path</code> dans l'une des trois catégories. La catégorie détermine quand le chemin est appliqué au système et pourquoi.",
"rows":[
{
"class":"hot",
"detail":"Voies appliquées <strong>immédiatement</strong> au système d'exécution. Le service qui les consomme ramasse le changement seul ou au prochain rechargement — aucun redémarrage n'est nécessaire. Ce sont l'essentiel d'une sauvegarde: <code>/etc/ssh</code>, <code>/etc/apt</code>, <code>/etc/cron.*</code>, <code>/root</code>, <code>/usr/local/bin</code>, fichiers de configuration de service général, etc."
"detail":"Chemins reportés au <strong>prochain démarrage</strong>, au lieu d’être appliqués <strong>immédiatement</strong> par ce processus. Ils concernent la configuration de démarrage : la génération du chargeur lit <code>/etc/default/grub</code>, les montages utilisent <code>/etc/fstab</code> et le chargement des modules utilise <code>/etc/modules</code>. Les fichiers en attente sont appliqués après redémarrage, puis les éléments de démarrage nécessaires sont régénérés. Exemples : <code>/etc/default/grub</code>, <code>/etc/kernel</code>, <code>/etc/modules</code>, <code>/etc/fstab</code>, <code>/etc/zfs</code>, <code>/etc/modprobe.d</code>."
"detail":"Chemins <strong>NON appliqués sur le système en cours d’exécution</strong> : une écriture à chaud pourrait corrompre l’état ou couper la connexion active. Ils sont placés dans l’ensemble en attente : <code>/etc/network</code> est écrit tôt au démarrage suivant, avant le démarrage du réseau, et <code>/etc/pve</code> est écrit par le répartiteur post-démarrage une fois le système de fichiers du cluster disponible. Exemples : <code>/etc/pve</code> (pmxcfs est un montage FUSE contenant la configuration active du cluster), <code>/var/lib/pve-cluster</code> (données actives du cluster, conservées dans le répertoire de récupération pour une récupération manuelle uniquement), <code>/etc/network</code> (pourrait reconfigurer l’interface même par laquelle l’utilisateur est connecté en SSH et couper la session)."
"intro":"Le pipeline complet de la sélection des archives à un hôte opérationnel restauré. Chaque étape alimente la suivante; l'état écrit par les étapes précédentes est consommé par les suivantes.",
