Migration du système vers un autre disque dur

Support Debian
#1

Bonjour,

après des recherches sur je sujet je viens poser ma question ici car je n’ai rien trouvé de vraiment satisfaisant sur les pages que j’ai consulté à ce sujet.

Voici ma situation:

je dispose d’un serveur sous débian qui tourne 24/7 depuis plusieurs années, récemment suite à la panne d’un autre ordinateur j’ai du le convertir en ordinateur de bureau.

L’installation initiale tourne encore très bien sur le disque dur d’origine : 9.5Go partitionné en 2 parties 9Go pour / et 0.5 de swap

Mais ce disque est très vieux (24/7 depuis au moins 10 ans) montre des signes de faiblesses (de plus en plus bruyant…)

Je viens d’acheter un disque sata neuf d’1To

Je souhaite faire migrer mon installation vers le nouveau disque, ce que je veux garder c’est surtout la conf des serveurs ( apache, mysql, smb, ssh, postfix/dovecot)

Je pensais procéder comme suit:

  1. partitionnement et formatage du nouveau disque:
    3 partitions:
  • Primaire ext4 de 200Go pour /,
  • Etendue avec deux volumes:
    ** un swap de 4Go
    ** une ext4 (le reste de la capacité) pour /home
    ->ceci dit il me semble que le monde a évolué depuis la dernière fois que j’ai fait ceci et la notion primaire/etendue est peut-être obsolète… Ma répartition peut-être mal choisie… Des conseil?

  1. suivre la procédure installation depuis un disque dur proposée ici en ayant au préalable copié mon /etc précédent vers la partition / … Je pense que les scripts de postconf me proposeront de garder mes fichiers de conf des serveurs.

  2. Définissant le nouveau disque comme masterboot dans mon bios, mise en place d’un dual-boot avec grub (en utilisant startupmanagerr) pour me laisser la possibilité de booter sur l’ancienne installation …

Est-ce que cela a des chances de marcher ou est-ce que je fais fausse route?
Y a-t-il plus simple?

Je suis preneur de tout conseil…

Merci d’avance pour votre aide.

FaFa

#2

Si c’est pour tout garder à l’identique mais sur un disque neuf, j’aurais fait un bon gros dd if=[vieux disque] of=[nouveau disque] depuis un live CD (en pensant à corriger /etc/fstab sur le disque neuf, à la fin), puis effectivement désigner le nouveau disque comme disque n°1 dans le BIOS. Ensuite il devrait être possible de redimensionner les partitions à ta convenance.

Et effectivement, de plus en plus, on trouve des disques durs avec GPT et non plus MBR. Si le BIOS de ta carte mère est assez récent (je crois qu’il faut qu’elle soit UEFI), tu peux alors utiliser GPT (c’est une autre façon de gérer les partitions du disque, notamment GPT supporte jusqu’à 128 partitions, et la table de partitions est écrite à plusieurs endroits du disque).

#3

Le clonage avec dd est une solution simple et rapide pour remplacer un disque, mais il a un gros inconvénient si l’ancien disque est conservé à côté du nouveau : les identifiants censés être uniques UUID et LABEL des partitions seront dupliqués et ne seront donc plus unique. Si les partitions sont identifiées par leur UUID dans /etc/fstab et ailleurs comme c’est la norme depuis longtemps, impossible de prédire si ce sera une partition de l’ancien ou du nouveau disque qui sera utilisée.

L’identification par le nom de périphérique /dev/sd* n’est pas mieux car ce nommage n’est pas persistant ; d’un démarrage à l’autre, /dev/sda peut désigner un disque ou l’autre. D’où l’utilisation des UUID.

Il faudrait donc après le clonage modifier les UUID et le cas échéant les LABEL des partitions du nouveau disque, modifier /etc/fstab et les autres endroits qui contiennent des UUID (chargeur d’amorçage, initramfs…) en conséquence. Fastidieux, risque d’erreur et d’oubli non négligeable…

Aussi, un disque en service ininterrompu depuis plus de 10 ans a probablement été installé avec une version originelle de Debian très ancienne. Même si elle a été mise à niveau régulièrement depuis, il doit rester pas mal de scories des anciennes versions (je connais, j’ai la même chose, transférée par clonage sur 3 disques différents depuis l’installation initiale). Le système de fichiers doit être au mieux ext3 qui est obsolète, or ext4 est plus moderne, performant et adapté pour les disques de grande capacité.

