Je reviens dans le fil après avoir mis à jour ma "base de données" (si je puis dire) concernant
CCC. Car j'utilise toujours la version
5 (dans ses dernières mises à jour) et pas la version
6 nouvelle.
Le
fond du problème n'a pas changé en ce qui concerne l'OS
Big Sur. Son
volume-Système étant
scellé par un sceau d'intégrité > ce volume n'est
pas recopiable par le procédé classique des logiciels de clonage qui est le "
mode fichier". Un
fichier étant un
objet offert à la
lecture ou à l'
écriture dans le périmètre d'un
volume monté.
Copier des fichiers > c'est donc
copier les objets d'un volume à
destination d'un autre volume monté. Mais ce n'est en
aucune façon > forme > ni manière -->
copier le générateur du volume (son "metteur en scène") qui est le
système de fichiers formateur (l'
apfs ici). En ce qui concerne donc le
volume-Système de Big Sur > il ne s'agit
pas simplement de
copier les fichiers-Système contenus dans ce volume => ce qu'il faut c'est
copier le générateur apfs de ce volume qui lui confère le statut exceptionnel de
volume scellé par un sceau d'intégrité.
Pour ce faire > l'
unique mode de copie possible est le "
mode bloc" > où ce qui se trouve copié ce sont les
blocs primaires d'une partition portant les
écritures du système de fichiers formateur. L'outil propriétaire Apple pour exécuter ce mode de copie s'appelle
asr (
apple_software_restore). Mais l'emploi de cet outil s'avère
exigeant dès lors que la
source est un
Conteneur apfs hégergeant une
population de volumes logiques. Car c'est l'
ensemble de la distribution des volumes (
Système >
Données >
Prédémarrage >
Secours) qui doit se trouver
copiée en bloc > via la
réplication des blocs de la source sur les blocs de la destination.
Aucun logiciel de clonage classique qui copie en "
mode fichier" ne peut remplacer le recours à l'exécutable Apple
asr dès lors que le
clone doit inclure une
réplication valide complète des volumes de la source - y compris le
volume-Système.
Ce préambule "théorique" est moins dispensable qu'on pourrait le croire. Car il montre que pour qu'un
clone effectué par
CCC soit
démarrable > il faut qu'une
réplication valide complète des
4 volumes fonciers de Big Sur ait été exécutée sur la
destination.
Réplication valide complète qui ne peut s'effectuer que par l'intermédiaire de l'outil Apple
asr.
Mike Bombich > qui a bâti sa carrière de développeur sur un
logiciel de clonage en "mode fichier" --> a une phobie d'
asr qui copie en "
mode bloc". C'est donc avec le rictus crispé du condamné aux travaux forcés qu'il a été obligé d'
intégrer l'exécutable
asr qu'il abhorre dans la
programmation de CCC. Et il ne rêve que d'une chose : c'est de pouvoir s'en passer si cela était possible.
Ce qui m'amène aux tests que j'ai effectués cet après-midi -->
- a) la version 5 de CCC > lors d'une 1ère tâche de sauvegarde de Big Sur => annonçait par défaut que pour que le clone soit démarrable il fallait passer par l'outil de réplication Apple asr > ce qui implique un reformatage préalable du volume apfs de destination. Il demandait donc à l'utilisateur son accord et si oui --> lançait une tâche de clonage en mode bloc exclusivement gérée par asr. Le clone était démarrable.
- b) la version 6 de CCC > lors d'une 1ère tâche de sauvegarde de Big Sur => ne propose plus par défaut une réplication asr en "mode bloc". Résultat : seul le volume-Données se trouve copié en "mode fichier" > ce qui fait que le clone n'est pas démarrable. C'est la situation de JLB.
J'ai cherché dans tous les sens de l'interface graphique de
CCC comment l'on pouvait
forcer le recours à une réplication asr en "
mode bloc" et j'ai enfin trouvé. Lors de la
définition de la tâche de clonage > prendre en
source le
volume globalement affiché sous le nom du
volume-Système (
Sans titre pour
JLB). C'est sur le choix de la
destination que tout se joue :
sélectionner le volume
apfs du
clone et là s'affiche un
menu contextuel affichant des
options.
Sélectionner l'option intitulée : "
Assistant de sauvegarde démarrable d'ancienne génération" (sous ce label amphigourique se cache l'
outil de réplication Apple asr capable seul de
copier en "mode bloc" la distribution complète de Big Sur). Une demande s'affiche alors : "
Autoriser CCC à effacer [le nom du volume du clone] ?" --> répondre
oui => ce qui va effectuer une
recopie en "mode bloc" entièrement neuve.
- je me suis livré à 2 tests de recopie asr de Big Sur : un avec CCC 5 (fonction proposée par défaut) > l'autre avec CCC 6 (fonction dissimulée dans les options liées à la destination). Mon SSD interne a une vitesse en lecture / écriture d'environ 2000 Mo/s. Je clone à destination d'un SSD connecté en Thunderbolt 3 dont la vitesse en lecture / écriture est d'environ 2500 Mo/s. L'occupation globale du Conteneur Big Sur source est de 80 Go. Avec CCC 5 > l'outil de réplication Apple asr a mis 3' 20" à créer une réplique valide complète de la source sur la destination (les 4 volumes fondamentaux : Système > Données > Prédémarrage > Secours - les 2 autres se créant automatiquement au démarrage). Avec CCC 6 > l'outil de réplication Apple asr a mis 6' 51" a exécuter la même tâche depuis zéro.
Remarques :
- on ne saurait trop conseiller d'en rester momentanément à la version 5 de CCC. Plus rapide pour l'établissement d'un 1er clone démarrable et plus franche du collier en proposant par défaut le recours à l'outil de réplication en "mode bloc" asr pour l'établissement d'un clone démarrable.
- seul le terminal > dans lequel passer la commande :
- permet de visualiser la distribution des volumes dans le Conteneur du clone. Tout clone ne comportant pas au moins les 4 volumes fondamentaux : Clone [le nom du volume choisi] > Clone - Données [ou Data] > Preboot > Recovery => n'est pas un clone valide démarrable de la source Big Sur. L'interface graphique de l'Utilitaire de disque est incapable de représenter intelligiblement la structure logique du Conteneur du clone et de permettre de voir directement si on a affaire à une structure démarrable (4 volumes fondamentaux) ou indémarrable (volume unique).