John Siracusa

Time Machine

Time Machine est la meilleure des nouvelles caractéristiques de Léopard, peut-être la meilleure de toutes celles jamais ajoutées à Mac OS X. D'un mot, Time Machine est un système de sauvegarde et de récupération que les gens vont utiliser réellement. Il coupe efficacement le nœud gordien d'un très vieux dilemme de la sauvegarde pour les utilisateurs : "Je sais que je devrais faire une sauvegarde, mais je ne le fais jamais. Je ne saurais même pas comment faire cela, de toute façon". Et bien, assez de ce discours. Si vous avez plus d'un disque dur associé à votre Mac, c'est plus difficile de ne pas utiliser Time Machine que de l'utiliser.

Time Machine

Dialogue de sélection de sauvegarde

La première fois que deux disques ou plus sont connectés à un Mac sous Léopard, une boîte de dialogue apparaît demandant à l'utilisateur de choisir un disque de sauvegarde. Choisissez-en un, et c'est fini ; vous n'avez besoin de rien faire d'autre. Si vous vous aventurez sur la vitre de préférences de Time Machine, vous verrez cet affichage bien organisé.

Time Machine préférences

La vitre des préférences de Time Machine

L'énorme bouton ON/OFF, domine l'écran (des réminiscences du contrôle de l'iPhone "glisser pour déverrouiller", bien sûr). Il n'y a que deux autres contrôles : Changer de disque, et Options, qui fait apparaître ce dialogue :

Options de sauvegarde

Cela se comprend tout seul, et les options par défaut sont assez intelligentes pour que personne n'aie jamais besoin de savoir que ces écrans existent.

Les bénéfices de Time Machine se revèlent de deux façons importantes. D'abord, si votre disque dur principal tombe en panne, ou est remplacé, redémarrer avec le DVD d'installation va permettre de restaurer le système à l'état de la dernière sauvegarde de Time Machine. Ensuite, quand on affiche n'importe quelle fenêtre dans le Finder, lancer un mode spécial va montrer le contenu de cette fenêtre à tous les moments du passé pour lequel la sauvegarde existe. Les fichiers peuvent être récupérés dans un état passé, et remplacer les incarnations courantes, ou coexister avec elles.

Cela est si simple que c'en est ennuyeux, mais c'est là qu'est le trait de génie. Apple a examiné les habitudes de sauvegarde de ses consommateurs avant de créer Time Machine. 80 % des utilisateurs de Mac disent qu'ils savent qu'ils devraient faire une sauvegarde de leurs données. (C'est effrayant d'ailleurs : seulement 80 % ?). 26 % disent qu'ils sauvegardent effectivement. Cela ne semble pas trop mauvais, jusqu'à ce que vous arriviez à la question suivante. Seulement quatre % sauvegardent régulièrement.

En résumé, cela veut dire que si vous pouviez claquer des doigts, et faire disparaître le disque dur d'un utilisateur de Mac, il y a 96 % de chances que vous allez détruire des fichiers qui sont entièrement irrécupérables. Avec de plus en plus de données personnelles irremplaçables stockées sur les Macs (photos de famille, vidéos), ce serait irresponsable de la part d'Apple de ne pas répondre au problème, d'une façon ou d'une autre.

J'ai entonné ce refrain il y a quelques années, en y arrivant par le côté matériel, en suggérant à Apple de mettre au moins deux disques durs dans chaque Mac. Dans Léopard, Apple a abordé le problème d'une autre façon, en éliminant les difficultés logicielles, et en comptant sur les utilisateurs de Macs pour fournir un second disque.

Dans le contexte, c'est une solution plus pratique. Les utilisateurs de Macs sont beaucoup plus susceptibles d'acheter et d'installer un disque complémentaire, que de naviguer dans les arcanes d'un logiciel de sauvegarde de leur cru, un logiciel qui peut leur coûter aussi cher qu'un disque dur, de nos jours.

Et, cerise sur le gâteau, Apple a même rendu la récupération de fichiers amusante. Cela commence par l'icône de Time machine qui est installée par défaut dans le Dock.

Time Machines

L'icône de Time Machine

Cliquez dessus, et toutes les fenêtres vont disparaître de l'écran, sauf la fenêtre du Finder la plus au dessus, faisant apparaître une nébuleuse tourbillonnante dans un champ d'étoiles en mouvement dans lequel se perd une succession d'incarnations historiques de la dernière fenêtre restante du Finder.

Le mode Time Machine

Le mode Time Machine (réduit à cause de contraintes de place). Voir plus d'images

Cœurs inutilisés

à gauche, le bouton Annuler ; à droite, l'espace temps

Des flèches et des boutons complètement hors standards sont utilisées pour naviguer, et pour restaurer les fichiers. Une ligne du temps à droite monte chaque sauvegarde comme un tiret, et les marques s'agrandissent quand la souris passe dessus, à la manière de l'agrandissement du Dock. Tout ça est complètement ridicule, eh bien savez-vous ? j'en raffole !

Je veux bien excuser Apple quand elle en arrive à ces embellissements pour deux raisons. La première, aucun de ces enfantillages ne rend les caractéristiques moins utilisables. Oui, ces flèches sont idiotes, mais ce sont aussi des cibles assez grosses pour cliquer dessus, et elles ont une signification claire. Même chose pour les boutons. La seconde raison, et la plus importante, c'est que Time Machine est conçue de telle façon qu'il est facile -et même trivial en fait- pour des développeurs indépendants, de créer leur propre interface pour gérer les données sauvegardées. Ce qui nous amène à ... >

L'aspect interne de Time Machine

Les sauvegardes sont stockées dans un dossier appelé Backups.backupdb au niveau supérieur du disque sélectionné comme dépositaire de Time Machine. Dedans, il y a un dossier avec le nom de l'ordinateur (tel qu'il est défini dans la vitre partage des Préférences Système), qui contient un ensemble de dossiers estampillés par la date (AAAA-MM-JJ HHMMSS), dont chacun contient un dossier au nom du volume sauvegardé. Voilà un exemple

listing de sauvegarde

La "base de données" d'une sauvegarde Time Machine

Dans le cas ci-dessus, le nom de l'ordinateur est "Léopard" et le nom du disque dur est "Leopard Demo". Chaque dossier "Leopard Demo" contient le contenu complet du volume tel qu'il existait à l'heure indiquée dans le dossier parent.

Attendez une seconde, le contenu complet ? Voyons, il y a 10 dossiers estampillés par la date, chacun contenant un dossier "Léopard Demo". Est-ce que cela signifie que le disque de sauvegarde est au moins dix fois plus gros que le volume Léopard Demo ? Heureusement, non. Time Machine est un peu plus maligne que ça.

Quand elle crée une nouvelle sauvegarde estampillée dans le temps, Time Machine ne copie pas tout fichier qui n'a pas été modifié depuis la dernière sauvegarde. C'est la même chose pour les dossiers ; Si tous les fichiers d'un dossier donné n'ont pas été modifiés, le dossier entier n'est pas copié.

Et cependant, ils sont tous là. Si vous naviguez dans l'un de ces dossier "Leopard Demo", vous voyez chaque fichier individuel. pas d'alias, pas de liens symboliques, les fichiers eux-mêmes.

Contenu de sauvegarde

Le contenu complet du disque dans chaque sauvegarde.

Enfin, à peu près. Dans mon compte rendu de Tiger, j'avais inclus une explication des permissions de fichiers Unix. Pour comprendre ce que fait Time Machine, vous devez d'abord connaître quelque chose à propos d'une autre caractéristique standard d'Unix ; les liens symboliques et les liens matériels. C'est quelque chose de très simple pour quelqu'un qui a une expérience Unix, mais j'ai reçu un tas de réactions positives à propos de mon tutoriel sur les permissions Unix, si bien que j'espère que vous allez m'autoriser une petite digression. Vous pouvez passer cette section si vous connaissez déjà ça.

Liens symboliques et liens matériels

Mac OS avait inclus la possibilité de créer un "alias" d'un fichier depuis le System 7. Les alias sont des petits fichiers complets dont le contenu est interprété par le Finder et les autres APIs de Mac OS, ce qui permet de retrouver le fichier original. Mais pour le cœur de l'OS, dans Mac OS X, les alias n'ont aucune signification. Ce sont tout juste des petits fichiers complets. (En fait, leur taille est montrée à zéro, parce que toutes les données sont dans la fourche ressource). La première partie de cette leçon, c'est que les alias n'ont absolument rien à voir avec les liens symboliques, ou les liens matériels.

Pendant des décennies, Unix a disposé de deux manières de faire ce que font les alias : les liens symboliques, et les liens matériels. Un lien symbolique, aussi appelé symlink est un pointeur sur un autre fichier. La localisation de ce fichier est spécifiée en utilisant un chemin absolu ou relatif dans une chaîne de caractères. Les liens symboliques sont créés avec la commande ln en utilisant l'option -s. En voici un exemple.
listing

Comme c'est indiqué par le "l" en tête de ligne dans la chaîne des permissions Unix, mysymlink est un lien symbolique. Il pointe sur myfile que la commande ls montre à droite de la petite flèche en ASCII. Notez que le lien symbolique est tout petit : six octets. Ce n'est pas une coïncidence. Les liens symboliques sont stupides, dans la mesure où ils ne contiennent exactement rien d'autre que le chemin du fichier cible sous forme d'une chaîne de caractères. Ici, la chaîne est un chemin relatif, "myfile" qui (surprise) a exactement 6 caractères de long.

Si je déplace mysymlink vers un répertoire entièrement différent qui se trouve contenir aussi un fichier myfile alors, le lien symbolique va pointer sur ce nouveau fichier. Si j'efface myfile, le lien symbolique va rester, et contient la même chaîne de caractères pour désigner un chemin qui ne mène plus à aucun fichier. Observez ceci :
listing

L'erreur renvoyée prête à confusion. Le fichier mysymlink existe toujours. Mais quand le système d'exploitation tente d'ouvrir ce fichier, il suit consciencieusement le lien symbolique, et trouve qu'il n'y a pas de fichier pour le chemin défini par le lien. La commande cat renvoie alors l'erreur qu'elle a trouvée en tentant d'ouvrir le fichier qu'on lui a dit d'ouvrir.

Cette propriété des liens symboliques peut aussi être considérée comme une caractéristique dans certaine circonstances : "simple", plutôt que "stupide". Mais parfois, on a besoin de quelque chose de plus robuste. Et voilà les liens matériels.

Un lien matériel est seulement une référence à des données sur le disque. Pensez à un fichier comme une combinaison de son nom, et d'un pointeur sur des données. Effacer un fichier, signifie en fait, effacer la partie nom de ce duo. Quand il n'y a plus de noms pointant sur des données particulières d'un disque, alors, cet espace disque peut être réutilisé.

La plupart des fichiers n'ont qu'un seul nom. En fait, chaque fichier complet est un lien matériel. Reprenons le fichier myfile du premier listing ci-dessus.
listing

Vous voyez ce nombre "1", à droite, juste avant le nom "john" ? Cela indique que les données associées au nom myfile n'ont qu'un seul nom. Autrement dit, supprimer myfile va mettre le compteur à zéro, et permettre de réutiliser l'espace du disque préalablement occupé par myfile pour d'autres fichiers. Notez que créer un lien symbolique n'augmente pas ce nombre.
listing

En fait, le lien symbolique lui-même a un "1" dans cette colonne, pour indiquer qu'il n'y a qu'un seul nom lié à ces six octets de données. Maintenant, créons un lien matéreil, toujours à l'aide de la commande ln, mais cette fois, sans option.
listing

Maintenant, le nombre de liens pour myfile et myhardlink est de 2. Cela signifie que les données liées par myfile ont deux noms, et que celles liées par myhardlink ont aussi deux noms. Dans ce cas, deux liens vers les mêmes données. On n'a aucun moyen de savoir ça simplement en regardant le nombre sur le lien. On le sait, simplement parce qu'on vient de lancer la commande ln.

Bien que la taille de myfile et de myhardlink soit listée à 894 octets, ces 894 octets n'existent qu'une seule fois sur le disque. Encore une fois, c'est un paquet de données qui a deux noms. Pour l'OS, ni myfile, ni myhardlink n'est le fichier "réel". Ils sont tous les deux réels, aussi réel que l'un ou l'autre serait si le nombre de liens était un ou lieu de deux.

Comme ces deux fichiers sont associés aux mêmes données, une modification des données sera reflétée dans chacun des fichiers. Par exemple, ajoutons 5 octets au paquet de données lié par myfile (le mot "test" plus le caractère new line)
listing

Maintenant, voyez le résultat :
listing

Les tailles de myfile et de myhardlink sont maintenant de 899 (894 + 5). et pendant de temps, mysymlink est encore le seul nom lié à ses six octets de données, et contenant la chaîne "myfile".

Retour à Time Machine

Bon, la digression est finie. Revoyons le mystère des dix copies apparemment complètes du volume "Leopard Demo" dans le dossier Backups.backupdb de Time Machine. Comme vous devriez l'avoir compris maintenant, Time Machine utilise des liens matériels pour les associer de façon répétée à une seule instance d'un paquet de données sur le disque. En voilà un exemple :
listing

Et là, vous l'avez : le "10" à côté du mot "root" indique qu'il y a 10 noms associés aux données auxquelles mach_kernel est lié. Les données n'existent qu'une seule fois sur le volume de sauvegarde de Time Machine. Cette disposition est répétée pour chaque fichier qui n'a pas été modifié depuis la dernière sauvegarde.

Time Machine fait un pas de plus. Historiquement, Unix a toujours associé les liens matériels à des fichiers. Dans Léopard, Apple a rajouté la possibilité de faire des liens matériels à des répertoires. Cela n'était pas autorisé sous Unix parce que cela peut entraîner toutes sortes de vilaines boucles infinies pendant les recherches de fichiers. Bien sûr, les liens symboliques peuvent aussi créer des boucles, mais elles sont plus facile à détecter et à prévenir parce que les liens symboliques peuvent être facilement différenciés des fichiers normaux. Mais comme on l'a dit précédemment, tout fichier est par essence un lien matériel, et tous les liens matériels ont une position équivalente aux yeux de l'OS, ce qui rend la détection de boucles plus difficile.

Néanmoins, les bénéfices, pour Time Machine furent suffisamment substantiels pour qu'Apple ajoute (avec précaution) cette possibilité à Léopard. Par exemple, si tout le répertoire /System n'a pas changé depuis la dernière sauvegarde, Time Machine a juste à créer un seul lien matériel à ce répertoire dans le nouveau dossier de sauvegarde. Sans le support des liens matériels aux répertoires, Time Machine aurait dû créer 18 744 répertoires contenant au total 68 839 liens matériels aux fichiers (j'ai utilisé les nombres de mon répertoire /System).

Oui, les répertoires sont petits, et les liens matériels ne prennent que la place nécessaire pour leurs noms de répertoires (au minimum, assez pour stocker le nom, et un pointeur vers les données sur le disque), mais ces octets se multiplient rapidement quand il s'agit de dizaines de milliers de liens matériels, créés à chaque fois que vous voulez faire une sauvegarde. Les liens matériels aux répertoires rendent tout cela plus simple, et plus efficient.

Il y a une dernière forme d'habileté dans Time Machine. Quand le temps est venu de faire une sauvegarde, comment Time Machine sait-elle quels fichiers ont changé depuis la dernière Sauvegarde ? Si vous avez tout lu depuis le début, et pas sauté des sections comme un faible, la réponse est évidente : FSEvents.

Bien qu'Apple ait été assez gentille pour en faire un framework public, Time Machine est très vraisemblablement la vraie raison pour laquelle FSEvents fut créé. Time Machine peut se réveiller quand elle veut, et trouver facilement ce qui a changé depuis le dernier test (c'est à dire, depuis le dernier event id du système de fichiers qu'il a vu). Comme FSEvents reporte les changements au niveau du répertoire, Time machine doit encore déterminer quels fichiers dans ce répertoire ont changé. Pas de problème ! Elle dispose de la précédente sauvegarde de ce répertoire, comme référence. FSEvents et Time Machine sont parfaitement liés l'un à l'autre.

Les conséquences de l'implémentation

C'est dommage que l'habileté de Time Machine n'aille pas un petit peu plus loin. La plus petite unité de donnée que Time Machine soit capable de sauvegarder est le fichier. Cela signifie que si vous changez un octet dans un fichier de 10 Mo, C'est le fichier entier de 10 Mo qui doit être copié sur le volume de sauvegarde. Les liens matériels ne sont d'aucune aide ici. Il n'y a aucun moyen de faire un lien matériel vers 9 999 999 999 octets de données anciennes plus un octet de données nouvelles.

Mais est-ce que cela se présente souvent ? Bien sûr, c'est le pire scénario pour une système de sauvegarde au niveau du fichier comme Time Machine, mais n'est-il pas rare de modifier régulièrement une petite portion d'un énorme fichier ? Et bien, ça dépend. Je connais deux exemples qui vont concerner des milliers d'utilisateurs de Macs.

Le premier, si vous utilisez Microsoft Entourage, votre courriel est conservé dans un seul, énorme fichier de base de données. Le mien fait autour de 2 Go. La plupart des gens reçoivent du courrier tous les jours. Beurk !

Le second, c'est si vous utilisez un logiciel de virtualisation comme VMWare ou Parallels ; chaque image-disque de machine virtuelle (VM) est un fichier de plusieurs Go qui change aussi souvent que vous utilisez VM. Beurk, Beurk !

Alors, combien d'utilisateurs de Macs utilisent Entourage, ou un logiciel de virtualisation ? Cela doit être des milliers, et cela va croissant.

Apple a encouragé les développeurs à utiliser de nombreux petits fichiers plutôt qu'un gros depuis des années, principalement pour rendre plus facile l'indexation par Spotlight des données des applications. Dans Tiger, Apple Mail est passé à la sauvegarde de messages individuels plutôt qu'à des boîtes aux lettres monolithiques, pour cette raison. On peu supposer que Entourage pourrait faire la même chose, mais je ne sais pas s'il procède ainsi dans la version de Microsoft Office 2008 qui se profile. Mais pour les fichiers de machines virtuelles, le problème est incontrôlable.

Ce problème a besoin d'être résolu. La meilleure solution est qu'Apple se tourne vers un nouveau système de fichiers, qui supporte des clichés au niveau du bloc. ZFS, par exemple, conviendrait. Il est regrettable qu'aucune transition de ce genre ne soit apparue dans Léopard. Time Machine sauvegarde dans un vieux volume HFS +. (Cependant, un support lecture seule pour ZFS est inclus dans Léopard, avec un support expérimental lecture /écriture disponible pour les développeurs).

Réimplanter Time machine au sommet de ZFS, ou de quelqu'autre système de fichiers similaire, serait un gain énorme en matière d'utilisation efficiente de l'espace. Malheureusement, c'est une requête non raisonnable. Ne vous attendez pas à quelque chose de ce genre avant au moins 10.6.

Toutefois, il est possible d'exclure des fichiers spécifiques, en les déplaçant dans la liste "Ne pas sauvegarder" disponible dans la vitre de préférences de Time machine. Cela exclut le fichier sur la base de son chemin. La même API sous-jacente, CSBackupSetItemExcluded() peut aussi être utilisée pour exclure un fichier directement, de la sauvegarde, quelle que soit la manière dont il est déplacé, ou renommé. (Les attributs étendus en action, encore une fois).

Le format de sauvegarde de Time Machine signifie aussi qu'il n'est pas possible de démarrer à partir d'un volume de sauvegarde de Time Machine. A la place, vous devez démarrer sur le DVD d'installation, et restaurer la sauvegarde Time Machine sur un nouveau volume. Si, comme moi, vous préférez disposer d'une sauvegarde démarrable, une application comme Super Duper est encore nécessaire. (Je me refuse à ajouter un point d'exclamation. Désolé, David).