D’autre part FaFa souhaite séparer /home de la racine, ce qui ne peut être fait par simple clonage. Certes il serait possible de créer une nouvelle partition et d’y déplacer le contenu de /home. Mais beaucoup d’arguments plaident en faveur d’une réinstallation qui remettrait tout au propre, même si cela donne un peu plus de travail.

Pas besoin d’UEFI pour utiliser GPT avec Linux. C’est une contrainte de Windows seulement. Un BIOS bien élevé se fiche du format de table de partition. Le PC sur lequel j’écris a un BIOS non UEFI et un disque en GPT.

Non, une table de partition GPT supporte autant de partitions que défini lors de sa création, et le nombre minimum recommandé et par défaut est 128. On peut très bien créer une table de partition GPT avec un nombre maximum de partitions différent.

A deux endroits : au début et à la fin.
Ce qui pose des problèmes qui n’existaient pas avec la table de partition MBR/DOS en cas de clonage avec dd sur un disque de taille différente :

  • la table de partition de secours ne sera pas à la fin du disque et donc inutilisable en cas de destruction de l’en-tête de la table de partition GPT principale.
  • si le disque de destination a une capacité supérieure, l’espace disponible ne sera pas augmenté tant que l’en-tête GPT n’aura pas été corrigé et la table de partition de secours réécrite à la fin du disque.
  • si le disque de destination a une capacité inférieure (mais suffisante pour contenir toutes les partitions du disque source), la table de partition de secours ne sera pas copiée.
1 J'aime
#4

Merci pour tous ces conseils qui confirment le choix d’une nouvelle install vers lequel je veux m’orienter.

Après mes lectures j’avais effectivement écarté la possibilité d’un simple clonage, principalement a cause de la vétusté de l’install ( je suis parti d’une deb3 ou 4 je ne sais plus, pour monter jusqu’a la 8… Avec à chaque fois des ajustements manuels pour résoudre des pb de conflits de paquets et de dépendance, bref ca tourne mais c’est pas très propre … ), et de l’histoire de UUID .

  1. Je vais me documenter sur GPT, que je ne connaissais pas, auriez-vous des liens pertinents sous la main à me suggérer?

  2. Au niveau de la répartition du nouveau disque est-ce que mon choix / - swap - /home tient la route ? (les contenus www et autres ne sont pas dans le dossier standard mais sont montés depuis un autre disque dont je n’ai pas besoin de parler) serait-il utile/pertinent de faire des partitions séparées pour /boot, /var etc… Comme on le trouve suggéré à de nombreux endroits? (je pense que non mais une confirmation me rassurerait)

  3. est-ce que la copie a priori du /etc (en ecartant /passwd et /fstab entre autres) me permettrait de retrouver rapidement la conf des serveurs ? Ou est-il plus approprié de reprendre les confs une par une a posteriori?

Merci pour votre aide.

#5

Je te conseille de lire ce fil, sur lequel je posais de nombreuses questions à Pascal, au sujet de GPT, entre-autres.
Partlabel et GPT

#6

Une partition séparée pour /boot ne se justifie que dans quelques cas :

  • Le BIOS ne peut pas adresser la totalité de l’espace disque et la racine occupe des secteurs dans la partie inaccessible par le BIOS ; cela arrive le plus souvent avec les disques de plus de 2 Tio (donc pas ton cas), ou de très vieux BIOS (peut-être ton cas si la machine est aussi vieille que le disque d’origine).
  • La racine n’est pas lisible par le chargeur d’amorçage parce que chiffrée ou dans un format que le chargeur ne sait pas lire.
  • Même si GRUB 2 sait lire LVM, on peut préférer mettre /boot dans une partition simple lorsque la racine est en LVM, au cas où la structure du LVM serait altérée.

En plus de /home, j’aime bien l’idée de séparer /var et /tmp car c’est là que se trouve le contenu qui “bouge” le plus (fichiers temporaires, logs…) , et donc qui est le plus susceptible d’être corrompu en cas de plantage, ou de saturer l’espace disque en cas de problème en cas d’anormalie. Les séparer évite que cela affecte la racine.

Plutôt que de copier tout le contenu de /etc a priori, ce qui risque d’importer des éléments obsolètes, je ne copierais que les fichiers de configuration utiles a posteriori (s’ils sont à jour).

#7

Ok, et quelle quantité allouer à /var et /tmp sur un disque d’1To ? 100Go chacun? moins? plus?

#8

Ça dépend de ce que tu comptes mettre dedans. 100 Go est probablemet beaucoup trop pour un système typique mais à la limite peu importe si l’espace disponible pour le reste est suffisant, tu peux te permettre de gaspiller. Quelques Go devraient largement suffire.

Si tu sais utiliser LVM, ça permet de définir des tailles initiales jugées suffisantes pour commencer et d’agrandir les volumes en cas de besoin.

#9

Je viens de regarder pour LVM:
du coup il parait adequat de faire:

  • une part ext4 pour /boot (quelle taille? 200Mo me semblent largement suffisants, peut-être meme moins)
  • une part pour swap (4Go ? 8Go)
  • une part ext4 en LVM avec 4 volumes:
    ** /var (100Go)
    ** /tmp (100Go)
    ** / (200Go (plus?) )
    ** /home (le reste)
#10

Oui. Et celle-là, on ne pourra pas l’agrandir donc autant prévoir large. A placer au début du disque.

Pourquoi ne pas utiliser LVM pour le swap ?

Ça ne marche pas comme ça. La partition pour LVM (PV) est au format LVM, pas ext4. Ce sont les volumes logiques (LV) qui peuvent être en ext4, swap, etc.[quote=“FaFa, post:9, topic:71598”]
** /var (100Go)
** /tmp (100Go)
** / (200Go (plus?) )
[/quote]
Trop gros pour commencer. Tu peux diviser au moins par 10.
Pense que tout tenait sur un disque de 10 Go.

Erreur classique du débutant, commise également par l’installateur en partitionnement assisté. Pour pouvoir agrandir les volumes logiques ultérieurement, il faut laisser de l’espace libre dans le groupe de volumes (pas sur le disque).

#11

Donc en fait , si je passe par LVM, je partitionne mon nouveau disque en deux :
première partition de 200Mo en ext4 pour /boot
et le reste pour le LVM, et ensuite je partage la part LVM en plusieurs parties, en gardant de l’espace vierge en réserve pour plus tard ? Je pourrais alors agrandir mes volumes selon mes besoins ?

Comme outil je partitionne avec gdisk puis je fais appel aux outils du paquet lvm2, en particulier system-config-lvm ?

#12

Oui tout à fait, c’est pour ça qu’il faut ensuite aller renseigner dans le fstab le retour de la commande blkid par exemple, histoire d’identifier les partitions à monter par leur UUID.
(personnellement, j’ai réalisé une seule fois un changement de disque dur avec cette méthode dd + inscrire les UUID des partitions dans fstab et j’ai pas eu de soucis)

Sinon merci pour les infos complémentaires et les corrections, Pascal, comme d’hab :slight_smile:

#13

En gros, oui.

Pas besoin de recourir à ces outils, tu peux tout faire dans l’installateur en partitionnement manuel.

D’autre part, gdisk ne gère que les tables de partition GPT. Je répète que ce format n’est indispensable que pour les disques de plus de 2 Tio ou si on veut créer plus de 4 partitions sans recourir à la structure fragile d’une partition étendue et de partitions logiques. Or tu n’as besoin que de 2 (ou 3, voir phrase suivante) partitions et le disque a une capacité inférieure à 2 Tio, donc une table de partition DOS/MBR fera aussi bien l’affaire.

Si tu optes néanmoins pour le format GPT, je recommande de créer une partition supplémentaire non formatée de 1 Mio au début du disque, de type “BIOS boot” qui sera utilisée par GRUB pour l’amorçage BIOS. Note que certains BIOS qui ont des exigences au delà des spécifications sur le contenu du MBR peuvent nécessiter des ajustements pour amorcer un disque au format GPT.

Pour un amorçage EFI il faudrait créer à la place une partition “système EFI” plus grosse et formatée en FAT (ce n’est pas spécifique à GPT, il en faudrait aussi une si le disque est au format DOS/MBR) mais si le serveur a au moins 10 ans il est peu probable qu’il ait un firmware UEFI. Même si c’est le cas, le firmware aura un mode de compatibilité BIOS et l’intérêt d’utiliser l’amorçage EFI est à peu près nul.

#14

J’ai fini de faire ma migration selon les conseils précédent pour ce qui concerne le partitionnement.

Pour le reste j’ai procédé comme suit, et ça a marché:

  1. j’ai fait une install minimale neuve sur le nouveau disque
  2. j’ai copié les /etc de mes serveurs dans le nouveau /etc
  3. j’ai réinstallé, testé et ajusté un à un mes serveurs
  4. l’ai ensuite installé le reste (environement bureautique etc…)

Et tout tourne…

Merci pour ceux qui m’ont aidé sur ce sujet.