Locke
Tiens, tiens, je serais curieux de savoir ce qu'en pense
macomaniac.
Hé ! J'ignorais complètement ce logiciel : «
StellarDriveClone.app». Et dans cet état de « bienheureuse ignorance »
(s'il est vrai que : « quiconque augmente sa science, augmente sa douleur ») > la méthode que j'aurais spontanément employée est la même que celle décrite par
r e m y : partitionner le SSD en 2 partitions d'accueil principales, une au format
jhfs+ pour l'accueil d'
OS X et une format
FAT-32 pour l'accueil d'un clonage par «
Winclone» (lequel reformate en
ntfs) > cloner par «
CCC» la partition
OS X du HDD dans celle dédiée du SSD (ce qui aurait aussi cloné la
Recovery HD en-dessous) > cloner par «
Winclone» la partition
Win du HDD dans celle dédiée du HDD.
♤
Mais une méthode "tout-en-un" est bien entendu séduisante - surtout par les questions théoriques qu'elle soulève :
comment cela peut-il se faire ? - de ce point de vue, j'ai une réponse passant par l'utilitaire UNIX
dd (
disk_doubler : duplicateur de disque -
disk_destroyer disent les mauvaises langues : destructeur de disque, parce que si on inverse la
source et la
destination, on clone du vide sur du plein et on a 2 vides à l'arrivée au lieu de 2 pleins).
dd est parfaitement capable de cloner un
disque entier (et pas telle ou telle
partition d'un disque) sur un
disque entier - ce pour la simple raison qu'il opère en mode "
blocs" et pas en mode "
fichiers".
Quand on copie en mode "
fichiers", on est dépendant aussi bien sur la
source que sur la
destination d'un mécanisme logique qui a commencé par
monter des volumes : il s'agit des
systèmes de fichiers gérant les partitions concernées, qui convertissent l'
espace des blocs d'écriture bruts de la partition en un
espace de répertoire (= un
volume monté) dans lequel se montrent des
fichiers (des séquences d'écriture reconnaissables). Et donc un cloneur en mode "
fichiers" va copier le "
contenu" d'un
espace de répertoire (un
volume monté) dans un autre - ce qui implique, qu'en
destination, il faut qu'une
partition préexiste,
formatée par un système de fichiers, lequel doit avoir
monté l'espace de blocs en un "
espace-répertoire" =
volume. C'est ainsi qu'opère «
CCC».
Quand on copie en mode "
blocs", on n'est pas dépendant de l'activation de systèmes de fichiers montant des volumes > mais ce qui est cloné est l'
espace-blocs brut de la partition dont le volume est
démonté, et dont le système de fichiers gestionnaire est
désactivé. Système de fichiers désactivé résidant sur l'
en-tête de la partition
source qui va donc se trouver cloné comme
gestionnaire d'en-tête de la partition
destination. Car il s'agit d'un
remplacement d'écritures total des blocs bit à bit. Si la
source d'un clonage en mode "
blocs" n'est pas une
partition de disque, mais un
disque entier, alors le procédé est d'une radicalité totale, car il y a
recopie bit à bit des écritures de blocs, impliquant le
secteur de boot du disque compris (les premiers blocs portant les fichiers de la Table de Partition), les
headers des partitions supportant les systèmes de fichiers et les
alignements d'écriture de données des blocs des partitions. À l'arrivée, on obtient un
clone intégral : càd. un disque "
doublé" sur un autre disque, où chaque partition a l'exacte taille de son original etc.
Je n'ai jamais essayé à l'échelle de gros disques (durs ou SDD), mais je présume qu'une opération
dd prenant pour
source un
disque entier partitionné en
OS X et
Win donnerait à l'arrivée un disque entier partitionné en
OS X et
Win qui serait le
jumeau intégral de l'original et dont aucun bit d'information n'aurait été perdu, à condition qu'il n'y ait pas de mauvais blocs sur la
source non plus que sur la
destination. Mais j'ai essayé expérimentalement à petite échelle, avec
2 clés USB de taille comparables (
15 Go), la source partitionnée en 2 volumes de données avec une
Recovery HD de 650 Mo en intercalaire créée par mes soins > j'ai passé une commande du type :
Bloc de code:
sudo dd if=/dev/rdisk1 of=/dev/disk2 bs=4096 conv=notrunc,noerror
(ou
disk1 est le disque de la clé
source et
disk2 celui de la clé
destination) > à l'arrivée, la clé de
destination est la
jumelle absolue de l'
originale : même partitionnement, mêmes données, même icônes et intitulés > c'en est troublant : impossible de distinguer "graphiquement" l'une de l'autre.
L'utilitaire
dd est donc un opérateur particulièrement impressionnant - mais comme en toutes choses, cela a un coût : le procédé de clonage en mode "
blocs" est infiiniment plus
lent que celui qui opère en mode "
fichiers". Le clonage expérimental du disque entier d'une clé sur le disque entier de l'autre (
15 Go) a pris
des heures ! Et pourtant j'avais opté pour une valeur numérique de "
blocksize" (nombre de blocs à considérer comme un "super-bloc" à transférer) de
4096 censée augmenter la vélocité de
dd.
♧
Cette apparente digression par l'utilitaire UNIX
dd n'est pas inopportune, car elle amène à se demander
quelle sorte de procédé de clonage est implémentée dans le logiciel «
StellarDriveClone.app», lorsqu'on utilise son option de recopie de disque à disque. Conjecturalement parlant, j'écarte un recours radical à
dd à l'image de la commande que j'ai citée, car les temps de transferts seraient immensément longs, ce qui donnerait une application peu "vendeuse" à l'usage. Mais je m'interroge sur le moyen utilisé pour cloner un partitionnement logique : clonage des fichiers de la
GPT de la
source sur la
destination (
backup) ? Ou plus modestement
lecture du partitionnement de la source et commande de
repartitionnement de la destination d'après cette information ?
La mention d'une partition dédiée à
Win créée au format
exFAT me laisse conjecturer qu'il s'agirait du 2è procédé. Cela fait, un dispositif des partitions sur le disque d'
accueil congruent de celui du disque
source > il doit être concevable de gérer temporellement un clonage en mode "
fichiers" des partitions
JHFS+ sur leurs homologues, et je le présume (pour répondre aux objections de
r e m y à ce sujet) un clonage de type «
Winclone» des fichiers d'une partition
Win dans son homologue préfigurée au format
exFAT d'accueil («
Winclone» requérant pour sa part une partition d'accueil
FAT-32 qu'il reformate en
NTFS) > ce qui fait qu'on aurait bien en sortie une partition en format
NTFS bootable sur la
destination, comme sur la
source.
=> cela supputé, je m'accorde avec
r e m y pour dire que, le disque
source ne devant être accédé qu'en
lecture seule sans modification intrinsèque et le SDD étant
vierge => il n'y a rien à perdre (sinon l'argent de la licence d'un logiciel) à tenter le clonage
disque à disque par «
StellarDriveClone.app» mais tout à gagner (logiquement parlant). Attention quand même (en cas d'essai de boot) au type de connexion du SSD à l'
iMac s'il s'agit de booter
Windows en externe...
[NB. Pour ne pas faire mentir l'adage latin : « in cauda venenom » > cloner un disque à destination d'un autre disque comporte toujours un risque énorme > c'est celui de confondre la source et la destination > car au lieu d'avoir 2 disques "pleins" au final > on obtient en cas de bévue 2 disques "vides" en sortie... ]
♡
