La sauvegarde revient souvent ici. Elle apparaît dans les articles sur YunoHost, sur grommunio, sur Immich, sur le Fediverse, sur Mastodon, sur le courriel, sur la migration depuis Umbrel ou encore sur les alternatives auto-hébergées aux grands services centralisés.
Autrement dit, le sujet est là. Il revient, il insiste, il accompagne presque chaque étape de cette démarche d’auto-hébergement.
Et pourtant, reconnaissons-le : parler de sauvegarde ne signifie pas toujours être parfaitement au point sur le sujet.
Et c’est précisément ce que cette « opération » matérielle a remis en lumière. Pendant longtemps, la sauvegarde restait un sujet sérieux, documenté, compris dans ses grandes lignes, mais encore partiellement théorique. J’ai évoqué les sauvegardes YunoHost, des copies vers le NAS, des procédures, des scripts, des alertes, des rapports. Mais il me manquait encore une étape concrète : celle qui touche réellement au disque système du serveur, avec le risque très concret de tout casser.
Cette fois, le passage s’est fait du « il faudrait vraiment le faire proprement » au « c’est fait, vérifié, et le serveur redémarre » (ouf 😮💨).
Ce retour d’expérience ne prétend pas encore atteindre la règle des 3-2-1, souvent rappelée dans les bonnes pratiques de sauvegarde : trois copies, deux types de supports, une copie hors-site. La démarche reste perfectible. Mais elle avance dans cette direction. Et surtout, elle rappelle une chose que l’on oublie facilement : une sauvegarde n’est rassurante que lorsqu’elle s’inscrit dans une procédure que l’on comprend, que l’on peut répéter, et dont on a testé au moins une partie du chemin de retour.
Le contexte : remplacer le NVMe du serveur homelab
Le serveur concerné est le serveur homelab principal, une machine YunoHost utilisée pour héberger plusieurs services personnels. L’objectif semblait simple : remplacer le SSD NVMe interne par un modèle plus récent, plus fiable, et mieux adapté à l’usage quotidien du serveur.
Le choix s’est porté sur un Samsung SSD 970 EVO Plus NVMe M.2 de 500 Go. Le modèle n’a pas été choisi au hasard : l’idée était d’avoir un support reconnu, suffisamment performant, avec de bonnes capacités en lecture et en écriture, afin de rester cohérent avec le reste de l’infrastructure locale.
Le serveur dispose désormais d’un adaptateur réseau 2,5 Gb, connecté à un switch compatible et à une connexion fibre. Le stockage n’est évidemment pas le seul facteur de performance, mais autant éviter que le disque devienne une faiblesse inutile dans une chaîne technique que l’on cherche progressivement à rendre plus solide.
Au départ, le plan paraissait assez direct :
ancien disque NVMe du serveur → clonage avec Rescuezilla → nouveau Samsung → redémarrage. FIN !
Sur le papier, rien de très compliqué.
En pratique, un détail a changé toute l’opération.
Le piège des « 500 Go » face aux « 512 Go »
La première surprise est venue de la capacité réelle des disques.
L’ancien disque du serveur était annoncé comme un NVMe de 512 Go. Le nouveau Samsung, lui, était un modèle de 500 Go. Jusqu’ici, cela pouvait sembler être une différence commerciale sans grande importance. Après tout, le disque du serveur n’était pas rempli. La partition principale n’utilisait qu’une petite partie de l’espace disponible.
Mais un clonage disque ne raisonne pas seulement en « données utilisées ». Il regarde aussi la taille des partitions et leur position sur le disque.
Et là, le problème est devenu très concret : l’ancien disque faisait environ 512 Go, tandis que le Samsung faisait environ 500 Go. Plus exactement, sous Linux, le Samsung apparaissait comme un disque de 465,8 Gio. La partition principale de l’ancien disque était trop grande pour être copiée telle quelle sur le nouveau support.
La leçon du moment : pour un clonage direct, un disque « 500 Go » n’est pas forcément un remplaçant naturel d’un disque de « 512 Go ».
C’est une erreur facile à faire. Elle semble même assez logique quand on n’a pas encore été confronté à la différence entre capacité commerciale, capacité réelle, Go, Gio, taille des partitions et contraintes de clonage. Mais au moment de migrer un serveur, cette nuance était devenue bloquante.
Première étape : contrôler le nouveau SSD
Avant de toucher au serveur, le nouveau Samsung a été branché sur un ordinateur via un adaptateur USB/NVMe, afin de vérifier qu’il était bien détecté et qu’il ne présentait pas d’erreur évidente.
Le système reconnaissait correctement le disque comme un Samsung SSD 970 EVO Plus. Le SMART n’était pas disponible via l’adaptateur USB, ce qui arrive souvent avec ce type de boîtier. Un test de lecture complet a donc été lancé depuis le terminal pour lire l’intégralité du disque, sans écrire dessus.
Le résultat a été rassurant : le disque a été lu du début à la fin, sans erreur d’entrée/sortie.
Ce contrôle ne remplace pas un vrai diagnostic SMART lorsque le disque est branché directement en NVMe interne, mais il permet déjà d’écarter un défaut manifeste avant de commencer une opération plus sensible.
Deuxième étape : comprendre que le clonage direct ne suffisait pas
Une fois la taille du disque actuel vérifiée, le problème est plus devenu clair : le disque source était plus grand que le disque cible. Et même si les données tenaient très largement sur le Samsung, la partition principale ne pouvait pas être copiée telle quelle.
Deux options existaient alors :
- acheter un NVMe plus grand, par exemple 1 To, pour faire un clonage direct sans se poser de question. Toutefois, l’actuelle techflation rendait la chose exorbitante.
- ou conserver le Samsung 500 Go, mais réduire proprement la partition de l’ancien disque avant de cloner.
La seconde option a été retenue, mais avec une précaution indispensable : faire d’abord une sauvegarde complète du disque actuel.
Troisième étape : faire une vraie sauvegarde avant de toucher aux partitions
Avant de redimensionner quoi que ce soit, un disque externe USB de 1,5 To a été branché au serveur. Rescuezilla a été utilisé pour créer une sauvegarde complète du disque NVMe actuel.
Cette étape change tout psychologiquement.
Sans sauvegarde, redimensionner la partition système d’un serveur peut vite devenir une opération anxiogène. Avec une sauvegarde complète, vérifiée, le risque ne disparaît pas, mais il s’affaiblit.
Une fois la sauvegarde terminée, Rescuezilla a permis de lancer une vérification de l’image. Les partitions importantes ont été validées. La partition swap, elle, a généré un avertissement normal : ce type de partition ne se vérifie pas comme une partition classique contenant des fichiers. Rien d’inquiétant à ce stade.
Le point important était ailleurs : il existait désormais une copie de sécurité avant de modifier le disque système.
Quatrième étape : réduire la partition avec GParted
La machine a ensuite été démarrée depuis Rescuezilla, qui permet aussi d’utiliser GParted.
L’ancien disque contenait trois partitions :
- une partition EFI de 512 Mio
- une grande partition ext4 pour le système YunoHost
- une petite partition swap
La grande partition ext4 occupait presque tout le disque de 512 Go. Pour qu’elle tienne sur le Samsung, elle a été réduite à 460 Gio. Ce choix permettait de rester très proche de la capacité utile du Samsung, tout en gardant une petite marge de sécurité.
La partition swap, placée après la partition principale, a ensuite été déplacée juste après elle. L’espace non alloué s’est retrouvé à la fin de l’ancien disque, ce qui permettait au nouvel agencement de tenir dans le Samsung.
Cette étape est probablement la plus importante de toute l’opération.
Le but n’était pas de recréer un disque, ni de formater, ni de repartir de zéro. Il s’agissait simplement de réduire proprement la partition existante, puis de repositionner la swap.
GParted a appliqué les opérations avec succès 🥳
Cinquième étape : cloner l’ancien disque réduit vers le Samsung
Une fois le disque source redimensionné, le Samsung a été branché au serveur via son adaptateur USB/NVMe.
Rescuezilla a ensuite été utilisé en mode clonage disque vers disque.
La source était l’ancien NVMe interne du serveur.
La destination était le Samsung SSD 970 EVO Plus branché en USB via l’adaptateur.
⚠️ Attention : c’est probablement l’erreur la plus dangereuse dans ce type d’opération : inverser source et destination revient à écraser le bon disque avec le disque vide.
Le clonage a copié les trois partitions :
- la partition EFI
- la partition système ext4
- la partition swap
Rescuezilla a également mis à jour les éléments nécessaires au démarrage. Le clonage s’est terminé sans erreur.
Sixième étape : remplacer physiquement le disque
Une fois le clonage terminé, la machine a été éteinte proprement.
Le Samsung cloné a été retiré de son adaptateur USB, puis installé physiquement à la place de l’ancien NVMe dans le serveur.
L’ancien disque n’a pas été effacé. Il a été conservé intact, comme disque de secours. C’est une précaution simple, mais précieuse : si un problème de démarrage était apparu, il aurait suffi de remettre l’ancien disque pour retrouver le serveur dans son état précédent.
Au redémarrage, le serveur a démarré normalement sur le Samsung.
Septième étape : vérifier que tout fonctionne
Après le premier démarrage, plusieurs vérifications ont été faites.
Le système voyait bien le Samsung comme disque principal :
- partition EFI montée sur
/boot/efi - partition ext4 montée sur
/ - partition swap active.
Le contrôle SMART du Samsung, cette fois branché directement en NVMe interne, indiquait un état sain :
- test SMART global : réussi
- usure : 0 %
- erreurs d’intégrité des données : 0
- température correcte pour un NVMe après migration
Le système ne signalait aucun service en échec. Le diagnostic YunoHost était globalement bon. Les alertes restantes concernaient des éléments déjà connus : un domaine à renouveler prochainement et une application YunoHost signalée comme cassée dans le catalogue. Rien qui soit lié au changement de SSD.
À ce stade, l’opération pouvait être considérée comme réussie.
Derrière le clonage, une question de résilience
Cette migration n’est pas seulement une histoire de SSD. Elle révèle plusieurs choses utiles pour celles et ceux qui auto-hébergent leurs services.
La première : un clonage simple n’est simple que si le disque cible est au moins aussi grand que le disque source. Sinon, même avec très peu de données utilisées, la taille des partitions peut bloquer l’opération.
La deuxième : une sauvegarde n’est pas une option de confort. C’est ce qui permet de travailler avec une marge de sécurité. Dans cette expérience, la sauvegarde complète sur disque externe a permis de redimensionner le disque source avec beaucoup moins d’appréhension.
La troisième : Rescuezilla et GParted forment un duo très accessible, à condition de prendre son temps. Rescuezilla rassure pour la sauvegarde et le clonage. GParted permet d’adapter proprement les partitions lorsque la situation n’est pas aussi simple que prévu.
La quatrième : conserver l’ancien disque intact après ce type d’opération technique est une excellente assurance. Même si tout fonctionne, ce disque reste une copie physique complète de l’ancien système. Il ne règle pas tout, mais il offre une possibilité de retour rapide en cas de problème imprévu.
Sauvegarder, ce n’est pas seulement copier
Le point le plus intéressant, au fond, est peut-être celui-ci : sauvegarder ne se limite pas à produire des fichiers quelque part sur un NAS ou sur un autre support de stockage.
Une sauvegarde devient vraiment sérieuse et utile lorsqu’elle entre dans une chaîne complète :
- savoir où elle se trouve
- savoir comment elle a été produite
- vérifier qu’elle n’est pas corrompue
- comprendre comment elle pourrait servir
- tester, au moins partiellement, le scénario de retour
Cette migration de disques n’est sûrement pas encore une stratégie parfaite. Il reste des marges de progression : copie hors-site, chiffrement systématique selon les usages, test complet de restauration sur une autre machine, documentation plus formelle.
Mais elle marque une étape importante : le serveur principal a été sauvegardé, son disque a été redimensionné, son système a été cloné, puis il a redémarré sur un nouveau support.
Dans un parcours d’auto-hébergement, ce genre d’expérience compte. Non pas parce qu’elle serait spectaculaire, mais parce qu’elle rapproche la résilience de sa réalité la plus matérielle : un disque, une sauvegarde, une erreur possible, une méthode, et la capacité de reprendre la main.
PS : Merci à Genma pour son article sur la la règle des 3-2-1 ainsi qu’à Alex Hoyau pour l’inspiration du titre et les échanges autour du sujet.
Laisser un commentaire