10.10 Yosemite [Résolu] Utilitaire de disque: Restaurer

[Laubuntu]

Salut,

J'ai acheté un nouveau disque dur externe (appelons-le # 2). Je voulais copier une partition de l'autre dd que j'ai (appelons-le # 1) jusque #2.
Donc, la partition appelée "DATA" de #1 doit être copiée dans la partition "FAT CLONE" sur # 2.
Les deux partitions sont en MS-DOS FAT.

Je voulais utiliser la fonctionnalité "Restore" (dans l'Utilitaire de disque).
J'avais choisi DATA comme source et FAT CLONE comme destination.

Lorsque j'ai cliqué sur «Restaurer», j'ai eu un doute, je n'avais pas copié les données de DATA ailleurs, au cas où quelque chose se passe.
J'ai annulé l'opération, et maintenant je ne peux plus voir DATA dans le Finder. Il est encore ici dans l'Utilitaire de disque, mais il est apparemment démonté.

Donc ma question est: dois-je simplement le re-monter et vais-je retrouver toutes mes données à nouveau? J'imagine que c'est ce que je dois faire, mais je ne veux vraiment pas tout foirer, étant donné que j'ai des données qui sont unique là dessus... Voilà pourquoi je pose la question sur ce forum

Merci d'avance pour votre aide!

 

[Laubuntu]

Comme prévu, il suffisait de remonter le volume.
J'ai fait ça après avoir reçu une réponse sur un thread que j'avais posté sur un autre forum (voir ici)

Je vais marquer le post comme résolu, au cas où d'autres personnes fassent la même bêtise que moi

 

[Membre supprimé 1060554]

Salut Laubuntu

La fonction "Restaurer" (restore) de l'«Utilitaire de Disque» de «Yosemite» (= Disk Utility "old school") pilote l'utilitaire UNIX asr (apple_software_restore) qu'on peut aussi appeler en ligne de commande dans le «Terminal» pour le même type d'opération.

Cet utilitaire asr a besoin au départ qu'on lui donne comme "source" et comme "destination" des disques ("containers" = partitions) ayant un point de montage apparent : càd. des partitions dont le système de fichiers (filesystem) a été activé de manière à monter le volume correspondant. Ces adresses "source" et "destination" obtenues, asr s'empresse de... démonter leurs volumes, en désactivant leurs systèmes de fichiers respectifs, afin de pouvoir engager un processus de copie bloc à bloc du "container" de la "source" sur le "container" de la "destination".

Il n'est donc pas étonnant, qu'ayant arrêté ton opération de restauration qui avait été engagée, tu te sois retrouvé avec les 2 volumes démontés de ta "source" et de ta "destination" (asr ne les remonte qu'à la complétion de son opération). Aucun problème donc pour remonter manuellement le volume de ta "source" (DATA) dont le disque (container de la partition) n'a été l'objet que d'une lecture de la part d'asr.

À inspecter ta capture de l'«Utilitaire de Disque», je note néanmoins que, sur l'autre DDE qui devait être celui de ta "destination" (le WD My Passport), le volume démonté correspondant n'apparaît plus sous son intitulé de volume (FAT CLONE d'après ton message), mais que seul l'identifiant logique du container-disque de la partition est mentionné : disk3s2 (section n°2 du disque 3) => est-ce que tu es sûr que cette partition remonte également un volume ? J'en doute, si aucun nom de volume (monté ou démonté) n'est mentionné.

Ma conjecture : le processus asr commence toujours par effacer (erase) le système de fichiers de la "destination" en préalable de son opération. Comme tu l'as interrompue, il y a des chances qu'aucun système de fichiers ad-hoc n'ait été re-créé > donc aucun volume n'est actuellement montable > il faudrait donc, manuellement, que tu sélectionnes la partition disk3s2 et que tu actives l'option "effacer" (Erase) de l'«Utilitaire de Disque» (avec le format et le nom que tu veux), pour qu'un système de fichiers, capable de remonter un volume, y soit recréé [ attention ! ta sélection de la cible doit être strictement la partition disk3s2 > tu pourras faire tes choix dans le panneau qui se démasquera > presse pour activer le bouton "Erase" (effacer) tout en bas à droite du panneau).

À présent, j'ai encore 2 observations à faire :

- a) à ma connaissance, l'utilitaire asr n'admet en "source" et en "destination" que des containers-disques dont le système de fichiers est au format JHFS+ (Mac OS étendu journalisé) > en cas de formats "exotiques" (comme le FAT-32), lors de la préparation préalable, s'il est capable (et même j'en doute) d'effacer (erase) la destination pour y imprimer un format jhfs+, il rejettera une "source" en FAT-32. Je ne pense pas que la fonction "Restore" fonctionne, par conséquent, entre 2 containers-disques au format de système de fichiers FAT-32.

