Partition renommée automatiquement : impossible à monter

des alternatives à TimeMachine

Tu peux télécharger, installer et tester (démo gratuite un mois sans limitations fonctionnelles) ☞Carbon Copy Cloner☜. C'est un logiciel qui permet de faire une copie miroir démarrable du volume de l'OS sur celui d'un DDE, en clonant aussi en parallèle la «Recovery HD». Les sauvegardes passée la première sont incrémentales : elles n'impliquent que les différences présentes dans le volume de l'OS par rapport au clone du DDE.

Personnellement, je n'utilise que ce logiciel et n'ai jamais utilisé «TimeMachine». J'utilise un DDE : [SSD x Thunderbolt] comme support pour mon clone (et j'ai un SSD aussi dans mon Mac) => en incrémentiel, «CCC» met environ 2' à effectuer le re-clonage de mon OS (je n'ai jamais des volumes d'OS X chargés en données). J'opère un re-clonage incrémentiel par jour et je n'ai jamais eu besoin d'autre outil de sauvgarde. En cas de plantage de mon OS (il m'est arrivé assez souvent de le planter expérimentalement), je démarre sur mon clone et je lance un rétro-clonage à destination du volume de l'OS : temps de l'opération [SSD x Thunderbolt] du DDE => [SSD x SATA] du Mac = environ 2' itou...

Dans ces conditions : pourquoi se priver de panter son OS, si l'on trouve ça amusant ?
361608_original.png
 
  • J’aime
Réactions: Typhuss
pourquoi se priver de panter son OS, si l'on trouve ça amusant ?
361608_original.png
Je n'ai jamais vraiment eu de problèmes avec l'OS, c'est lorsqu'on en vient aux données que le souci se pose.
je n'ai jamais des volumes d'OS X chargés en données
Je comprends et j'ai tendance à faire pareil (c'est pour ça que mon DD interne a une partition pour l'OS et d'autres pour les données).
Mais de ton côté ton SSD interne te sert-il aussi pour les fichiers "de travail" ? Je pense notamment à des vidéos traitées dans iMovie, est-il plus judicieux de les avoir sur le disque avec l'OS si celui-ci est hyper véloce (SSD) ou les stocker sur une partition de ce DD interne ou un DDE SSD ? (quoique de mon côté je suis partout en UBS2)

Et pour CCC, outre l'intérêt de sauvegarder la partition avec l'OS, il y a aussi la sauvegarde incrémentale des données (stockées sur d'autres partitions ou disques)
Question sur CCC (mais peut-être faut-il ouvrir un post dédié ?, ou qu'avant je scrute davantage le forum d'ailleurs :bookworm:) : peut-il servir sur plusieurs DDE (pour avoir plusieurs copies de sauvegarde) ?
 
:coucou: Typhuss

Hé ! je m'avise n'avoir pas répondu aux demandes de ton dernier message...

J'ai moi aussi depuis lurette le réflexe de répartir OS et données sur 2 partitions de mon disque interne. Comme j'ai mis un SSD Crucial de 1 To à la place du HDD dans mon MacBook Pro 17" Late_2011, j'ai aussi tous les OS depuis «Snow Léopard», avec les «Recovery HD» collatérales à partir de «Lion», encore sur d'autres partitions du disque.

Il se trouve que les "données" que je stocke sur la partition dédiée (nommée Réserve) de mon SSD n'ont rien de « graphique ». J'y ai déporté la base de données de mon application de courrier «Entourage 2008» (comme tu vois, je me soucie comme d'une guigne d'être à la page), l'original remplacé par un lien symbolique ; et tout le reste consiste uniquement en documents de type « texte ». Photos, Musiques ou Vidéos : tout ça réside sur des DDE en ce qui me concerne, uniquement dans des dossiers créés a la mano (je n'utilise pas de logiciels-bibliothécaires, genre «iTunes» ou «Photos»).

Comme tu t'en doutes alors, je ne « travaille » jamais (ni en professionnel, ni en personnel) sur des données « graphiques ». Ce type de données, je me contente d'en collecter telles quelles, et de les "consommer" telles quelles... Je suis un homme du « texte » - exclusivement, activement parlant. Et des fichiers textes, ça ne pèse jamais lourd.

