Comment sauvegarder ma partition bootcamp ?

Julie 75

Membre junior
24 Janvier 2015
96
3
24
seine et marne
Bonjour,

Si j'ai bien compris dois changer mon disque dur montrant des défaillances lors du test smart (nombre de secteurs ré-alloués 5).
Ce disque contient toutes mes photos, j'ai des sauvegardes Time Machine, mais il contient aussi une partition Bootcamp.
Comment faire pour la sauvegarder afin de pouvoir la réinsérer dans le nouveau disque? Une image disque?
Je suis sur mac pro El Capitan à jour.

Merci d'avance de vos aides.

Cordialement.
 

r e m y

Cas clinique
Club MacG
4 Novembre 2000
41 492
4 321
59
St Germain en Laye - FRANCE
Pour sauvegarder la partition BootCamp et la recopier ensuite sur le nouveau disque, il faut acheter l'utilitaire WinClone de TwoCanoes.

Ce n'est pas donné mais il fonctionne parfaitement et c'est la seule solution pour faire cette duplication et retrouver ensuite une partition BootCamp identique et opérationnelle, une fois le disque changé.

Sans WinClone, la partition BootCamp est perdue et doit etre recree sur le nouveau disque, puis il faut reinstaller Windows, puis ses applications et enfin ses donnees (sous reserve de les avoir sauvegardees depuis un utilitaire de sauvegarde sous Windows)
 

Locke

What am I doing here?
Modérateur
Club MacG
20 Juillet 2011
37 842
5 246
Ce disque contient toutes mes photos, j'ai des sauvegardes Time Machine, mais il contient aussi une partition Bootcamp.
Tu parles de ton disque dur interne ?
 

Locke

What am I doing here?
Modérateur
Club MacG
20 Juillet 2011
37 842
5 246
A tester aussi, j'ai un iMac 27 de 2015. Je démarre sans aucun problème avec un clone d'une version de Windows 10 faite depuis un vrai PC portable avec EaseUS Todo Backup Workstation avec un disque dur SSD dans un boîtier en USB 3.0. Chose qui n'est pas possible sous macOS, sauf avec un clone créé avec Winclone dans un boîtier Thunderbolt.
 

Julie 75

Membre junior
24 Janvier 2015
96
3
24
seine et marne
Pour sauvegarder la partition BootCamp et la recopier ensuite sur le nouveau disque, il faut acheter l'utilitaire WinClone de TwoCanoes.

Ce n'est pas donné mais il fonctionne parfaitement et c'est la seule solution pour faire cette duplication et retrouver ensuite une partition BootCamp identique et opérationnelle, une fois le disque changé.

Sans WinClone, la partition BootCamp est perdue et doit etre recree sur le nouveau disque, puis il faut reinstaller Windows, puis ses applications et enfin ses donnees (sous reserve de les avoir sauvegardees depuis un utilitaire de sauvegarde sous Windows)
Bonsoir,
Merci de ta réponse, j'ai tech tool pro 9, je pourrais faire un clone avec ?
Non, je viens de regarder, il ne propose pas de cloner ma partition Bootcamp nommée "Untitled".
 

Julie 75

Membre junior
24 Janvier 2015
96
3
24
seine et marne
D

Deleted member 1099514

Invité
Sinon te prends pas la tête Winclone coute 19 € dans sa version simple et c'est largement suffisant pour ton usage.
 

Julie 75

Membre junior
24 Janvier 2015
96
3
24
seine et marne
Sinon te prends pas la tête Winclone coute 19 € dans sa version simple et c'est largement suffisant pour ton usage.
19 euros, c'est bon. Rémy avait que ce n'était pas donné, alors j'imaginais que c'était beaucoup plus cher.:eek: Merci et bonne soirée à tous. :merci::kiss:
 

r e m y

Cas clinique
Club MacG
4 Novembre 2000
41 492
4 321
59
St Germain en Laye - FRANCE
19 euros, c'est bon. Rémy avait que ce n'était pas donné, alors j'imaginais que c'était beaucoup plus cher.:eek: Merci et bonne soirée à tous. :merci::kiss:

WinClone standard c'est plutôt 45€...
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
85 344
25 732
Forêt de Fontainebleau
[Simple incrustation technique sans enjeu pratique ici]

À supposer que le disque défaillant du Mac Pro soit un HDD de 1 To et qu'il soit envisagé de le doubler par un autre disque de 1 To - ce qui permet de supposer a priori une égalité de taille des 2 disques.

Une commande dd (data_doubler) exécutée à partir du démarrage sur un Système tiers et prenant en source le disque entier défaillant et pour destination le nouveau disque - par exemple :
Bloc de code:
sudo dd if=/dev/rdisk0 of=/dev/disk1 bs=4096 conv=notrunc
réaliserait un clone intrégral du disque 0 sur le disque 1.

Comme dd copie byte à byte de manière à reproduire sur la destination les écritures exactes des blocs de la source --> il recopie donc exactement sur le disque de destination les tables de partition du secteur de boot du disque source (blocs 0 à 32) > puis les alignements de blocs des partitions dont les en-têtes de blocs porteurs des fichiers des systèmes de fichiers.

En conséquence > le disque de destination cloné byte à byte est un double logique du disque source. On doit donc théoriquement retrouver dessus la partition BOOTCAMP bootable de la source, au byte près et sur des blocs équivalents.

S'il y a un excédent de blocs sur le disque de destination par rapport à la source > dd neutralise ces blocs en affectant des astériques * = signes de null_bytes à chaque byte excédentaire > ce qui équivaut à une "suppression" des blocs excédentaires.

Les 2 inconvénients immenses de la commande dd sont qu'elle n'est pas bavarde (impossible de suivre la progression de la copie en mode byte à byte et bloc à bloc) > et qu'elle est d'une lenteur à faire paraître véloce un escargot de Bourgogne.
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
85 344
25 732
Forêt de Fontainebleau
Petit addendum dans la même veine que ce qui précède.

J'ai fait le test d'une commande dd entre 2 clés USB où -->

  • la source est un disque de 3,8 Go > avec table de partition GUID > et 2 partitions : EFI (209 Mo) et STOCK (pour près de 3,8 Go) au format JHFS+ ;
  • la destination est un disque de 4,1 Go > avec table de partition MBR et 1 seule partition BROL de 4,1 Go au format exFAT.

Le volume STOCK de la source contient une image-disque jouant le rôle de témoin.

Après un long processus (muet - les 2 volumes étant nécessairement démontés) > le disque de la source étant inchangé > j'obtiens comme disque de destination :

  • la destination est un disque de 3,8 Go reconnus > avec table de partition GUID > et 2 partitions : EFI (209 Mo) et STOCK (pour près de 3,8 Go) au format JHFS+. Dans le volume STOCK de la destination est présente l'image-disque présente dans le volume la source.

Les 2 disques ont donc bien été alignés --> les [nombre de blocs disponibles > table de partition > nombre de partitions > contenu des partitions] du disque destination sont bien devenus un clone exact des paramètres de la source.
 

The Jibest

Membre confirmé
15 Novembre 2005
189
19
Toulouse
:coucou: macomaniac,

Je remonte ce post car je lis tes interventions développées pour comprendre un peu plus la structure de nos disques et l'outil fétiche Terminal ;)

Si j'ai bien suivi le cas école que tu proposes, la commande dd du Terminal copie intégralement une source vers une destination. Un peu comme une image disque qui recopie fidèlement la source.

Je suis allé voir dans Onyx/Utilitaires qui affiche facilement le manuel des commandes, mais même en épluchant toute la commande que tu donnes, j'ai du mal à faire le point.

Tu précises que la destination sera de la même taille que la source, s'il y a de l'espace supplémentaire, il ne paraîtra plus "suppression" des blocs excédentaires. Par contre, on peu envisager avec cette méthode de "cloner" un disque avec toutes ses partitions ? L'intérêt dans le cas du post étant la partition Bootcamp.

Peut-on exploiter cette même commande dd en préservant l'espace restant dans le cas d'une destination plus volumineuse, ou à l'inverse, si une destination est moins volumineuse mais suffisamment pour accueillir les données ? Je dois rêver un peu ? :angelic:

Enfin, réaliser la commande avec une image disque calibrée à la taille exacte de la source ?

:merci:
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
85 344
25 732
Forêt de Fontainebleau
:coucou: Jibest

la commande dd du Terminal copie intégralement une source vers une destination

Oui : c'est ça.

Disons qu'il y a 2 grands procédés de recopie :

a) le procédé en mode "fichiers" (utilisé par des commandes comme cp > ditto > rsync et des logiciels comme comme «Carbon Copy Cloner» ou «Super Duper!»). La source pour ces opérateurs est toujours exclusivement ce que montre un volume monté. Volume défini par la structure logicielle sous-jacente et externe du système de fichiers inscrit sur l'en-tête de la partition. Définition d'un Volume càd. d'un espace de répertoire affichant des fichiers lisibles et scriptibles. Ce qui est une conversion opérée par le système de fichiers à partir des blocs d'écriture bruts de la partition. La définition d'un volume est donc la génération de cet espace de répertoire affichant des fichiers > qui en somme est la version « user_friendly » ou encore « human_readable » de l'alignement des blocs bruts de la partition.

Le volume étant défini par le système de fichiers comme espace "user_friendly" --> il est monté par le kernel (noyau opérateur) > càd. pris en charge comme espace-disque.

Bref ! cette mise-en-scène "tournée vers l'utilisateur" effectuée par les 2 compères invisibles : le système de fichiers et le kernel --> des "pseudo-objets" ont l'air d'« exister en soi », comme des entités quasi chosistes : des fichiers (et des fichiers de fichiers = dossiers). C'est ces "pseudo-objets" que les opérateurs de copie en mode "fichiers" prennent pour source. Ils ne vont pas au-delà de cette présence "chosiste" dans l'espace "human_readable" du volume monté. Et idem pour la destination : c'est aussi un volume monté > càd. un espace de présentation de fichiers > dépendant d'un autre système de fichiers inscrit sur une autre partition de disque > mais monté par le même unique kernel qui est seul à opérer en tant que noyau d'un Système.

----------

- b) le procédé en mode 'blocs" (utilisé par des commandes comme asr ou dd). Ces opérateurs se contrefichent des fichiers présentés dans l'espace de répertoire du volume. Il se contrefichent même, dans l'absolu, du volume. Du volume monté (par le kernel). Mais aussi bien du volume en tant que définition logique d'un espace de répertoire par le système de fichiers. Ils traversent le point de montage du volume sur la partition > qui est le point de départ de la génération du volume par le système de fichiers : le point de départ de cet espace de répertoire. Ils le traversent pour accéder au « raw disk ».

Le « raw disk » (disque brut) est le conteneur de la partition. Càd. l'espace brut de blocs allant d'un n° tant à un n° tant qui est enregistré dans la table de partition. Le point de départ du « raw disk » est le 1er bloc absolu de la partition : le bloc limite. Sur ce bloc est inscrit le header du système de fichiers. L'opérateur qui copie en mode "blocs" va donc copier à partir du 1er bloc de la source --> il va donc copier en 1er lieu l'en-tête des blocs de la partition "source" où réside le système de fichiers du volume source. Et il va copier ces blocs supportant le système de fichiers de la source --> sur l'en-tête des blocs de la partition de destination. Il va donc remplacer le système de fichiers de la destination > par un clone du système de fichiers de la source.