- b) le format MS-DOS (FAT-32) comporte une limitation intrinsèque, qui est de ne pas permettre la copie de fichiers de + de 4 Go > est-ce que tu ne trouves pas ce format limitatif (par rapport à l'exFAT qui n'a pas cette restriction) ?​

 

[Laubuntu]

Salut, merci pour ta réponse détaillée!

J'ai déjà utilisé Restaurer et asr via le Terminal (nottament pour installer un OS sur une carte SD pour mon Raspberry Pi). Pour cette raison, j'étais quasiment certain qu'il suffisait de seulement remonter le disque et que je n'avais rien perdu. Je préférais demander pour être sûr, ne voulant vraiment pas faire de bêtises.

L'autre disque importait peu, il était déjà vide de toute façon mais oui j'imagine qu'asr dans ce cas a commencé par effacer ce disque avant de lancer la copie.

a) N'ayant pas essayé je ne saurais pas dire. Peut être que cette opération aurait refusée effectivement. J'ai choisi la méthode classique et j'ai bêtement copié/collé les fichiers. Je voulais utiliser cette fonction en pensant que ce serait plus rapide.

b) Je connais la restriction du FAT32 et elle m'importe peu, j'ai rarement des fichiers qui dépassent 4 Go. Maintenant, quelle est la différence avec le exFAT. J'imagine que le fait que l'exFAT accepte des fichiers plus gros apporte un inconvénient derrière...?Si non, effectivement, je ferai mieux de passer à l'exFAT. Mais encore une fois, il est très rare que j'ai des fichiers plus gros que 4 Go...

 

[Membre supprimé 1060554]

Ceci est une facétie dominicale​

Hé ! Comme j'aime bien expérimenter (et pas seulement spéculer au plan logique

- histoire de soumettre le spéculatif à l'épreuve de l'expérience) => j'ai donc expérimenté d'une part une commande asr dans le «Terminal» vs une option "Restaurer" dans l'«Utilitaire de Disque».

Pour ce faire, j'ai attaché à mon Mac 2 clés USB, que j'ai tablées en MBR, avec une seule partition chacune au format MS-DOS (FAT-32). La première clé est donc identifiée dans son disque comme disk1 > dans sa partition unique FAT-32 comme disk1s1 > dans son nom de volume comme SOURCE ; la 2è clé => disque disk2 > partition unique FAT-32 = disk2s1 > nom de volume = TARGET.

- a) expérience en ligne de commande («Terminal»).

Je saisis la commande canonique :

sudo asr restore -s /dev/rdisk1s1 -t /dev/disk2s1 --erase --noprompt

et j'obtiens en retour : un démontage instant des 2 volumes (qui cessent d'être affichés sur le Bureau) > et ce retour dans le «Terminal» :

Validating target...done
    Validating source...
Could not recognize "/dev/rdisk1s1" as an image file
done
Could not get source volume name

=> bref, un avortement d'entrée de la commande, au fait que la "source" n'est pas reconnaissable (car le container de la partition contient un format de fichiers FAT-32). Pour ce qui est de la "destination", pas de problème a priori, puisque asr se réserve en principe le privilège d'effacer le système de fichiers de la "destination", et donc d'en reconstituer un neuf au format qui lui convient (= jhfs+).

=> À l'issue de cet échec en ligne de commande, les 2 volumes sont démontés, mais tous les 2 remontables sans problèmes - aucun effet ne s'étant ensuivi.

--------------------​

- b) expérience graphique («Utilitaire de Disque 10.10.5»).