Du bon côté, le format de sauvegarde n'est pas réellement un 'format' . C'est un paquet de fichiers complets dans des dossiers estampillés par la date. Vous n'aimez pas l'interface idiote de restauration de fichier dans le Finder ? Ne l'utilisez pas. Vous pouvez vous déplacer dans le dossier Backups.backupdb à l'aide du Finder, de la ligne de commande, ou d'un autre gestionnaire de fichiers. Mais le plus gros intérêt, avec toutes ces APIs publiques, et des structures simples, c'est qu'on a une champ très vaste pour permettre à des développeurs de créer des applications qui complètent et se greffent sur Time Machine.

C'est une belle machine

Malgré les conséquences de l'incapacité permanente d'Apple à mettre en jeu un successeur au vénérable système de fichiers HFS +, Time Machine est un tour sans faute, conceptuel et technique. D'accord, c'est un tour intérieur, mais il marque encore des points. Time Machine accomplit une tâche qui était auparavant si complexe et si intimidante, que presque personne ne voulait la tenter, et la rend invisible. Comme les grandes idées, cela semble évident quand vous l'avez vue, mais cela n'amoindrit en aucune façon la performance.

Le temps dira (ah...) si cette machine est suffisante pour arriver au but fixé par Apple, 100 % d'utilisateurs de Macs sauvegardant régulièrement, mais cela va certainement laisser une trace. Je suis souvent critiqué par d'autres mères, quand j'utilise ma mère comme exemple, mais cela vient trop à propos pour l'éviter ici. Time Machine est rigoureusement la seule façon que je peux imaginer pour permettre que ma maman sauvegarde son Mac. Quand elle a fait sa mise à jour à Léoaprd, je peux lui dire par téléphone d'acheter un disque externe, de le brancher, et de déclencher un bouton dans une boîte de dialogue. Pas de déplacement, pas de session Apple Remote Desktop (bien que Léopard rende cette chose là plus facile), pas d'installation de logiciel, pas de nouvelle application à apprendre.

Oui, c'est une ouverture vers un futur auto-suffisant-pour-maman auquel nous rêvons tous. Le format ouvert de sauvegarde ; et les APIs, sont la bonne façon d'ajouter de nouvelles caractéristiques sans la charge d'être tout pour tout le monde. Laissez les développeurs indépendants rajouter de la valeur ; ils vont vous aimer pour ça. Time Machine mérite sa place comme caractéristique frontale dans Léopard. Bonne démonstration, Apple.