Si j'avais à gérer des données graphiques lourdes, je pense que j'exclurais leur masse de tout stockage sur mon disque interne. Je distinguerais probablement entre données "en réserve" et données "en travail". Les données en réserve, je les stockerais sur un ou des DDE, exclusivement. Les données "en travail", ça dépendrait : éventuellement recopier telle donnée graphique sur la partition de l'OS, ou la partition de stockage, du SSD interne, afin que les processus d'édition soient le plus véloce possible. Si, expérimentalement parlant, il s'avère qu'il y a pas mal à gagner à ce procédé.

Tu dis que tu es limité à l'USB-2. Ce qui implique que ton Mac est déjà assez ancien. S'il n'est pas antérieur à 2011, néanmoins, il doit être doté d'un port Thunderbolt. Pour tous les modèles de Macs à partir de 2011 et non dotés de l'USB-3, la connexion Thunderbolt est précieuse : elle fait absolument jeu égal avec la connexion SATA principale du disque du Mac. Dans ces conditions, il suffit d'avoir un boîtier Thunderbolt dans lequel on fourre un SSD, et la vitesse d'opérations depuis ce disque n'a rien à envier à celle d'un SSD interne. J'ai personnellement récupéré sur eBay des boîtiers Lacie Thunderbolt nantis d'usine d'un HDD, afin de les obtenir le meilleur marché possible, je les ai ouverts et j'ai remplacé le HDD par un SSD : c'est sur un tel DDE Thunderbolt x SSD que j'ai mon clone et ça va vite.

Pour ce qui est de «CCC», tu dois pouvoir créer plusieurs tâches séparées (dont la définition se conserve dans le panneau d'affichage du logiciel), consistant à cloner le même dossier (ou volume) de données chaque fois à destination d'un DDE distinctif. Si la "source" est un dossier, savoir que «CCC» clone les éléments enfants sans recréer sur la destination le dossier parent => dans ce cas, créer un dossier vide d'accueil, à l'intitulé ad hoc, et le donner comme "destination" à la tâche de clonage. Ces tâches distinctes s'exécutent l'une après l'autre, en les activant en manuel ; mais tu peux définir des règles de programmation, également (ce qui implique de laisser les DDE connectés au Mac).
 
  • J’aime
Réactions: Typhuss
Bonjour Macomaniac,

Merci encore de cette réponse !
Ta vision de gestion des fichiers graphiques volumineux concorde avec la mienne.
Pour compléter, iMovie (et surtout FinalCut Pro X) génèrent des fichiers internes/temporaires/de travail de taille absolument as-tro-no-mi-que (plusieurs Go pour quelques minutes de vidéo, et rapidement des dizaines de Go !!! mais générés où l'on veut, donc pas nécessairement sur la partition de l'OS) donc cette question de vélocité se pose. Actuellement je tourne sur un DD interne SATA "classique" (changé car le DD d'origine a planté - référence connue à l'époque de disques internes choisis par Apple bof bof).

Je vais déjà expérimenter via Firewire/Thunderbolt car j'ai un boitier Vantec qui fait du Firewire (mais le transfert depuis des DDE -non SSD donc- ne m'avais pas paru plus performant. A vérifier de plus près)
NB: j'ai un iMac de 2007 (qui tourne -bien- sous El Capitan) et un MacBook Pro de 2010 (resté sous Snow car Snow est pour moi le dernier OS "convivial" avant de basculer dans l'ère iOS décliné en OS, et j'y ai mes petites habitudes - notamment en traitant des vidéos, pour lesquelles la perte du QuickView de tous les formats vidéo (grâce à feu-Perian) est une régression majeure des OS récents).

Il me reste à acheter des SSD (le cap financier est pas évident à franchir, mais mes déboires avec les DDE vont finir par me convaincre que moins il y a de mécanique, mieux c'est).

recopier telle donnée graphique sur la partition de l'OS, ou la partition de stockage, du SSD interne, afin que les processus d'édition soient le plus véloce possible. Si, expérimentalement parlant, il s'avère qu'il y a pas mal à gagner à ce procédé.
Si j'abuse, une question subsidiaire pour finir (car l'informatique reste un monde obscur pour moi qui demeure dans la zone des utilisateurs) : pour des données "de travail" il n'existerait pas de différence (sous l'angle du traitement par l'OS) entre les stocker sur la partition de l'OS ou sur une partition "de réserve" du même disque ? ou si peu ?
 
:coucou: Typhuss

Pour ta dernière question : il n'y a aucune différence en terme d'efficacité, si les localisations sont sur des partitions différentes du même disque en connexion SATA. Pour le processus qui concerne un fichier nommé brol, que le chemin logique qui y mène soit /Users/typhuss/Movies/brol (partition de l'OS : la / initiale désigne toujours le point de montage du système de fichiers démarré de l'OS) ou /Volumes/Reserve/brol (partition de stockage supposée intitulée Reserve : la localisation initiale /Volumes/ désigne toujours le point de montage du système de fichiers non démarré d'une partition autre que celle de l'OS à l'intérieur de la localisation de l'OS dédiée à cette opération : le répertoire invisible des Volumes) - c'est du pareil au même.

Ton MacBook Pro_2010 ne bénéficie pas du Thunderbolt, mais seulement du Firewire. Dommage, car entre les deux, il n'y a pas photo : seul le Thunderbolt fait jeu égal avec le SATA du disque du Mac. J'ai donc un MacBook Pro 17" Late_2011 qui a le Thunderbolt, un SSD interne et un clone sur un SSD externe en connexion Thunderbolt : les 2 Systèmes (interne : OS X et externe : son clone) démarrent dans le même le temps, à la seconde près - c'est dire l'efficacité du Thunderbolt pour les Macs un peu anciens qui n'ont pas l'USB-3. En ce qui te concerne, tu es limité au Firewire 800 : c'est mieux que rien, mais un SSD externe connecté en Firewire 800 sera loin de faire jeu égal avec un SSD interne SATA.

Je te conseille de regarder les SSD Crucial 2,5 pouces. Si tu en prends un volumineux (1 To) pour remplacer ton HDD, tu n'auras plus de questions à te poser pour l'espace de travail de tes fichiers vidéo, si tu as une partition réservée aux données (temporaires même éventuellement) de 900 Go !
 
Salut à vous deux.

Il ne faut pas négliger la solution du Caddie qui permet de mettre sur un Macbook le SSD à la place du HDD et le HDD à la place du lecteur dvd qui lui même peut aller dans un boitier externe.
Les 2 interfaces étant à 3 Gbps, c'est une solution à ne pas négliger -> système sur le SSD (500 Go à 150 €) et données sur le HDD

@+
 
  • J’aime
Réactions: Typhuss
C'est vrai cette solution du Caddie (je ne savais pas qu'elle portait ce nom) je l'aie déjà vue.
A titre perso, elle viendrait en complément de celle évoquée par Macomaniac car les fichiers video sont traités sur l'iMac en raison de la taille de écran (même s'il est plus vieux, un 21" est plus confort qu'un 15"). Et oui, je lorgne évidemment sur un iMac 27"...
D'ailleurs que penser du "Fusion Drive" 1To proposé par Apple ?
 
C'est vrai cette solution du Caddie (je ne savais pas qu'elle portait ce nom) je l'aie déjà vue.
A titre perso, elle viendrait en complément de celle évoquée par Macomaniac car les fichiers video sont traités sur l'iMac en raison de la taille de écran (même s'il est plus vieux, un 21" est plus confort qu'un 15"). Et oui, je lorgne évidemment sur un iMac 27"...
D'ailleurs que penser du "Fusion Drive" 1To proposé par Apple ?
Attention les 1 To Fusion drive ont maintenant un SSD ridiculement petit : 24 Go http://www.macg.co/mac/2015/10/fusion-drive-la-derniere-pingrerie-dapple-91415
A éviter.
 
Oh ! en effet, j'avais en mémoire 256Go SSD + 1To... Oublions vite cette piste.
 
Bonsoir,
Petit point d'étape : macomaniac, j'ai suivi tes conseils en investissant dans un SSD 1To sur lequel j'ai cloné l'OS de l'iMac. J'en ai profité pour cloner l'OS du portable (Snow dont je n'arrive pas à me séparer, et que je vais garder encore grâce à ce clone)
Démarrage effectivement possible sous Capitan de l'iMac ou Snow du acBook depuis le SSD (encore externe) connecté au portable.

Prochaines étapes :
1. mettre le SSD dans l'iMac (je me tâte pour en profiter à remplacer une des 2 barettes de RAM 2Go par une de 4Go, pour passer à 6Go (2+4Go), le max réel de ce modèle d'iMac 2+4Go)

2. mettre aussi un SSD dans le MacBook et mettre en oeuvre la solution caddie de jeanjd63 (tout en en profitant pour passer de 2x2Go RAM à 2x4Go)

Bon week-end pascal à vous
 
:coucou: Typhuss

C'est sûr qu'un SSD métamorphose un Mac déjà ancien.

Avec un portable (MacBook Pro ou MacBook), la manipulation est enfantine.

Avec un iMac, déjà c'est plus coton (démontage de la vitre de l'écran) ; de plus : le HDD est un 3,5 pouces alors que le SSD destiné à le remplacer est un 2,5 pouces (donc prévoir un compensateur) ; enfin, il y a la question de la sonde thermique qui va se retrouver en ballade => je te renvoie à ce fil d'archive de MacGé pour que tu puisses cogiter à la question : ☞Astuce si vous souhaitez changer votre HDD☜ . Regarde aussi sur le site «iFixit» ici : ☞iMac Intel Repair☜ en allant à ton modèle et à la rubrique "Installation d'un SSD".
 
C'est marrant j'étais plus inquiet pour le changement du disque dans le macbook pro, parce que j'ai déjà changé celui de l'iMac (le 320G d'origine par un 1To "classique" il y a quelques années). Ton message m'incite davantage.

Et as-tu un avis sur l'upgrade mémoire vive ? Sur le MacBook je pense que ça vaut le coup de passer de 4 à 8Go lorsque la bébête est ouverte et le cout est raisonnable (env 60€+SSD), mais pour l'iMac qui a presque 10 ans, la barette 4Go seule vaut au moins 90€ et apporte-t-elle vraiment quelque chose en plus du SSD ?
 
PS: petit retour d'expérience du clonage de Capitan :
Au moment de créer le clone avec CCC sur le SSD, El Capitan ne me créait pas de partition "démarrable" je n'ai pas trouvé dans l'utilitaire disque comment faire, pas de "case à cocher" ni d'option spécifique. (j'utilisais -et utilise toujours- l'utilitaire disque de Snow Leopard qui fait ça automatiquement (du moins de manière transparente pour moi).
Une fois Capitan cloné, il ne bootait pas (démarrage+alt) :banghead:. J'ai donc lancé une installation de Capitan sur le clone ("par dessus" celle clonée, sans formater), et là ça marche en boot sur le SSD externe !

Ce qui me convainc que Snow est vraiment mieux (avec des micro-réserves car un peu ancien maintenant) : c'est qu'une partition créée via l'utilitaire disque de SL a pu accueillir le clone de SL en étant démarrable immédiatement ! (création de table GUID dans les 2 cas, mais résultats différents !)
Pourquoi l'utilitaire de SL crée des partitions démarrables et pas celui de Capitan ? (j'ai bien mon idée, mais c'est fou qu'Apple ait décidé de brider les fonctionnalités de cet utilitaire, indispensables aux "intermédiaires" comme moi qui ne sont pas hyper à l'aise avec Terminal, au risque d'y faire de fausses manip)
 
:coucou: Typhuss

J'avais négligé de te répondre...

Je ne saisis pas trop le problème que tu as rencontré sur ton SSD en ce qui concerne une « partition démarrable ». Le terme « démarrable » étant un mot "valise" (c'est-à-dire tant soit peu "fourre-tout"), permets-moi quelques précisions linguistiques à son sujet.

D'après ce que j'en conçois, une partition a le statut « démarrable » (sur un Mac Intel, précisons-le), si 3 conditions se trouvent réunies :

- a) la partition doit être « amorçable » pour l'EFI. (EFI = le Firmware de la Carte-Mère ou Programme Interne du Mac). Càd. que l'EFI doit pouvoir « accéder » logiquement au secteur du disque concerné. Pour cela, la Table de Partition du disque en question doit être strictement conforme au schéma GUID (Globally Unique IDentifier), càd. comporter sur son secteur d'amorçage qui est le secteur 0 une série de descripteurs logiques du disque (liste de blocs, secteurs de blocs = partitions...) lisibles pour l'EFI. De surcroît, la partition concernée (secteur de blocs de la Table GUID) doit elle-même inclure un système de fichiers au format standard Apple JHFS+ (Mac OS étendu journalisé). Ce système de fichiers constitue l'en-tête de la partition : ce sont des fichiers de type : catalogue B-tree, fichier des attributs_étendus... qui gèrent les blocs du secteur de la partition pour les opérations de lecture / écriture. En résumé : l'EFI doit pouvoir lire la table de partition pour suivre un chemin au secteur de démarrage, et lire le système de fichiers d'en-tête de la partition pour suivre un chemin au fichier de démarrage.