À partir de là > le destin de l'opérateur en mode "blocs" est scellé --> pour que le clone sur la destination du système de fichiers de la source retrouve ses "petits" --> càd. puisse définir un alignement de blocs bruts comme espace de répertoire de fichiers lisibles --> il faut absolument que l'alignement des blocs de la partition-source qui suivent le "point de montage" [càd. le bloc limite qui distingue la fin du système de fichiers du départ du volume montable] --> soit copié strictement à l'identique de la source sur la destination.

Ainsi --> le système de fichiers cloné sur l'en-tête des blocs de la partition de destination --> passé le bloc "limite" du point de montage --> trouvera un alignement de blocs clones de ceux de la source --> correspondant exactement dans leurs écritures aux gestionnaires du système de fichiers exporté : le fichier du catalogue B-tree > le fichier de l'allocation des blocs (bitmap) > le fichier des segments de blocs en excès (extents) etc.

Des 2 utilitaires > asr (apple_sofware_restore) est le plus "souple" --> au sens où s'il y a dans le conteneur de la partition de destination un espace de blocs excédentaires par rapport à la partition source (par exemple : source = 500 Go > destination = 999 Go) --> il ne va pas neutraliser les 499 Go de blocs excédentaires parce qu'ils ne correspondent pas a priori au système de fichiers de la source cloné sur la destination. Mais le système de fichiers cloné sur la destination > va être "étiré" en finalisation de la copie pour intégrer comme "espace disponible" les blocs excédentaires. asr est un magnifique exemple de l'ingéniérie Apple.

L'utilitaire dd est un binaire à programmation aussi puissante que rigide : tous les blocs excédentaires dans le conteneur de la partition de destination par rapport à la capacité de la partition source seront neutralisés en finalisation de la copie. Càd. que les bytes correspondant à ces blocs seront flaggués comme « null_bytes » (marqués par un astérique *) --> de telle sorte que les blocs constitués de « null_bytes » seront des « null_blocks ». Espace-disque "absent" (introuvable) qui fait que le conteneur de la partition incluant cet espace-disque "zéroïsé" n'aura pour capacité que les blocs (écrits ou libres) correspondant à la source. Dans mon exemple : 500 Go (499 Go de « null_blocks » se trouvant "disparus").

Je présume que dd puisse cloner un disque entier en mode "blocs" en commençant "à partir du commencement" --> càd. le bloc 0 ou premier bloc du disque source. Bloc 0 supportant la table alternative Protective_MBR > puis clonant les 32 blocs suivant portant la Pri[mary] GPT > puis etc. tous les blocs à la suite jusqu'au dernier bloc du disque de la source.

Je n'ai jamais testé cette capacité > harrassé d'avance (mentalement) par le procédé dd (data_doubler ou disk_doubler). Procédé opérant en aveugle (pas de fonction verbose ; on peut simplement mettre dd en pause --> ce qui affiche une sommation provisoire du rapport : nombre de bytes copiés par tant de secondes) > d'une lenteur phénoménale (malgré un choix possible de clusters 4096 bytes) car copiant byte à byte comme un véritable bourrin. Ça peut prendre des jours et des jours cette affaire !

En résumé : je n'arrive jamais à me motiver pour m'intéresser à dd --> c'est plus fort que moi. L'intérêt de retrouver sur un disque de destination la distribution complète d'un disque source n'arrive pas à m'impulser (je m'en f...).
 

The Jibest

Membre confirmé
15 Novembre 2005
189
19
Toulouse
:coucou: macomaniac

Je te remercie pour cette revue de détail impressionnante. Pour moi c'est une invitation à plonger dans la structure de nos disques et je la saisis :)

Bon, il va me falloir plusieurs lectures et plongées dans le dico informatique pour assimiler ce cours. Ces 2 lettres, comme D-Day recèlent un sacré programme.

Je comprends, en synthèse, que le caractère obscur de l'action de dd qui opère en aveugle, prend son temps et peu pilotable ne te motive pas, tu m'as aussi convaincu. La maîtrise que tu as pour scruter la structure globale d'un disque et les actions possibles pour utiliser/réparer les partitions de façon claire n'a pas d'équivalent ;)

:merci: