OS X El Capitan permet aux outils de sauvegarde d'optimiser leurs clones
Mike Bombich, l'éditeur de Carbon Copy Cloner, aborde une problématique apparue avec El Capitan qui touche tous les logiciels de sauvegarde et clonage de disques durs comme le sien (lire aussi SuperDuper s’accommode mal d’OS X El Capitan). Dans un billet publié la semaine dernière, il rassure d'abord ses utilisateurs quant à la compatibilité de son logiciel avec le prochain El Capitan, une version bêta est à disposition (lien en fin de page).
Cependant, Apple a instauré un nouveau mécanisme de protection qui a quelques conséquences sur les clones de disques réalisés avec Carbon Copy Cloner et ses concurrents. Cela se traduit par des temps de démarrage du système et de lancement des applications augmentés d'une manière qualifiée de « modeste » lorsqu'ils sont exécutés depuis le volume de sauvegarde.
La faute en incombe à une nouvelle fonction baptisée "System Integrity Protection". D'une part, elle veille à ce que certains dossiers clefs ne puissent plus être manipulés à tout bout de champ par les utilisateurs, même titulaires d'un statut d'administrateur ou de super utilisateur. D'autre part, et c'est là le nœud du problème pour l'éditeur, un nouvel attribut — "com.apple.rootless" — est associé à certains dossiers système par l'installeur d'OS X El Capitan. Les contenus de ces dossiers sont gérés par le cache du noyau d'OS X et ils profitent de délais de lancement réduits à la suite d'une optimisation réalisée automatiquement.
Cependant, les logiciels comme CCC n'ont pas la possibilité de réinstaurer cet attribut après avoir cloné ces dossiers. Ils continuent de faire des copies parfaites des fichiers et dossiers mais sans ce petit plus de l'optimisation. Le clone sera donc un peu plus lent lorsqu'on s'en sert depuis le volume de sauvegarde.
Mike Bombich explique que l'on peut d'ores et déjà pallier cette lacune en installant, quand on le souhaite, OS X El Capitan sur son disque de sauvegarde. L'installeur ne touchera pas vos fichiers qui y sont sauvegardés, mais en prenant la place du système cloné précédemment il en profitera pour faire son travail d'optimisation. Puisque CCC est capable ensuite de ne remplacer que les fichiers qui ont été modifiés depuis la dernière sauvegarde, ces attributs resteront en place.
Ce qu'espère Bombich maintenant c'est qu'Apple assouplisse le mécanisme de cette fonction. En accordant à certains éditeurs triés sur le volet le droit d'affecter cet attribut au travers de leurs logiciels au moment du clonage. Les développeurs d'extensions pour le noyau d'OS X peuvent déjà obtenir de telles dérogations. Et qu'aussi, l'utilisateur final dispose d'une option pour autoriser une application à procéder ainsi.
[MàJ le 14/07] : l'éditeur de SuperDuper a constaté que la dernière bêta d'OS X rectifiait le problème décrit ci-après et permettait à nouveau de cloner un volume sans perdre le nouvel attribut système "com.apple.rootless".
Question, si la copie est bien parfaite, mais il y a seulement un problème de droits si on lance directement la sauvegarde, dans ce cas si on utilise la sauvegarde durant une nouvelle installation de Mac OSX pour importer nos anciens fichiers, paramètres et applications, dans ce cas tout fonctionne correctement, c'est juste ?
C'est pour m'organiser car j'ai 6 disques dur de sauvegarde où je clone tout régulièrement est je voudrais être sûr que je pourrais bien tout récupérer si j'ai un jour un problème...
Merci !!! :0)
Vous pourrez toujours tout récupérer.
Ok super, merci !!
@nifex
Telle que décrite la situation va surtout poser des problèmes a ceux qui utilisent le clonage pour répliquer une installation sur un parc de machines. Par exemple un administrateur qui peaufine une installation sur une machine de test puis lorsqu'il la juge bonne replique le disque sur n machines.
Pour le backup, qu'il soit complet ou incremental, il s'agit des fichiers modifiables par l'utilisateur (avec ou sans les droits administrateurs) et la pas de soucis.
Donc y deux catégories qui sont concernes par le systeme de protection d'Apple:
- les administrateurs de parcs
- les testeurs.
Pour les testeurs (développeurs, chercheurs en sécurité, beta testeurs, hacker,...) la solution c'est en partie de faire une installation identique entre la machine de "travail" et le disque de sauvegarde (la on va regretter amèrement la disparition de firewire...). Ensuite la fonction de réplication des softs mentionnés va opérerer sans pb.
Reste le souci pour les administrateurs de parc. La Apple va devoir proposer quelque chose, parce qu'il est évident qu'un admin va pas changer une procédure qui est efficace, certifiée et qu'il va surtout pas s'amuser a traiter n machines individuelement...
Reste une solution: la prise en charge de la replication par Utilitaire disque. Ce serait assez logique, Apple propose déjà un système de versionning performant avec Time Machine, et doter Utilitaire disque d'une fonction de réplication serait le complément qu'Apple aurait du faire depuis longtemps. Et évidemment, cela doit pouvoir se faire a destination d'un disque, d'une image disque et en local comme en réseau...
Cela implique bien évidemment la fin des utilitaires comme Carbon Copy Cloner et Super Dumper, mais leurs existence est la cause des manquements de l'OS d'Apple. Si Apple améliore sont OS, plus la peine de compenser les manques...
en relisant l'article deux fois, je crois comprendre que oui, en faite ce qu'il ne peu pas faire c'est restaurer les fichiers protégé, par contre il peu parfaitement restaurer les fichiers modifié excepté évidemment les fichier de mac os 10.11, bref c'est beaucoup de travail pour finalement, du moins pour le moment pas grand choses.
en même temps avoir un clone de son disque c'est plus sécurisant que pas de clone du tout.
Ce sont des systèmes mis en place pour la sécurité des machines. Si Apple commence à laissé des passe droit à droite et à gauche à quoi cela va t-il servir ? Il suffira de se faire passer pour un des dev pour plomber la machine.
Je comprends la demande du dev de CCC que j'apprécie grandement, mais je ne suis pas d'accord avec sa conclusion.
@Nesus
+1
C'est comme les imbécilités dont nous abreuvent les proto dictateurs genre Cameron et les (ir)responsables des agences de sécurité qui réclament l'interdiction d'un vrai chiffrement des logiciels de communication.
S'il y a une porte, c'est une faille et une faille c'est une porte d'entrée pour n'importe qui.
Ceci dit, le système d'Apple ressemble dans son principe a ce qui se faisait majoritairement pour les DRM et les plombages de progiciels il y a quelques années.
Toutes ces "protections" ont été cassées!
Meme les systemes de serialisation utilisant le matériel (en particulier les disque dur) ou des "dongles" ont été contournes.
Va falloir voir comment la réalisation d'Apple va résister.
Donc si on reclone son système pour le restaurer, il faudra en plus réinstaller OS X pour retrouver cette optimisation que seul l'installer d'OS X est autorisé à faire.
Sinon on aura un système fonctionnel mais un peu plus lent...
Et personnellement je ne pense pas qu'Apple autorise CCC de Mike Bombich à re attribuer ces attributs sur le fichiers protégés du système.
(Apple n'a jamais autorisé CCC, pas plus que SuperDuper, sur le Mac AppStore...)
On est mal parti s'ils suivent cette ligne.
Moi si je n'ai pas un CCC parfaitement opérationnel sous El Capitan et bien je ne mettrai pas à jour mon système vers El Capitan, c'est aussi simple que cela. CCC c'est ma bouée de sauvetage. Combien de fois il m'a sauvé de la catastrophe...
C'est terrible : au fur et à mesure que les années passent, apple enlève tout doucement TOUT ce qui faisait l'intérêt de se servir de mac OSX.
Petit à petit.
C'est insensible, mais c'est inéluctable.
Que faire ?
Au fait, il y a moyen, sous ElCapitan, de désactiver cette protection inutile et contraignante pour un monoposte d'utilisateur très averti ? (et utilisateur régulier de SuperDuper)
@pecos
Depuis le premier Macintosh Apple a fait de son credo: "s'adresser a des populations qui voulaient utiliser l'informatique sans devoir être des informaticiens".
Et son objectif a toujours été de populariser l'informatique, donc pas de se limiter aux populations professionnelles de l'informatique.
L'utilisateur de Mac, c'est la secrétaire, le manager, le professeur, l'étudiant, le scientifique, l'écrivain, le graphiste, le designer, le rédacteur, le journaliste, le photographe, le musicien,... bref les créatifs, utilisateurs lambda, qu'ils soient professionnels ou pas.
En relisant l'histoire d'Apple, on se rend compte que le Mac a été des le départ une "black box" masquant sous une interface conviviale et "skeumorphisée" la complexité de l'ordinateur, au point meme qu'au départ il faillait une autre machine pour créer des logiciels pour le Mac: le Lisa!
Apple vend plus de 50 millions d'iPhone/iPad par trimestres. Dans le meme temps elle vend moins de 10 millions de Mac.
L'utilisateur d'Apple c'est l'utilisateur d'iPhone et d'iPad.
Le power user, l'informaticien, le technicien c'est pas l'utilisateur qui a du poids chez Apple. Pour ces catégories, y a le monde Linux, et Linux en desktop c'est moins de 2% du marche...
Apres il y a aussi les bidouilleurs, les geek, les nerds,... et ce qui est clair depuis 1983 c'est que cette population ne considère pas Apple, et c'est réciproque. Pour eux il y a Linux, Arduino, Raspberry et le PC en kit.
Aujourd'hui on peut reprocher a Apple les problèmes de stabilité et de non optimisation de ses OS, l'inconsistance de son interface - qui se complique et devient moins ergonomique et esthétique-, l'obsolescence des fichiers (suite iWork par ex)... mais on peut pas reprocher ni la fermeture des machines ni celle du logiciel.
Teint ce serait intéressant de voir avec une copie "bit à bit" ou avec une commande du type "dd if= disk0 of=fdisk1" ce qui se passe niveau rapidité du système si on se fait couiller ou pas...
Ça m'étonnerait fort que ça marche.
Sous OSX, comme avec toutes les versions de Mac OS, les fichiers et dossiers sont identifiés par un identifiant unique et pas par leur chemin.
C'est ce qui permet d'avoir un système d'alias très performant, notamment, de ne pas endommager un alias quand on déplace l'original dans un autre dossier du même volume (donc sans le copier sur un autre volume).
(bien entendu ceci ne s'applique pas aux liens UNIX)
Je peux me tromper mais je subodore que ça va empêcher une copie bit à bit de fonctionner comme tu l'imagine : comme les couples "id du fichier - id du volume" ne seront pas identiques entre l'original et la copie (en effet l'ID du disque changera par rapport à l'original), l'OS verra que c'est une copie.
C'est une manière de voir la supercherie.
Il y en a sans doute d'autres auxquelles je n'ai pas pensé.
"elle veille à ce que certains dossiers clefs ne puissent plus être manipulés à tout bout de champ par les utilisateurs, même titulaires d'un statut d'administrateur ou de super utilisateur."
Là, sous le prétexte habituel de nous protéger, du pour notre sécurité, Apple par dans une dérive ou bientôt l'on ne contrôlera plus rien, comme sur iOS, voir pire. Le tout sous les applaudissements de certains.
@ Orus
+1
"Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité ne mérite ni l'une ni l'autre, et finit par perdre les deux."
Benjamin Franklin
"... Là, sous le prétexte habituel de nous protéger, du pour notre sécurité, Apple par dans une dérive ou bientôt l'on ne contrôlera plus rien, comme sur iOS, voir pire. Le tout sous les applaudissements de certains."...
Le tout sous les applaudissements de certains... Ben oui, et ceux là s'obstinent à vouloir y croire, envers et contre tout. C'est évident pour de + en + de gens, mais non, ce sont les raleurs de service qui se remettent a beugler...
Enfin ! Au pays des boiteux beaucoup pensent qu'ils marchent droit.
Pour l'instant j'ai dû abandonner SuperDuper! (passage à El Capitan). Voici ma démarche de substitution concernant le clonage:
- installation propre de El Capitan, et sur le Master, et sur le Clone
- installation des logiciels sur les deux
- les diverses mises à jour ultérieures des logiciels sont à faire en double, et sur le Master, et sur le Clone
- les documents je les synchronise entre le Master et le Clone avec SyncTwoFolders (dont le développeur mérite bien une donation).
http://synctwofolders.fr.softonic.com/mac (téléchargement)
http://throb.pagesperso-orange.fr (son site perso)
Job done.
La nouvelle beta de CarboncopyCloner fonctionne parfaitement avec ElCapitan au détail de ce que décrit Mike Bombich (les dossiers "protégés" qui ne sont plus tagués comme tel et du coup ca empêche l'optimisation du système)
Il "suffit" une fois un premier clone effectué, de réinstaller dessus ElCapitan, pour que ces dossiers protégés soient à nouveau targués correctement.
Les clones suivants mettent à jour les fichiers modifiés et les fameux dossiers n'étant par définition JAMAIS modifiés ils restent proprement tagués. Le clone est donc parfait et fonctionnel.
Le seul soucis c'est que si on veut recloner en sens inverse pour restaurer son disque principal, il faudra penser une fois le reclonage fait, à réappliquer l'installer d'ElCapitant pour retagguer les dossiers en questions. C'est tout
C'est juste un peu plus long
BONNE NOUVELLE!!!
Mike vient d'actualiser sa page et écrit:
Update [July 14, 2015]
The good folks at Apple responded to my request to allow third-party developers the privilege of writing the "com.apple.rootless" extended attribute. Yea! They addressed this in the Beta 3 release of OS X 10.11. Backups with CCC 4.1.4 will make a fully optimized, bootable copy of your El Capitan installation.
Donc à partir de la beta3 d'ElCapitan, CarbonCopyCloner 4.1.4 fera des clones parfaits car il pourra attribuer le bon attribut "com.apple.rootless" aux fichiers système protégés.
c'est quand meme pathétique que dès que l'on met un commentaire qui ne plait pas, on se fait ban.
Au journalistes: bande de charlots, changez de métier . Il y a des gens compétents qui ne demandent qu'a travailler. Laissez votre place. On manque de main d'oeuvre dans la voirie. avec un pic et une pioche, vous serez probablement moins lamentables.
Mais à la redaction, vous lisez les mails qu'on vous envoie???
Je vous ai signalé hier soir que Mike Bombich a actualisé sa page pour indiquer que la beta 3 d'El Capitan permet aux éditeurs tiers de réaffecter le bon attribut com.apple.rootless sur les fichiers système protégé
Nota: il faudra qu'un utilitaire comme Batchmod soit mis à jour pour gérer ce nouvel attribut...
Ne nous énervons pas surtout, ça n'en vaut pas la peine.
Surtout que la solution à tout ça est très simple sous ElCapitan :
sudo nvram boot-args="rootless=0"
sudo reboot
C'est radical mais je pense que je me laisserai tenter.
Après je pense que ni SuperDuper ni CCC n'auront de soucis pour réaliser un clone potable.
euh.... j'ai l'impression de parler dans le vide, non?
Il n'y a PLUS de problème!
La béta 3 d'El Capitan permet aux éditeurs tiers de réaffecter cet argument com.apple.rootless aux fichiers le nécessitant.
Inutile de désactiver cette protection et OUI SuperDuper et CCC peuvent réaliser un clone bootable (ça elles l'ont toujours pu) ET optimisable par le système (inutile de parler au futur)
"euh.... j'ai l'impression de parler dans le vide, non?"
Ça vous étonne ? :)
Curieusement, les bonnes nouvelles font moins sensation que les mauvaises, mais surtout, elles ne permettent pas de se vider de sa mauvaise humeur du jour.
"Les bonnes nouvelles fond moins sensation..."
ou elles fondent plus vite ;-)
Sur ce sujet, la mise à jour de l'article devrait être à l'image de ce qu'à publié Mike Bombich en tête de son blog après avoir informé de la bonne nouvelle:
Please note that the content below this line is no longer relevant, Apple fixed the bug
""Les bonnes nouvelles fond moins sensation..."
ou elles fondent plus vite ;-)"
merci :)
Pas tout à fait : certes, les éditeurs de softs de sauvegarde vont pouvoir les mettre à jour et peut-être cette solution fonctionnera à long terme.
Peut-être.
Mais la présence de rootless empêche toujours de faire une sauvegarde d'une partition ElCapitan depuis un ancien système (Snow, par exemple) équipé d'une vieille version de SuperDuper.
Jusqu'à Yosemite, ça marchait très bien.
C'est ce que je fais souvent et je pense sérieusement qu'il est vital de se débarrasser de ce rootless tant qu'on le peut.
D'où les commandes terminal que je donnais plus haut.