Je choisis l'option "Restaurer" (Restore) et je fais glisser sur la fenêtre de la "source" le volume monté SOURCE = disk1s1 de la clé disk1 > et sur la fenêtre de la "destination" le volume monté TARGET = disk2s1 de la clé disk2 > je presse le bouton "Restaurer".

À ma grande surprise, après démontage préliminaire des 2 volumes (affichés en grisé) > un processus de restauration s'engage avec une barre de progression de la tâche et une durée d'opération fonction de la quantité de données présentes sur la "source", de la connexion (USB-2 chez moi) et de la vitesse intrinsèque des disques (clés USB ici parmi les plus lentes du monde - j'achète toujours les clés le meilleur marché pour test et je collectionne donc les « rossignols »).

J'observe donc, ébranlé, ce « miracle » improbable : l'utilitaire asr (piloté graphiquement par la fonction "Restaurer") en train d'accomplir via l'«Utilitaire de Disque» ce qu'il refuse d'accomplir via le «Terminal», càd. la manifestation d'une « Contradiction Logique » qui me déconfit dans ma croyance au respect du « Principe d'Identité Logique » en informatique - tout en réveillant le démon sommeillant de la logique dialectique, qui est l'invalidation même de l'informatique...

... lorsque, à la fin de l'opération prétendue, voici qu'un panneau s'affiche dans l'«Utilitaire de Disque» :

Échec de la restauration
Impossible de restaurer - Paramètre invalide

Pfuiiit ! J'ai eu chaud... Je voyais déjà un cas de « Logique Dialectique » (càd. de validité de la contradiction) intervenir dans l'informatique Mac (ce qui eût marqué son caractère unique : « Think different ! ») > mais non : le processus avorte bien et bien.

Et comment avorte-t-il ? En laissant démonté le volume SOURCE de ma "source" (disk1s1) mais qu'il m'est aisé de remonter, sans perte de données. Par contre, en ce qui concerne ma "destination" > pfuit ! plus de volume TARGET, dont le système de fichiers a manifestement été complètement flingué pendant la tentative, et simplement l'affichage de l'identifiant de la partition disk2s1. Partition déclarée "Impossible à monter" : un format de système de fichiers DOS_FAT_32 est toujours identifié dans ce container, mais dépourvu de nom de volume montable => autant dire qu'il est corrompu. L'«Utilitaire de Disque» appelé à "Réparer le disque" sur cette partition répond : « Erreur : Utilitaire de disque ne peut pas réparer ce disque. Sauvegardez autant de fichiers que possible, reformatez le disque, puis restaurez vos fichiers sauvegardés ».

Une commande :

diskutil repairVolume disk2s1

renvoie un :

Started file system repair on disk2s1
Repairing file system
** /dev/rdisk2s1
Invalid BS_jmpBoot in boot block: 000000
File system check exit code is 8
Updating boot support partitions for the volume as required
Error: -69845: File system verify or repair failed
Underlying error: 8: POSIX reports: Exec format error

=> ce qui me désopile, car la recommandation de l'«Utilitaire de Disque» de "sauvegarder autant de fichiers que possible" est manifestement impossible à suivre en mode "remontage d'un volume", puisque le système de fichiers est planté avec son secteur de boot d'un volume en vrac. Je présume, pour que la recommandation fasse sens, qu'elle signifie : "employez un logiciel de récupération des données par scan des blocs" > ce qui porte l'absurde à un échelon supérieur, puisque la partition dont il s'agirait de récupérer des données était la partition cible de la restauration, càd. destinée à être effacée avant restauration à partir de la source > comme quoi, à échapper la « logique dialectique », la logique identitaire n'échappe pas à l'absurde...​

=> en résumé : la logique aristotélicienne (non-contradictoire) est respectée, aucune intervention de la dialectique hégélienne (contradictoire) n'étant admise dans l'espace logique du « think different ! » (je respire, car sinon où irait-on, sans déterminisme identitaire ?). Néanmoins, l'absurde trouve à se loger dans l'espace de la non-contradiction, témoin cette longue simulation d'une restauration comme si la "source" et la "destination" avaient été validées a priori > pour déboucher sur un avortement de la restauration, parce que cette validation s'avère déficiente a posteriori.

L'« absurde » consisterait donc dans une « temporalité de l'échec » à l'intérieur d'un système logique identitaire autorisant une simulation provisoire de l'impossible.