Tag Archive for Time Machine

Faire un nettoyage des snapshots de macOS

J’ai abordé hier la notion de snapshot avec APFS, une fonction super puissante et très pratique pour créer un instantané d’un volume. Suite à cet article, j’ai reçu une question sur le stockage de macOS qui prend parfois bien plus de place qu’il ne devrait. Par exemple une partition macOS qui occupe 300 Go d’espace alors que l’utilisateur n’exploite réellement que quelques Go du disque. Et cela m’a fait penser à un problème que j’ai rencontré récemment avec ces fameux snapshots.

En effet, en voulant faire du nettoyage sur mon Mac, j’ai dégagé une grosse partie des machines virtuelles que j’utilisais avec VMware Fusion. Mais une fois la corbeille vidée, surprise : impossible de récupérer l’espace-disque pris par ces machines ! Soit plusieurs centaines de Go…

Il faut savoir que normalement, les snapshots sont automatiquement nettoyés lorsque de l’espace-disque est nécessaire. Ils sont donc à ce titre considérés comme de l’espace-disque disponible et comptés comme tel. En clair : même si un Snapshots prend 200 Go sur votre disque, macOS n’affichera pas cette espace comme occupé.

Sauf que dans mon cas, ça n’est pas exactement ce qui s’est produit. Et cela était à priori dû à une fonction de macOS : les instantanés locaux de Time Machine. Cette fonction suuuuuuper utile permet de sauvegarder régulièrement les données de votre poste même quand votre disque Time Machine n’est pas disponible. Dans ce cas, macOS passe par les sauvegardes locales pour vous permettre quand même de récupérer vos données en cas de pépin (genre un fichier que vous avez effacé par erreur).

Revenons sur notre problème. Dans mon cas, je ne sais pas si c’était dû à un bug ou pas, mais la seule solution a été pour moi de supprimer les snapshots locaux. Pour cela, il a fallu à nouveau passer par le Terminal et la commande tmutil.

tmutil listlocalsnapshotdates /

Affiche les dates des snapshots disponibles pour votre Mac :

Time machine snapshots

On aurait pu utiliser aussi

tmutil listlocalsnapshots /

Mais la première commande est préférable car elle liste uniquement les dates des snapshots, et comme vous le verrez ensuite, ça sera plus pertinent.

À priori, peu de chances que votre disque soit gavé jusqu’à la moelle de snapshots. Mais si vous devez en effacer, vous disposez de deux options.

Supprimer une certaine quantité de données

Pour cela, tapez :

tmutil thinlocalsnapshots / TailleEnOctets UrgenceDe1à4

Vous pouvez spécifier dans la commande :

– La taille en octets à récupérer. Par exemple, si vous voulez récupérer 10 Go, tapez 10000000000 (Oui je sais qu’un Go ça fait pas 10 000 000 000 octets précisément MERCI, c’est pour simplifier enfin) ;

– Eventuellement, le degré d’urgence, qui sera un chiffre compris entre 1 et 4.. Ce qui est rigolo, c’est qu’Apple ne précise pas ce que ça fait exactement. Mais on peut penser que ça permet, euh, de faire agir la commande plus vite. Ou pas. Bref.

Supprimer des dates précises de snapshots

C’est dans ce cas précis qu’il vaut mieux avoir les dates uniquement affichées avec listlocalsnapshotdates.

tmutil deletelocalsnapshots date

Où vous remplacerez date par une date de snapshot à supprimer.

Evidemment, vous voyez le souci : il est impossible de facilement savoir quelle est la taille utilisée réellement par un snapshot APFS et donc de viser un snapshot précis. C’est fort dommage. Mais c’est comme ça.

Dans mon cas, donc, je n’ai vu regagner de la place sur mon disque qu’après avoir supprimé tous les snapshots locaux.

Un peu de philosophie sur la façon dont nous appréhendons le stockage

J’aurais quand même tendance à devoir de nos jours expliquer que le stockage s’use si on s’en sert. Mais pour le coup, les snapshots sont une BONNE façon d’occuper de l’espace de façon intelligente. Dans l’absolu, sauf horreur ou que vous ne trouvez vraiment pas votre compte de stockage, ne vous forcez pas à supprimer les snapshots locaux. Il vaut mieux les avoir sous la main et en disposer en cas de pépin plutôt que de vouloir absolument chercher à récupérer le moindre octet quand cela n’est pas nécessaire.

