# Comment sauvegarder ma partition bootcamp ?



## Julie 75 (19 Septembre 2017)

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 (19 Septembre 2017)

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 (19 Septembre 2017)

Julie 75 a dit:


> 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 ?


----------



## Deleted member 1099514 (19 Septembre 2017)

Salut

Personne a tenté cette solution :
Créer une image disque dans windows sur un DDE
Réinstaller bootcamp avec un système de base
Restorer l'image créée précédemment 
en se servant de ce lien : https://www.howtogeek.com/howto/4241/how-to-create-a-system-image-in-windows-7/


----------



## Locke (19 Septembre 2017)

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 (19 Septembre 2017)

Locke a dit:


> Tu parles de ton disque dur interne ?


Oui, un second disque interne, pas celui où est installé mon système.


----------



## Julie 75 (19 Septembre 2017)

r e m y a dit:


> 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 (19 Septembre 2017)

jeanjd63 a dit:


> Salut
> 
> Personne a tenté cette solution :
> Créer une image disque dans windows sur un DDE
> ...


Bonsoir et merci, mais déjà je rame en Français, alors en Anglais, même pas la peine.


----------



## Deleted member 1099514 (19 Septembre 2017)

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


----------



## Julie 75 (19 Septembre 2017)

jeanjd63 a dit:


> 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. Merci et bonne soirée à tous.


----------



## Deleted member 1099514 (19 Septembre 2017)

Sur cette page tu as winclone standard à 28 € environ avec le code : https://twocanoes.com/products/mac/winclone-2/
C'est une bonne affaire.


----------



## r e m y (19 Septembre 2017)

Julie 75 a dit:


> 19 euros, c'est bon. Rémy avait que ce n'était pas donné, alors j'imaginais que c'était beaucoup plus cher. Merci et bonne soirée à tous.



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


----------



## macomaniac (20 Septembre 2017)

[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* (*d*ata_*d*oubler) 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 :

```
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 (20 Septembre 2017)

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 (7 Février 2018)

*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 ? 

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


----------



## macomaniac (8 Février 2018)

*Jibest
*


The Jibest a dit:


> 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* (*a*pple_*s*ofware_*r*estore) 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* (*d*ata_*d*oubler ou *d*isk_*d*oubler). 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 (8 Février 2018)

*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


----------

