Restauration PRA automatisée

Restauration PRA automatisée

Cette page documente le flux validé pour restaurer un système depuis un disque de backup vers une VM vierge ou une machine physique. Le flux de référence inclut une chaîne renforcée: LUKS, TPM, FIDO2, UKI, Secure Boot et systemd-boot.

La vue d'ensemble de cette chaîne est rattachée à la page Boot Trust du portfolio.

État validé

• Snapshot PRA de référence: <SNAPSHOT_ID>.
• Repo Restic: <DEPOT_RESTIC>.
• Scripts exportés sur le disque backup: <OUTILS_PRA>.
• Point de montage live recommandé: <MONTAGE_BACKUP_LIVE>.
• Restauration et réparations post-restore validées sur VM vierge <VM_TEST_PRA>.
• Rapport pré-boot, comparaison UUID, génération UKI, clé de récupération et invite de redémarrage validés.
• Temps total observé sur cette VM: 11 min 13 s, restauration de 56,702 GiB comprise.
• Boot réel validé avec racine LUKS, vTPM, UKI LTS et systemd-boot après ajout du vTPM à la VM restaurée.
• Profil appliqué pendant la restauration: LUKS + UKI + clé de récupération. TPM, FIDO2 et enrôlement Secure Boot n'étaient pas demandés pendant cette phase.

Preuve du dry-run préalable

Avant le mode applicatif, le plan complet a été affiché et relu sans partitionnement ni restauration. Ces deux captures ouvrent la chronologie des preuves.

Validation pré-boot

Le test public retient uniquement les propriétés non sensibles suivantes:

1. Les outils sont relocalisés dans l'environnement live pour libérer le support backup.
2. La résolution DNS est testée avec un délai maximal.
3. Le resolver est corrigé seulement si le test DNS échoue.
4. Le keyring Arch est actualisé avant l'installation de Restic.
5. Les signatures des paquets restent obligatoires.
6. Restic est installé automatiquement et l'existence du snapshot demandé est vérifiée avant toute restauration.
7. Les tailles de l'ESP et du swap sont calculées automatiquement selon la capacité du disque.
8. Le disque cible reçoit automatiquement une table GPT et une ESP FAT32 marquée bootable.
9. La partition racine est chiffrée automatiquement en LUKS2, ouverte dans un mapper puis formatée en ext4.
10. La racine chiffrée et l'ESP sont montées aux emplacements attendus avant restauration.
11. 56,702 GiB sont restaurés par Restic en 7 min 51 s.
12. Les contrôles et réparations post-restore sont appliqués, notamment sur les fichiers sensibles, les services et les scripts Restic.
13. Les points de montage chroot sont préparés avant l'installation cible de paquets.
14. Les liens FHS /bin, /lib et /lib64 sont recréés si nécessaire.
15. systemd-ukify est installé dans la cible lorsque le profil UKI le demande.
16. fstab, les entrées systemd-boot et la ligne de commande UKI sont réalignés sur les UUID de la nouvelle cible.
17. systemd-boot est installé, l'entrée UKI devient l'entrée par défaut et le random seed est protégé.
18. mkinitcpio régénère les initramfs et l'UKI; les hooks de signature présents sont exécutés.
19. Le swapfile de 8 GiB est créé à l'intérieur de la racine LUKS et ajouté à fstab.
20. Une clé de récupération LUKS est créée et doit être archivée hors ligne.
21. Le support backup et la cible sont démontés proprement après les contrôles.
22. Le rapport DIFF bloque le redémarrage en cas d'incohérence; sinon le reboot reste soumis à une seconde confirmation humaine.

Preuves pré-boot commentées

Les UUID affichés appartiennent exclusivement à cette VM jetable. Snapshot, secret Restic, phrases de passe et clé de récupération sont masqués.

Validation post-boot de la VM restaurée

Après enrôlement du vTPM et régénération de l'UKI, la VM démarre sur le système restauré. Les contrôles suivants relient le disque reconstruit, le chiffrement et l'artefact de boot réellement utilisé.

Preuve Boot Trust distincte sur l'hôte

Ces captures ne sont pas présentées comme le post-boot de la VM restaurée. Elles démontrent séparément que la chaîne renforcée utilisée comme référence fonctionne sur l'hôte Morpheus.

Préparation

Dans l'ISO live Arch:

lsblk -f

Identifier:

• le disque cible à effacer, par exemple <DISQUE_VM> en VM ou <DISQUE_PHYSIQUE> sur machine physique;
• la partition backup, par exemple <PARTITION_BACKUP>;
• le snapshot à restaurer avec restic snapshots; ne jamais reprendre aveuglément un identifiant historique.

Monter le backup:

mkdir -p <MONTAGE_BACKUP_LIVE>

mount <PARTITION_BACKUP> <MONTAGE_BACKUP_LIVE>

Vérifier les outils:

grep -n "Rapport final pre-reboot\|Voulez-vous redemarrer" \
  <MONTAGE_BACKUP_LIVE>/<OUTILS_PRA>/finalize-restore-target.sh \
  <MONTAGE_BACKUP_LIVE>/<OUTILS_PRA>/run-pra-restore-luks-uki-tpm.sh

Vérifier et choisir le snapshot:

restic -r <MONTAGE_BACKUP_LIVE>/<DEPOT_RESTIC> snapshots --compact

Dry-run obligatoire

Toujours lancer la commande sans --apply avant une restauration réelle:

<MONTAGE_BACKUP_LIVE>/<OUTILS_PRA>/run-pra-restore-luks-uki-tpm.sh \
  --disk <DISQUE_CIBLE> \
  --backup-dev <PARTITION_BACKUP> \
  --snapshot <SNAPSHOT_ID> \
  --target-root <RACINE_CIBLE> \
  --backup-mount <MONTAGE_BACKUP_LIVE> \
  --restic-repo-path <DEPOT_RESTIC> \
  --password-prompt \
  --install-restic \
  --luks \
  --uki \
  --tpm \
  --tpm-pcrs <PCRS_TPM> \
  --recovery-key \
  --fido2-pair \
  --secure-boot

Commande VM de test

Cette variante valide la restauration LUKS + UKI sans supposer que la VM dispose déjà d'un vTPM, d'un passthrough FIDO2 et des clés Secure Boot adaptées:

<MONTAGE_BACKUP_LIVE>/<OUTILS_PRA>/run-pra-restore-luks-uki-tpm.sh \
  --disk <DISQUE_VM> \
  --backup-dev <PARTITION_BACKUP> \
  --snapshot <SNAPSHOT_ID> \
  --target-root <RACINE_CIBLE> \
  --backup-mount <MONTAGE_BACKUP_LIVE> \
  --restic-repo-path <DEPOT_RESTIC> \
  --password-prompt \
  --install-restic \
  --luks \
  --uki \
  --recovery-key \
  <MODE_APPLICATIF_PRIVÉ>

Ajouter --tpm, --fido2-pair ou --secure-boot uniquement après avoir configuré et vérifié les périphériques et clés correspondants dans la VM.

Commande machine physique renforcée

Exemple anonymisé pour restaurer une machine physique avec les clés Secure Boot déjà enrôlées:

<MONTAGE_BACKUP_LIVE>/<OUTILS_PRA>/run-pra-restore-luks-uki-tpm.sh \
  --disk <DISQUE_PHYSIQUE> \
  --backup-dev <PARTITION_BACKUP> \
  --snapshot <SNAPSHOT_ID> \
  --target-root <RACINE_CIBLE> \
  --backup-mount <MONTAGE_BACKUP_LIVE> \
  --restic-repo-path <DEPOT_RESTIC> \
  --password-prompt \
  --install-restic \
  --luks \
  --uki \
  --tpm \
  --tpm-pcrs <PCRS_TPM> \
  --recovery-key \
  --fido2-pair \
  --secure-boot \
  <MODE_APPLICATIF_PRIVÉ>

Flux legacy

L'ancien flux simple reste documenté pour les restaurations sans chaîne renforcée:

<MONTAGE_BACKUP_LEGACY>/<OUTILS_PRA>/run-pra-restore.sh \
  --disk <DISQUE_CIBLE> \
  --backup-dev <PARTITION_BACKUP> \
  --snapshot <SNAPSHOT_ID> \
  --target-root <RACINE_CIBLE> \
  --backup-mount <MONTAGE_BACKUP_LEGACY> \
  --restic-repo-path <DEPOT_RESTIC> \
  --password-prompt \
  --install-restic \
  <MODE_APPLICATIF_PRIVÉ>

Ce que le script fait

1. Demande confirmation avant repartitionnement.
2. Relocalise les outils dans l'environnement live.
3. Vérifie le DNS avec un délai maximal et corrige le résolveur si nécessaire.
4. Actualise le trousseau de clés Arch et installe Restic si demandé.
5. Prépare le disque cible: ESP, root, swap optionnel.
6. Monte la racine sur <RACINE_CIBLE> et l'ESP sur <RACINE_CIBLE>/boot.
7. Restaure le snapshot Restic vers <RACINE_CIBLE>.
8. Démonte le disque backup pour éviter un blocage.
9. Corrige les liens FHS /bin, /lib, /lib64.
10. Synchronise les UUID root, boot et swap.
11. Reconstruit les initramfs avec mkinitcpio -P.
12. Installe systemd-boot.
13. Reconstruit et signe les artefacts de boot selon la cible UKI / Secure Boot.
14. Génère un rapport UUID pré-reboot.
15. Attend Entrée.
16. Propose le reboot avec confirmation oui/non.

Rapport final attendu

Le rapport pré-reboot affiche:

Rapport final pre-reboot:
  UUID disque root: ...
  UUID disque boot: ...
  UUID disque swap: ...
  fstab root: ...
  fstab boot: ...
  fstab swap: ...

Puis compare les UUID attendus avec les fichiers:

Diff UUID disque attendu vs fichiers boot/fstab:
UUID OK: fstab et entrees boot alignes avec les disques cibles.

Si une incohérence est détectée, le script bloque le redémarrage.

Vérifications post-reboot

Dans le système restauré:

findmnt /

findmnt /boot

sed -n '<DEBUT>,<FIN>p' <FSTAB_RESTAURE>

bootctl status

Attendu:

• / monté depuis la partition root du disque restauré;
• /boot monté depuis l'ESP du disque restauré;
• fstab aligné avec les UUID réels;
• entrée courante <ENTREE_BOOT_ATTENDUE>;
• si l'image cible utilise la chaîne renforcée, bootctl status et sbctl status confirment que l'entrée de boot et la signature attendues sont cohérentes.

Chaîne de confiance au boot

La restauration ne s'arrête pas à remettre / et /boot. Le système est considéré restauré seulement si la chaîne de confiance reste cohérente:

• LUKS protège les données au repos;
• TPM peut conditionner l'ouverture au matériel attendu;
• FIDO2 ajoute une voie matérielle alternative pour le déverrouillage;
• UKI limite les écarts entre noyau, initramfs et ligne de commande;
• Secure Boot valide les binaires de boot;
• systemd-boot reste le point d'entrée d'amorçage.

En pratique, la phase post-restore vérifie:

bootctl status

sbctl status

findmnt /

findmnt /boot