Bref : sauf cas extrême, laissez votre Mac gérer votre espace de stockage pour vous.

Faire un snapshot de macOS avant un déploiement

Avec l’arrivée d’APFS, Apple a introduit dans son système de fichiers une fonction très puissante : les snapshots. L’idée est de pouvoir rapidement prendre une sorte de photographie instantanée du disque, et de pouvoir rapidement y retourner en cas de problème. Par exemple : vous installez une mise à jour système, mais la mise à jour échoue : en quelques secondes, vous pouvez utiliser le snapshot fait avant l’installation pour revenir à un état de votre Mac exactement tel qu’il était avant le plantage. Puissant et très pratique !

C’est encore plus pratique pour pouvoir tester par exemple un processus de déploiement de Mac et rapidement revenir à l’état du poste avant le déploiement, en conjonction avec l’astuce précédente qui consistait à appeler le Terminal lors du premier démarrage du Mac. Une fois la fenêtre du Terminal apparue, tapez simplement :

tmutil localsnapshot

Et validez avec Entrée. Un message apparaitra pour confirmer le snapshot avec sa date de création.

Createlocalsnapshot

Si vous souhaitez revenir à l’état du Mac avant le snapshot, démarrez sur la partition Recovery avec Cmd +R puis sélectionnez Restaurer une sauvegarde Time Machine. Sélectionnez alors votre volume APFS, puis la sauvegarde à restaurer. Après quelques secondes, votre Mac redémarre tel qu’il était au moment du snapshot.

Time Machine Restore local snapshot 2

Time Machine Restore local snapshot 1

Attention cependant : les snapshots effectués ainsi expirent au bout de 24 heures. Il faut donc penser à recréer régulièrement un nouveau snapshot pour éviter tout souci !

tmutil : la commande cachée pour Time Machine

Certes, j’ai beaucoup râlé sur ce que Lion n’apportait pas, ou apportait en trop, ou ce qu’il faisait à mon goût mal. Mais il recèle aussi quelques pépites fort utiles, par exemple une nouvelle commande de Terminal appelée tmutil.

Cette commande sert à manipuler Time Machine, de façon très complète, voire plus complète qu’avec l’interface graphique.

La façon la plus simple de l’utiliser, c’est encore de taper juste tmutil :

Minimoi:~ admini$ tmutil
Usage: tmutil help <verb>
Usage: tmutil version
Usage: tmutil enable
Usage: tmutil disable
Usage: tmutil startbackup [-b|--block]
Usage: tmutil stopbackup
Usage: tmutil enablelocal
Usage: tmutil disablelocal
Usage: tmutil snapshot
Usage: tmutil delete snapshot_path ...
Usage: tmutil restore [-v] src dst
Usage: tmutil compare [-a@esmugtdrvEX] [-D depth] [-I name]       tmutil compare [-a@esmugtdrvEX] [-D depth] [-I name] snapshot_path       tmutil compare [-a@esmugtdrvEX] [-D depth] [-I name] path1 path2
Usage: tmutil setdestination mount_point       tmutil setdestination [-p] afp://user[:pass]@host/share
Usage: tmutil addexclusion [-p] item ...
Usage: tmutil removeexclusion [-p] item ...
Usage: tmutil isexcluded item ...
Usage: tmutil inheritbackup machine_directory       tmutil inheritbackup sparse_bundle
Usage: tmutil associatedisk [-a] mount_point volume_backup_directory
Usage: tmutil latestbackup
Usage: tmutil listbackups
Usage: tmutil machinedirectory
Usage: tmutil calculatedrift machine_directory
Usage: tmutil uniquesize path ...
Use `tmutil help <verb>` for more information about a specific verb.Minimoi:~ admini$

Bon… Pas forcément très parlant tout ça. Déjà, on voit quand même qu’on dispose d’options pour activer (enable) ou désactiver (disable) Time Machine. Évidemment, il faudra lancer la commande en root, donc la précéder de sudo puis taper son mot de passe administrateur.

Minimoi:~ admini$ sudo tmutil enable

Maintenant, vous pouvez choisir une destination de sauvegarde :

Minimoi:~ admini$ sudo tmutil setdestination /Volumes/Untitled

On peut aussi lancer une sauvegarde :

Minimoi:~ admini$ sudo tmutil startbackup
Total copied: 247.19 MB (259201817 bytes)
Avg speed:    617.66 MB/min (10794449 bytes/sec)

L’option –block (ou -b) lance la sauvegarde en premier plan. En clair : tant qu’elle n’est pas terminée, vous ne pouvez pas aller plus loin. Moui… Mais on doit pouvoir faire mieux que ça non ?

Minimoi:~ admini$ sudo tmutil enablelocal

Voilà qui est bien plus intéressant ! L’option enablelocal active une des nouvelles fonctions de Time Machine dans Lion : les sauvegardes locales. Lorsque votre Mac est déconnecté de son disque de sauvegarde, il peut continuer à faire des sauvegardes transparentes sur votre disque interne. Si cette fonction vous agace, vous pouvez la désactiver en tapant tmutil disablelocal. Mais vous pouvez aussi l’activer sur un Mac de bureau pour avoir des sauvegardes locales au cas où… Celles-ci seront ensuite automatiquement rapatriées vers votre disque Time Machine.

 

On peut aussi supprimer une sauvegarde Time Machine, ce que ne permet pas le Finder, même avec le compte root !

 

Minimoi:~ admini$ sudo tmutil delete /Chemin/Vers/Le_Dossier_TimeMachine_A_Effacer

Au passage, une astuce : tapez juste sudo tmutil delete, retournez dans le Finder, affichez le dossier Backup.backupdb dans le Finder, sélectionner une sauvegarde dans son dossier, puis glissez-la dans la fenêtre de Terminal pour récupérer son chemin.

Vous avez un dossier ou un fichier à restaurer ? Pas de problème, l’option restore est là pour vous (et vous pouvez l’utiliser sans sudo) :

 

Minimoi:~ admini$ tmutil restore /Chemin/Vers/Le/Dossier/A/Restaurer Dossier_Cible

Et si vous voulez savoir quel fichier est copié en live, ajoutez -v après restore.

Oh, mais on peut aussi faire un instantané du disque sous forme de « snapshot » ! Histoire de le restaurer rapidement en cas de problème :

Minimoi:~ admini$ sudo tmutil snapshot

Bon, ça, j’ai l’impression que ça marche moyen. À tester plus tard…

 

Vous voulez exclure un dossier de la sauvegarde ? Tapez donc :

Minimoi:~ admini$ tmutil addexclusion /Chemin/Vers/Le_Dossier_A_Exclure
Il est intéressant ici de savoir qu’en plus du comportement par défaut de Time Machine en mode graphique, qui est d’associer l’exclusion à un dossier ou un fichier *où qu’il se trouve sur le disque* (en clair : si on le déplace ou qu’on le copie ailleurs, il continuera de ne pas être sauvegardé), on peut choisir en ligne de commande une autre option : en ajoutant -p après addexclusion, on peut définir un chemin de façon absolue et définitive. Ainsi, si vous déplacez le dossier ou fichier dans le chemin défini, il sera à nouveau disponible pour la sauvegarde.

Il y a bien  d’autres options éventuellement à voir, mais ça sera… pour un autre article :)

Sauvegarder dans le Cloud : bonne ou mauvaise idée ?

Cela fait quelques temps que je me posais des questions sur la pertinence des solutions de sauvegarde en ligne. Un article de MacGeneration publié il y a quelques semaines sur l’arrivée de Dolly Drive sur le marché des solutions de sauvegarde en ligne me donne enfin l’occasion de rebondir sur le sujet et d’approfondir un peu cette fameuse question.

Car s’il est un marché qui explose en ce moment, c’est bien celui du stockage en ligne, avec Amazon S3, qui propose du stockage pas cher, mais également d’autres solutions comme Mozy, Yellow Backup, Crashplan et donc, depuis quelques jours, Dolly Drive. Mais tous les systèmes de sauvegarde ne se valent pas, et il faut réfléchir à plusieurs problématiques lorsqu’on décide de placer ses données dans le Cloud. 1

Pourquoi sauvegarder en ligne ?

La sauvegarde en ligne permet de répondre à cette fameuse problématique de l’externalisation des sauvegardes. Car malheureusement, il arrive que des drames arrivent parfois. Et dans ce cas, ça peut être le travail de toute une vie qui disparaît, une entreprise qui se retrouve complètement bloquée ou qui est obligée de mettre la clé sous la porte… Vous devez donc vous assurer de disposer d’une sauvegarde de vos données les plus importantes à l’extérieur de votre entreprise ou de votre domicile.

Durant des années, la solution classique a été la bonne vieille disquette, puis le lecteur de cartouches. Syquest, Bernouilli, Jaz, AIT, DLT… Le grand leader de la cartouche est désormais le LTO, ouvert, très bien conçu, mais dont le coût peut sembler quelque peu démesuré par rapport aux besoins des petites entreprises (mais par contre très bien adaptées aux besoins de sauvegardes pour les SAN par exemple). On trouve aussi des lecteurs de cartouches renfermant un disque dur 2,5″ comme le RDX de Tandberg ou le GoVault de Quantum. Intérêt : le disque peut être utilisé sans logiciel de sauvegarde spécial, il est juste vu comme un disque externe…

Malheureusement, les solutions à base de cartouches à bande nécessitent un logiciel de sauvegarde apte à les gérer. Et là, on ne peut pas dire que les solutions sur Mac soient nombreuses. Entre un Retrospect qui n’arrête pas d’être racheté puis revendu et dont le passage à Mac OS X s’est fait dans la douleur, BRU dont l’interface graphique a longtemps été loin d’être au point malgré des outils en ligne de commande efficaces, ou des solutions très haut de gamme comme NetVault ou Time Navigator… Il reste Prestore, avec lequel j’ai un peu de mal, mais ça vient peut-être de moi. Cela dit tous ceux qui l’utilisent en sont très content.

Le souci des cartouches, c’est donc qu’il faut penser à les changer. Donc, arriver sur site avec la cartouche de la semaine, la mettre dans le lecteur, garder au moins deux cartouches hors site, etc. Avec le risque de se faire piquer la cartouche (même si on peut toujours chiffrer le contenu de la sauvegarde), de ne pas penser à la prendre le dimanche soir pour la remettre dans le lecteur le lundi, etc.

La démocratisation des lignes à haut débit permet désormais de se faciliter la vie en proposant une sauvegarde site à site facile, ou une sauvegarde dans le Cloud. Et là, tout devient plus simple : plus de cartouche à gérer, la sauvegarde se faisant de façon transparente, de façon très simple.

Oui, mais comme souvent, avec tout ce qui touche à la technologie… Il y a un « mais ».

La question de la confidentialité

C’est bien évidemment ce qui fait le plus peur quand on confie ses données à une autre entreprise. On n’a pas forcément envie de mettre entre les mains d’un tierce ses données confidentielles. Sur ce point, tout est question de point de vue :

  • Vous pouvez penser que le risque que le bâtiment hébergeant vos données brule est plus important que le risque que certaines données soient consultées par les barbouses de la DGSE. Dans ce cas, la solution de sauvegarde dans le Cloud est faite pour vous.
  • Vous pensez au contraire qu’une fois vos données dans le Cloud, n’importe qui peut y avoir accès (syndrome de Stallman) alors qu’il y a peu de chance que le Ciel vous tombe sur la tête. Dans ce cas, laissez vos données sur votre disque, et n’oubliez pas vos bonnes vieilles cartouches.

Crashplan propose cependant une alternative très intéressante : vous téléchargez le logiciel Crashplan, et vous pouvez sauvegarder (à titre d’utilisation personnelle) sur un disque externe, un autre ordinateur de votre réseau, ou… sur l’ordinateur d’un ami, par le biais d’un code à s’échanger. Et là, on a une solution finalement très intéressante, puisqu’on diminue énormément le risque de voir les données disparaître dans la nature. Vous « offrez » un disque à votre ami, qui le branche sur son ordinateur, et hop, vos données sont régulièrement sauvegardées chez votre ami. Et même si on vole le disque de sauvegarde, les données sont chiffrées, et donc illisibles sans votre mot de passe… qui lui, reste uniquement sur votre ordinateur !2

Quand on sauvegarde dans le Cloud, un autre point important doit être pris en compte : la durée de sauvegarde, qui via Time Machine est variable selon plein de critères. Hors, l’un des principaux points faibles de Time Machine réside dans son manque de granularité : si un fichier est modifié d’un seul bit, il est entièrement sauvegardé à nouveau… Très (trop) lourd. Un logiciel de sauvegarde dans le Cloud ou en externalisation se doit de sauvegarder uniquement les données modifiées de vos fichiers et pas le fichier en intégralité, sinon le temps et le coût de la sauvegarde explosent.

Quid de Dolly Drive ?

Le problème de Dolly Drive est double.

  • D’abord, il s’appuie sur le moteur de Time Machine pour sauvegarder sur le Net. Or, Time Machine n’a pas été conçu à la base pour sauvegarder de façon archi-sécurisée vos données sur Internet, mais pour sauvegarder régulièrement vos données en local. Cela implique de gros défauts, en particulier, la redondance des copies due à un manque d’intelligence flagrant de Time Machine. Prenons par exemple le cas suivant : dans un moment de délire, vous décidez de déplacer un dossier contenant beaucoup de fichiers sur votre disque dur. Que va-t-il donc se passer ? Et oui, Time Machine recopie à nouveau TOUTES les données du nouveau dossier. C’est ballot, mais c’est comme ça. Un logiciel plus moderne comme Crashplan fait de la déduplication de données, si bien que si un fichier est en double dans la sauvegarde, il ne sera réellement sauvegardé qu’une seule fois et ne sera pas recopié à nouveau. Donc, gain de temps sur la sauvegarde, moins d’espace-disque utilisé car pas de doublon, etc.
  • L’autre problème de Time Machine : les performances en réseau. Le protocole AFP qu’utilise Time Machine pour les sauvegardes en réseau est certes très rapide sur un réseau local, mais particulièrement lent et inadapté à une sauvegarde sur Internet. De plus, aucune somme de contrôle n’est effectuée sur les fichiers, ne garantissant donc à aucun moment que le fichier est bien arrivé à destination. Ce qui peut être très gênant dans le cas d’une sauvegarde distante : entre votre Mac et votre serveur, les pertes de paquet ou déconnexions sont très rares, mais entre votre poste et un serveur à l’étranger, tout peut arriver.

En clair, donc : Dolly Drive est une solution au concept intéressant, mais se basant sur un moteur qui n’est pas taillé pour. C’est un peu comme vouloir utiliser une Formule 1 pour faire du 4×4 en montagne…

Alors, que faire ?

Déjà, ça me semble évident : oublier Dolly Drive. Une idée intéressante, mais qui ne peut s’appuyer sur un moteur peu adapté à cet usage.

Ensuite, et c’est une évidence, multiplier les sauvegardes. À ce titre, rappelons quelques points essentiels :

  • Faire une synchro, ce n’est pas sauvegarder. Si un fichier est endommagé sur le disque d’origine, il sera alors dupliqué à l’identique sur le disque de sauvegarde. Et donc, impossible à restaurer.
  • Le RAID n’est pas une sauvegarde, juste un moyen d’éviter une indisponibilité des données3. Le RAID consiste peu ou prou à avoir des données redondantes sur plusieurs disques afin qu’en cas de panne de l’un d’entre eux, le système continue de fonctionner correctement. Mais si une donnée est endommagée sur un disque d’un volume RAID, elle est également endommagée sur tous les disques de l’ensemble. Aucune chance donc de retrouver le fichier.
  • Il vaut mieux avoir trop de sauvegardes que pas assez.
  • Testez vos sauvegardes. Rien de plus idiot que de retrouver des données dans ses sauvegardes mais qu’elles soient inexploitables. De temps en temps, restaurez un ou plusieurs fichiers pour vous assure qu’ils sont correctement lisibles. Et pour vos vieux fichiers, gardez les CD/DVD (disquettes ???) d’installation de vos anciens logiciels.

Et si vous trouvez que je parle trop de Crashplan dans cet article, c’est qu’il est vraiment, vraiment bien conçu, et répond à de très nombreuses problématiques posées par la sauvegarde. Quand on sait en plus que le soft dans sa version standard est gratuit pour une utilisation familiale (et vraiment peu cher pour la partie entreprise)… Pourquoi hésiter ?

  1. Le Cloud, ce n’est pas un système de retouche photo en ligne pour faire une photo pourrie à partir de plusieurs photos pourries, comme voudrait vous le faire croire Microsoft dans ses pubs…
  2. Et si vous trouvez ces solutions peu fiables, dites-vous que quand vous transférez par exemple vos données par FTP, vous n’avez AUCUNE sécurité, puisque même les mots de passe circulent en clair ! Idem quand vous envoyez un mail : le pourcentage de la population qui doit être capable d’envoyer un mail chiffré ne doit pas dépasser les 0,1%, et encore, je suis généreux.
  3. Dans le cadre de disques en RAID1 ou supérieur, le RAID 0 n’assurant que des performances plus rapides au détriment de la sécurité des données

Time Machine Erreur 11 : et pourquoi pas les ACL ?

Je viens de tomber sur un cas étrange : un serveur qui refuse de sauvegarder correctement avec Time Machine, en déclenchant des erreurs de ce type à tort-la-rigaud tire larigot :

41) SrcErr:NO Copying /Groups/xxxxxx/blahblah/pouet/DossierTruc to /Volumes/Copies de sauvegarde Time machine/Backups.backupdb/Monserveur/2009-11-13-005451.inProgress/ED94403D-4B1F-42A1-9DCF-7A36836BABA2/Groups/xxxxxx/blahblah/pouet/DossierTruc
Nov 13 01:20:33 serveur com.apple.backupd[57561]: Copied 526 files (292.7 MB) from volume Serveur.
Nov 13 01:20:33 serveur com.apple.backupd[57561]: Copy stage failed with error:11
Nov 13 01:20:39 serveur com.apple.backupd[57561]: Backup failed with error: 11

Cas intéressant : ce plantage surgit toujours au même endroit, et si on exclut le dossier coupable des sauvegardes, le bug se répète quelques minutes plus tard au même endroit. Pourtant les fichiers incriminés semblaient en bon état… Et le scénario se répète sur deux serveurs de sauvegarde différents… Hmmmmm.

Après pas mal de recherches, il semble que le bug soit lié à un nombre d’ACL trop important sur les dossiers ou fichiers incriminés. En supprimant les entrées surnuméraires de la liste des autorisations (avec Server admin par exemple) et en particulier des ACL, il semble que Time Machine n’échoue plus sur la sauvegarde.

Pensez-y donc : si votre sauvegarde avec Time Machine vous semble chancelante, pensez à vérifier les ACL de vos dossiers et réduisez-les au maximum.

Time Machine, à l’épreuve du feu

Ce soir, le disque dur du MacBook de mon épouse a décidé de rendre l’âme. Comme ça, sans prévenir, enfin presque : quelques secondes après qu’elle m’ait demandé « c’est quoi ce bruit là », la machine a figé, et au reboot, plus rien de disponible… Argh. Un disque dur qui lâche d’un coup, ce n’est jamais rigolo. Et cela aurait pu être très, très problématique…

Sauf qu’il y a quelques mois, j’avais créé un partage pour Time Machine sur mon serveur multimédia, qui sert aussi pour EyeTV ou comme console de jeu occasionnelle. Il tourne sous Mac OS X Server 10.5, et ce dernier permet de transformer un point de partage comme point de sauvegarde pour Time Machine.

Coup de bol, j’avais aussi un disque dur de secours qui pouvait rentrer dans le Macbook. Après avoir démarré sur un DvD d’installation, j’ai donc utilisé la fonction de restauration d’une sauvegarde Time Machine. Magie d’Apple, le DVD m’a permis d’accéder au serveur à distance, et de restaurer une sauvegarde datant de moins d’une heure avant le crash… Et après environ une heure trente de restauration, le Macbook était fin prêt à fonctionner. Certes, il a fallu encore attendre un peu pour la réindexation des messages dans Mail, mais le Macbook était à nouveau fonctionnel à 100% en moins de trois heures après le crash, changement du disque dur compris…

Conclusion : Time Machine est aussi efficace pour restaurer une machine complète que pour récupérer quelques fichiers dans une sauvegarde. Et ça, c’est quand même plutôt très rassurant ! Et accessoirement, ce billet est surtout là pour vous rappeler que la défaillance, mécanique ou logicielle, peut surgir absolument n’importe quand. Pensez donc à vous préparer dès aujourd’hui à toute panne ! Et accessoirement, avoir un disque de rab’ c’est finalement pas si mal que ça…