résolu - dd : copier une partition sur autre hdd, table dos vers GPT

rem · Le 25/01/2023, à 22:19

Bonjour,

J'ai un miroir logiciel mdadm RAID1 de 1TB constitué par deux partitions sur deux disques durs identiques, une par disque.
C'est /dev/md0 qui est monté sur /home avec son UUID.
Ces disques ont une table de partition dos.

La racine est sur un autre disque SSD.

J'ai désormais deux nouveaux disques durs identiques ST4000LM024 de 4TB
Je compte les utiliser avec une table de partition GPT, avec un miroir logiciel mdadm RAID1 et pour le futur /home
Ces ST4000LM024 sont décrits comme ceci : « Bytes per sector : 512 (logical) / 4096 (physical) »

Mon objectif est de garder la date de création des répertoires et des fichiers.

Je pense laisser un des disques actuels et placer un des nouveaux dans les deux baies de mon transportable.
Je pense démarrer en recovery et démonter /home si le montage est existant puis stopper le miroir dégradé.
Je pense créer une première partition sur le nouveau disque, exactement de la même taille (1953521664 secteurs) que sur les anciens disques.

Je voudrais savoir si je peux utiliser la commande dd pour copier la partition actuelle sur la partition nouvellement créée ?
Je me demande si le type différent de table de partition entre la partition source (dos) et celle de destination (GPT) peut poser un problème ?

Merci

rem@n73sm-lubuntu:~$ sudo fdisk -l /dev/sd[ab]
Disque /dev/sda : 931,51 GiB, 1000204886016 octets, 1953525168 secteurs
Disk model: HGST HTS721010A9
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xe46a7557

Périphérique Amorçage Début        Fin   Secteurs Taille Id Type
/dev/sda1              2048 1953523711 1953521664 931,5G fd RAID Linux autodétecté


Disque /dev/sdb : 931,51 GiB, 1000204886016 octets, 1953525168 secteurs
Disk model: HGST HTS721010A9
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xa87e3474

Périphérique Amorçage Début        Fin   Secteurs Taille Id Type
/dev/sdb1              2048 1953523711 1953521664 931,5G fd RAID Linux autodétecté
rem@n73sm-lubuntu:~$

Bilan :
La commande dd n'est pas appropriée dans mon cas.
Avec les outils mdadm, je peux reconstruire /dev/md0 avec un nouveau disque pour première étape,
puis avec les deux nouveaux disques en deuxième étape.
udisksctl status # est utile pour différencier les disques de références identiques par leur numéro de série (Merci à MicP)
Il faut aussi faire attention à mdadm.conf et fstab pour s'assurer de la reconnaissance et du montage (UUID du raid).
Si l'UUID du raid change, mdadm.conf indique d'utiliser update-initramfs -u
Ne pas trop solliciter la machine lors des synchronisations.

J'ai mal mesuré la cage ; je pensais franchement avoir les 15 mm de hauteur.
La connectique SATA du disque dépasse de moins de 3 mm celle de la cage du transportable...
J'ai deux ST4000LM024 à vendre ? Non, je renvoie gratuitement et je suis remboursé
J'ai appris finalement que ce sont des disques SMR, alors je ne regrette rien.

Dernière modification par rem (Le 27/01/2023, à 19:57)

geole · Le 25/01/2023, à 23:45

Bonsoir
La commande dd va te poser de gros problémes car tu vas te retrouver avec une cible de même taille qu'il faudra bricoler pour agrandir.
Le plus simple me semble
Travailler avec ton systeme opérationnel
1) Créer ton nouveau raids de 4 To
3) Avec rsync dupliquer le contenu de home dans ce nouveau raid.
Pendant cette opération, évite d'utiliser la messagerie car les nouveautés risqueraient de ne pas être toutes transférées.
4) Lorsque c'est fini, mets à jour le fichier /etc/fstab puis reboote. Tu pourras alors faire ce que tu veux de l'ancien raids.

Cependant, à mon avis, c'est le moment ou jamais de dédier ce raids à tes données personnelles et de réintégrer le logiciel du home avec le logiciel principal qui est dans un SDD afin de profiter de sa vitesse et de 'souder' le home qui ne sera alors jamais absent au démarrage.

Ajout.
Dans ce contexte, je verrais bien ta messagerie (certainement thunderbird) être traitée comme données personnelles mais pas firefox. Ce dernier point se discute.

Dernière modification par geole (Le 26/01/2023, à 00:05)

FrancisFDZ · Le 26/01/2023, à 10:17

Bonjour,

geole a écrit :

Dans ce contexte, je verrais bien ta messagerie (certainement thunderbird) être traitée comme données personnelles mais pas firefox. Ce dernier point se discute.

Et les problèmes éventuels liés à firefox en snap (qu'on commence à savoir gérer )

rem · Le 26/01/2023, à 10:30

Bonjour,

Merci geole pour ton message.
J'ai un système sans snap.

geole a écrit :

La commande dd va te poser de gros problémes car tu vas te retrouver avec une cible de même taille qu'il faudra bricoler pour agrandir.

Je me suis trompé, il n'y a pas besoin d'utiliser dd pour atteindre mon objectif : les commandes mdadm sont suffisantes.
Agrandir un RAID1 n'est pas très compliqué.

geole a écrit :

Avec rsync dupliquer le contenu de home dans ce nouveau raid

rsync ne préserve pas la date de création des dossiers et des fichiers.

geole a écrit :

Cependant, à mon avis, c'est le moment ou jamais de dédier ce raids à tes données personnelles et de réintégrer le logiciel du home avec le logiciel principal qui est dans un SDD afin de profiter de sa vitesse et de 'souder' le home qui ne sera alors jamais absent au démarrage.

J'ai un répertoire /home/$USER sur le SSD qui est suffisant pour démarrer en cas de perte totale du RAID1 mécanique.
Je garde le SSD pour le système et le RAID pour les données des utilisateurs.

Tout ce à quoi j'avais pensé s'avère inutile sauf placer un disque neuf à la place d'un des deux disques anciens.
Si j'ai bien compris, je peux faire quasiment toutes les opérations nécessaires à chaud et même en graphical.target pour avoir la documentation.
Sauf les interventions physiques sur les disques.

Je poursuivrai avec des demandes d'aide relatives à mdadm en cas de besoin et sur un autre fil.
Je place en résolu.

Dernière modification par rem (Le 26/01/2023, à 10:59)

MicP · Le 26/01/2023, à 11:06

Bonjour

Si besoin :

Je constate que tu as plusieurs disques ayant les mêmes références,
et si tu as besoin de débrancher physiquement un de ces disque et pas l'autre,
tu auras peut-être du mal à savoir comment les différencier.

La ligne de commande suivante :

udisksctl status

permet de récupérer le numéro de série du disque, et le nom du fichier de périphérique qui permet d'accéder à ce disque
et ce numéro de série est, la plupart du temps, inscrit sur l'étiquette qui est collée sur le disque
ce qui permet de savoir quel disque physique il faudra déconnecter.

rem · Le 26/01/2023, à 11:11

Bonjour MicP

C'était un véritable souci ; je comptais outrepasser et me débrouiller.
Merci beaucoup !

geole · Le 26/01/2023, à 11:21

Oui.
Il est vrai que tu peux déclarer un disque failing, le remplacer par un plus grand puis rebâtir .
Faire la même chose pour l'autre. Puis agrandir. chapitre 5.2
Mais, à mon avis, cela va prendre beaucoup plus de temps.
Cela serait bien que tu notes les temps d exécution pour un disque de 1 To en bon état...

Ajout.
J'ai remarqué que même la commande cp ne conserve pas la date de création. Cela semble un problème de conception linux. Il n y aurait que mac capable de cette action.

Dernière modification par geole (Le 26/01/2023, à 13:45)

MicP · Le 26/01/2023, à 11:41

Les cartes mères actuelles sont équipées de puces SATA
qui permettent de débrancher/rebrancher un disque sans avoir besoin d'arrêter la machine <=> https://en.wikipedia.org/wiki/Hot_swapping

J'ai testé ça avec un RAID5 pour vérifier si le disque spare allait être automatiquement mis en service en cas de panne
et ça a parfaitement fonctionné, même pas eu besoin d'arrêter le système Linux : C'est magique

Bien sûr, après avoir fait ça, le RAID se reconstruit automatiquement et ça prends du temps
pendant lequel le système travaille beaucoup, mais j'avais fait mes tests avec des "petits" disques.

Si tu as un doute, recherche les références de la puce SATA de ta carte mère (ou autre carte fille)
et cherche sur le net pour confirmer/infirmer si le hotplug est possible.

Dernière modification par MicP (Le 26/01/2023, à 12:07)

rem · Le 26/01/2023, à 15:58

geole a écrit :

Mais, à mon avis, cela va prendre beaucoup plus de temps.

Le temps, ce n'est pas vraiment un problème pour moi.
Mais l'argent, là oui, c'est plus difficile.

Je suis vert

J'ai mal mesuré la cage ; je pensais franchement avoir les 15 mm de hauteur.
La connectique SATA du disque dépasse de moins de 3 mm celle de la cage du transportable...
Le disque neuf que j'ai déballé et touché et manipulé est déjà remis dans l'anti ESD et scellé.

J'ai repris mon 1T et la reconstruction s'est faite extrêmement rapidement.
Dans mon malheur, je n'ai rien cassé ! C'est juste une déception.

geole a écrit :

Cela serait bien que tu notes les temps d exécution pour un disque de 1 To en bon état...

De quelle temps d'exécution parles-tu ?

geole a écrit :

même la commande cp ne conserve pas la date de création. Cela semble un problème de conception linux.

Je crois plutôt que c'est une fonctionnalité voulue.

MicP a écrit :

C'est magique

Pas de souci pour des disques facilement extractibles ; pour mon transportable de 2012 je n'ai pas besoin de chercher.
J'espère pouvoir essayer un jour

Dernière modification par rem (Le 27/01/2023, à 19:58)

geole · Le 26/01/2023, à 16:05

Les 3 mm étaient dans le mauvais sens ......
Je parlais du temps entre le moment où tu vas lancer la commande d'ajout de la nouvelle partition et où cela te dit que la reconstruction est totalement finie pour le disque neuf.

Dernière modification par geole (Le 26/01/2023, à 16:06)

rem · Le 26/01/2023, à 18:09

Ce temps n'est mesurable qu'avec les taux de lecture et d'écriture aucunement atténués par d'autres process.
Autrement, en utilisant en même temps son système, la mesure n'a pas vraiment de sens.
Le système lui-même peut engendrer une atténuation dans certains cas.

Il y a d'autres facteurs qui interviennent, les performances globales et celles des disques et des contrôleurs.
Pour te donner un ordre de grandeur sur un vieux et poussif micro-serveur : plus de 10 heures pour un spare de 4T vierge dans un RAID6.
En SATA300 et CPU 2@1500 (HP Proliant N40L) ; Cela peut être vraiment long.

geole a écrit :

Les 3 mm étaient dans le mauvais sens ......

C'est très pertinent car ama il faut laisser de l'espace autour des disques durs pour aider à la dissipation thermique.

Globalement, mon erreur tient d'un manque partiel de formation initiale et surtout d'expérience pro continue.
J'aurais pu me trouver des boîtiers adéquats pour des sauvegardes de - grosse - poche et tester ButterFS qui me fait envie
Mais j'ai un accord pour un remboursement intégral.

J'en ai fini avec ce sujet.
Merci pour les contributions et aux lecteurs

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 25/01/2023, à 22:19

résolu - dd : copier une partition sur autre hdd, table dos vers GPT

#2 Le 25/01/2023, à 23:45

Re : résolu - dd : copier une partition sur autre hdd, table dos vers GPT

#3 Le 26/01/2023, à 10:17

Re : résolu - dd : copier une partition sur autre hdd, table dos vers GPT

#4 Le 26/01/2023, à 10:30

Re : résolu - dd : copier une partition sur autre hdd, table dos vers GPT

#5 Le 26/01/2023, à 11:06

Re : résolu - dd : copier une partition sur autre hdd, table dos vers GPT

#6 Le 26/01/2023, à 11:11

Re : résolu - dd : copier une partition sur autre hdd, table dos vers GPT

#7 Le 26/01/2023, à 11:21

Re : résolu - dd : copier une partition sur autre hdd, table dos vers GPT

#8 Le 26/01/2023, à 11:41

Re : résolu - dd : copier une partition sur autre hdd, table dos vers GPT

#9 Le 26/01/2023, à 15:58

Re : résolu - dd : copier une partition sur autre hdd, table dos vers GPT

#10 Le 26/01/2023, à 16:05

Re : résolu - dd : copier une partition sur autre hdd, table dos vers GPT

#11 Le 26/01/2023, à 18:09

Re : résolu - dd : copier une partition sur autre hdd, table dos vers GPT

Pied de page des forums