EXP C11 — Restaurer le Gold Master : peut-on reconstruire le serveur ?

EXP C11 — Restaurer le Gold Master : peut-on reconstruire le serveur ?

Dans l’expérience précédente, nous avions franchi une étape importante.

Le serveur d’impression fonctionnait, le Wi-Fi était stable dans notre environnement et la Canon LBP-810 imprimait à nouveau depuis Windows et Kubuntu.

Nous avions ensuite capturé l’état complet de la micro-SD sous Kubuntu/Linux avec USBImager 1.0.10.

Mais une question restait ouverte :

une image de sauvegarde permet-elle réellement de reconstruire le serveur ?

Une sauvegarde n’est pas encore une preuve.

Créer un fichier image est une chose.

Le restaurer sur une autre carte, redémarrer le Raspberry Pi et retrouver exactement le même environnement en est une autre.

Nous voulions donc réaliser une expérience beaucoup plus stricte :

reference card
      ↓
full image
      ↓
SHA-256
      ↓
another micro-SD
      ↓
restore
      ↓
boot
      ↓
Wi-Fi
      ↓
CUPS + CAPT
      ↓
real print

Et cette fois, nous avions un avantage important : la carte de référence pouvait rester intacte.

Retour sous Kubuntu.

La carte ayant servi de référence a été arrêtée proprement puis retirée du Raspberry Pi.

Nous l’avons connectée au PC sous Kubuntu et avons commencé par identifier précisément le support.

lsblk

La carte apparaissait comme :

sdc  14.5G  disk
├─sdc1  512M  vfat  RPICFG
└─sdc2  13.8G ext4  armbi_root

Il fallait surtout éviter toute ambiguïté : l’image devait porter sur le disque entier /dev/sdc, et non simplement sur l’une de ses partitions.

USBImager 1.0.10.

C’est ici que nous avons utilisé le logiciel qui nous intéressait depuis l’expérience précédente :

USBImager 1.0.10 sous Kubuntu/Linux.

Dans USBImager, nous avons sélectionné le périphérique :

sdc [14.4 Gio]
Generic MassStorageClass

L’opération choisie était une lecture de la carte vers une image, avec :

Verification: enabled
Compression: enabled
Format: Zstandard

L’image obtenue a été enregistrée sous :

usbimager-20260915T2315.dd.zst

Sa taille était d’environ :

989 MiB

Nous avions maintenant une véritable image brute compressée du support complet.

Le hash.

Comme pour toute sauvegarde que nous voulons pouvoir identifier sans ambiguïté, nous avons calculé son empreinte SHA-256 :

3df3ba1f96060a645fd93fcd74663e0c4e3f8ccf87096b24d771ab4e7f0b2c35

Cette valeur constitue l’identifiant cryptographique de cette image précise.

Et les cartes micro-SD ?

Nous avons alors rencontré un point pratique qui mérite d’être documenté.

Deux cartes micro-SD portant la même capacité commerciale ne sont pas nécessairement constituées exactement du même nombre de secteurs.

Pour une restauration d’image brute, cette différence peut avoir des conséquences très concrètes : une carte de destination légèrement plus petite peut tout simplement ne pas pouvoir recevoir l’image complète.

Nous avons donc vérifié la géométrie réelle des deux supports.

La carte source et la carte destinée à recevoir l’image présentaient exactement :

30 702 592 sectors

La carte de destination affichait :

15 719 727 104 bytes
512 bytes per sector

La géométrie était donc compatible avec notre image.

Une image disque ne garantit pas que n’importe quelle carte micro-SD puisse la recevoir.

Il faut donc choisir les supports avec soin et vérifier leur capacité réelle.

Autrement dit : la marque, la qualité et surtout la géométrie réelle d’une carte peuvent décider du succès de la restauration. Quelques euros économisés sur une carte douteuse peuvent rapidement nous faire maudire tout le projet. :)

Une difficulté que nous n’avons toujours pas expliquée.

Il faut également revenir sur nos expériences précédentes.

Sous Windows, nous avions déjà utilisé des logiciels sérieux de sauvegarde et de restauration, notamment Macrium Reflect. Pourtant, certaines restaurations s’étaient révélées hasardeuses.

Le comportement le plus déroutant concernait la partition Linux principale : après certaines restaurations réalisées avec Macrium Reflect, la carte ne retrouvait pas correctement cette partition une fois replacée sous Linux.

La conséquence était simple : la carte ne pouvait plus fonctionner normalement dans le Raspberry Pi après la copie.

Nous n’avons pas identifié avec certitude la cause de ces comportements.

Il serait donc incorrect de prétendre aujourd’hui expliquer pourquoi ces restaurations ne se comportaient pas toujours comme prévu.

Cette fois, nous avons simplement changé de méthode expérimentale :

Kubuntu
   ↓
USBImager
   ↓
full raw disk image
   ↓
Zstandard compression
   ↓
verified restore

Le résultat allait permettre de trancher une question beaucoup plus intéressante : est-ce que cette méthode permet réellement de reconstruire notre serveur ?

La restauration.

La troisième carte avait été préparée pour l’expérience.

Nous avons ensuite sélectionné dans USBImager :

Source:
usbimager-20260915T2315.dd.zst

Destination:
sdc [14.6 GiB] Generic MassStorageClass

Operation:
Write

Verify:
enabled

La restauration s’est terminée après :

00:16:27

USBImager indiquait :

Terminé. Image écrite avec succès.

Nous avions maintenant une carte qui n’était pas simplement formatée à nouveau : elle avait reçu l’image complète de notre système de référence.

Le moment de vérité.

La nouvelle carte a été remise dans le Raspberry Pi Zero 2 W.

Premier contrôle :

uname -r

Résultat :

6.18.44-current-bcm2711

Le système était bien celui attendu :

PRETTY_NAME="Armbian 26.8.3 resolute"
VERSION_ID="26.04"
VERSION_CODENAME=resolute
ARMBIAN_PRETTY_NAME="Armbian 26.8.3 resolute"

Le nom de machine était également conservé :

rpizero2w

Le matériel USB est toujours là.

Nous avons ensuite vérifié la présence du périphérique d’impression :

ls -l /dev/usb/lp0

Le périphérique était présent :

crw-rw---- 1 root lp ... /dev/usb/lp0

Le système restauré retrouvait donc également la partie matérielle nécessaire à notre chaîne CAPT.

Et CUPS ?

C’est ici que l’expérience devenait vraiment intéressante.

Nous n’avons pas reconstruit CUPS à la main.

Nous avons simplement demandé au système restauré quel était l’état de la file :

lpstat -p LBP810
lpstat -v LBP810

Résultat :

printer LBP810 is idle. enabled since ...

device for LBP810: ///dev/null

La configuration CUPS avait été restaurée avec l’image.

Notre queue, son nom, son état et sa configuration étaient toujours présents.

Le vrai test : imprimer.

À ce moment précis, nous pouvions encore avoir une restauration qui démarre mais dont la chaîne d’impression était cassée.

Il fallait donc imprimer une vraie page.

lp -d LBP810 /usr/share/cups/data/testprint

Le serveur a répondu :

request id is LBP810-2 (1 file(s))

Et cette fois, il n’y avait plus de doute.

La feuille est sortie.

La page était impeccable, identique à celle obtenue avec la carte de référence.

Nous avons reconstruit le serveur.

À partir d’une seule image, nous avons retrouvé :

Armbian 26.8.3
Ubuntu 26.04
kernel 6.18.44
aarch64
hostname rpizero2w
Wi-Fi
systemd-networkd
wpa_supplicant
CUPS
Avahi
CAPT 0.1
/dev/usb/lp0
Canon LBP-810
file:///dev/null
queue LBP810
      ↓
real print

Nous ne sommes donc plus simplement dans la théorie de la sauvegarde.

Nous avons restauré une carte, démarré le Raspberry Pi et obtenu la même impression que sur la carte de référence.

Un autre détail révélateur.

L’image avait également conservé l’état système jusque dans certains éléments d’identité de la machine.

Nous n’avons notamment pas eu besoin de supprimer une ancienne empreinte SSH pour retrouver la machine restaurée à son adresse habituelle : la restauration avait conservé les éléments d’état du système tels quels.

C’est logique pour une image brute complète, mais cela rappelle aussi une précaution importante :

un Gold Master de laboratoire et une image destinée à être distribuée publiquement ne sont pas nécessairement la même chose.

Pour une distribution publique, il faudrait notamment traiter les clés SSH, les identifiants réseau, les historiques et les éventuelles données personnelles.

Pourquoi cette expérience est importante.

Nous avions commencé cette série avec une vieille imprimante Canon que les systèmes modernes ne supportent plus naturellement.

Nous avons ensuite construit un serveur autour d’un Raspberry Pi Zero 2 W, réparé la chaîne CAPT, créé une configuration stable et enfin capturé son état complet.

Mais la véritable validation n’était pas l’existence du fichier image.

La véritable validation était la restauration.

working
     ↓
stable
     ↓
backed up
     ↓
restored
     ↓
working again

Et cette fois, chaque étape a pu être observée et vérifiée.

Le Gold Master est désormais un véritable point de référence.

Nous pouvons maintenant donner un sens précis au terme Gold Master.

Ce n’est pas simplement « la carte qui fonctionne ».

C’est une configuration dont nous possédons :

a working state
      +
a full image
      +
a SHA-256 fingerprint
      +
a verified restore
      +
a real print

Autrement dit :

nous avons maintenant une configuration que nous savons préserver et reconstruire.

Conclusion :

L’expérience C11 est donc validée.

Nous ne nous contentons plus de savoir que le serveur fonctionne. Nous avons démontré qu’une image complète créée sous Kubuntu avec USBImager peut être restaurée sur une autre carte compatible, que le système redémarre correctement, que CUPS retrouve sa configuration et que la Canon LBP-810 imprime à nouveau.

Nous ne savons toujours pas expliquer précisément pourquoi certaines de nos anciennes restaurations réalisées sous Windows étaient problématiques. Mais nous n’avons plus besoin d’en inventer la cause pour avancer : nous disposons maintenant d’une méthode de restauration que nous avons réellement vérifiée.

Le détail des cartes micro-SD nous rappelle également qu’une image n’est pas magique : le support de destination doit être suffisamment grand et compatible avec la géométrie du support original.

Après plusieurs générations de système, de pilotes et de bricolages, le projet vient donc de franchir un nouveau seuil :

Ça fonctionne.
Ça reste stable.
Nous pouvons le sauvegarder.
Nous pouvons maintenant le restaurer.

À suivre …

(12) — Git / GitHub : conserver ce que nous avons appris

Le serveur est désormais reproductible.

Mais une image disque ne contient pas toute l’histoire.

Nous avons accumulé CAPT 0.1, le PPD, les commandes, les procédures, les corrections et surtout tout ce que nous avons appris pendant les expériences.

La prochaine étape sera donc différente :

configuration
      ↓
documentation
      ↓
scripts
      ↓
sources
      ↓
version control

Parce qu’un Gold Master préserve une machine.

Git doit maintenant nous permettre de préserver ce que nous avons appris.

AxehGo & DebIA — Independent Research & Experiments in Linux, AI and Statistical Computing