- b) la partition doit être « exécutable » pour l'EFI. Càd. que les fichiers écrits sur les blocs de la partitition doivent constituer un Système lançable, et pas consister en simples données de stockage. Il faut donc l'architecture de fichiers d'un OS. Ce qui, en bref, implique un « démarreur », un « moteur » et un « mécanisme ». Le démarreur est un fichier boot_loader : boot.efi. Le moteur est un micro-noyau de type kernel, qui se trouve implémenté de pilotes du hardware (extensions du kernel ou kexts). Le mécanisme est un Système Logiciel en mouvement, càd. une combinaison de processus tournant en continu (le processus parent launchd...) par rapport auxquels une session graphique d'utilisateur est un effet terminal. En résumé : le système de fichiers de la partition doit gérer une architecture de fichiers-Système.

- c) la partition doit être « choisissable » pour l'EFI. Càd. qu'au démarrage du Mac par le bouton d'allumage (qui lance le Programme Interne du Mac), l'EFI doit pouvoir disposer d'une instruction de direction à tel disque, tel secteur de disque, tel fichier démarreur de Système. Pour cela, l'EFI dispose d'un petit programme auxiliaire : le DiskManager (capable de scanner les volumes montés des disques attachés au Mac en vue de repérer ceux qui contiennent un Système exécutable), qui se lance quand on appuie sur la touche "alt" au boot. Mais à quoi le DiskManager va-t-il reconnaître si une partition recèle un Système exécutable ou non ? Au fait qu'un flag "démarrable" se trouve fixé sur l'en-tête des partitions recélant un OS, assorti du PATH au fichier démarreur boot.efi (lequel resterait enfoui sinon dans l'arborescence des fichiers-Système de la partition at: /System/Library/CoreServices/boot.efi et serait non-répérable). Ce flag "démarrable" et ce PATH au boot.efi sont fixés sur l'en-tête de la partition recélant un Système par un procédé qui s'appelle "bénédiction" (blessing). Tout installateur d'un OS "bénit" l'en-tête de la partition-Système en fin d'installation ; mais tout cloner de bon aloi en fait autant par une commande ad hoc en fin de clonage. Dès que tel volume identifié par le DiskManager comme recélant un Système exécutable est choisi (à l'écran de choix du disque de démarrage), l'EFI qui était en "stand-by" accède au disque par le secteur d'amorçage, accède à l'en-tête de la partition correspondante, lit et suit le PATH au fichier démarreur et exécute le boot.efi en bout de chemin logique (en lui passant des tas de flags éventuellement récoltés dans la NVRAM). Cela fait, elle quitte en tant que programme et le boot.efi démarre le kernel.

Lorsque le choix est fait d'un démarrage automatique sur une partition, alors une instruction de type "efi-boot device" est écrite en NVRAM, mentionnant l'UUID de la partition de boot automatique à laquelle l'EFI accèdera directement, et sur l'en-tête de laquelle elle doit pouvoir trouver le PATH à suivre pour accéder au boot.efi à exécuter.​

=> par rapport à ce descriptif des 3 conditions qui font qu'une partition est « démarrable » (amorçable, exécutable, choisissable), il est clair que l'utilisateur doit s'arranger à l'avance pour avoir une partition « amorçable » sur son disque (table GPT + format JHFS+ du système de fichiers de la partition). Qu'il lui faut installer dans la partition les fichiers-Système d'un OS sans lacune "mécanique", pour qu'elle soit « exécutable ». Enfin, que l'en-tête de la partition soit bien "béni", pour que la partition soit « choisissable ». «Carbon Copy Cloner» gère impeccablement les 2 dernières conditions (clonage d'un Système exécutable, bénédiction de la partition), mais c'est à l'utilisateur de créer la première condition (caractère amorçable = GPT + format JHFS+).
 
Dernière édition par un modérateur: