Time Machine ridiculement lent après la mise à jour d'El Capitan

Une partie du problème réside dans le fait que les opérations d'entrée/sortie (E/S) à faible priorité semblent maintenant être fortement limitées. Vous pouvez le vérifier via le Terminal (que vous pouvez trouver via Spotlight (généralement lié à Space ) et en entrant terminal ) puis en entrant à l'invite bash :

sudo fs_usage backupd

et cherchez le THROTTLED les entrées. Si vous les voyez, la sauvegarde est étranglée.

Ainsi, si vous avez une tonne de fichiers, le temps nécessaire pour effectuer les entrées/sorties prend une éternité, même si les fichiers sont petits (parce qu'il y a beaucoup plus d'opérations d'entrée/sortie autour des fichiers). xattrs etc. qu'auparavant).

Allez dans un terminal et entrez :

sudo sysctl debug.lowpri_throttle_enabled=0

Pour moi, cela a permis de passer de 72 heures à ~4 heures sur un système de fichiers contenant 2,5 millions de fichiers.

C'est aussi une bonne idée de réactiver l'étranglement après que votre sauvegarde se soit terminée avec succès avec la commande suivante

sudo sysctl debug.lowpri_throttle_enabled=1

Je confirme que la commande :

sudo sysctl debug.lowpri_throttle_enabled=0 

fonctionne parfaitement.

Si vous voulez le rendre permanent après un redémarrage, vous pouvez faire ce qui suit.

• créer un fichier sous /Library/LaunchDaemons/fix-el-capitan-slow-time-machine-speed.plist

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
    <dict>
      <key>Label</key>
      <string>fix-el-capitan-slow-time-machine-speed</string>
      <key>ProgramArguments</key>
      <array>
        <string>/usr/sbin/sysctl</string>
        <string>debug.lowpri_throttle_enabled=0</string>
      </array>
      <key>RunAtLoad</key>
      <true/>
    </dict>
  </plist>

• s'assurer que le fichier appartient à Root

  sudo chown root /Library/LaunchDaemons/fix-el-capitan-slow-time-machine-speed.plist

• donnez la commande

  sudo launchctl load /Library/LaunchDaemons/fix-el-capitan-slow-time-machine-speed.plist

Vous pouvez trouver le contenu du fichier à cette adresse Gist

J'ai trouvé cet article sur les forums de discussion Apple à propos du message qui apparaît dans la console (alors qu'elle ne fait rien ou qu'elle sauvegarde à 10 octets/seconde) :

com.apple.backupd: Waiting for index to be ready (100)

Dans mon cas, j'ai pu me débarrasser de toutes les anciennes sauvegardes, j'ai donc démonté le volume du Mac en question, monté le lecteur/partage réseau à partir d'un autre ordinateur (pas un Mac), supprimé l'ensemble de la base de données de l'entreprise. .sparsebundle (ce qui a pris un temps étonnamment long) et a ensuite recommencé la sauvegarde. Elle a créé un nouveau .sparsebundle et la sauvegarde se fait maintenant à environ 10 Mo/sec.

Si vous ne voulez pas supprimer vos sauvegardes existantes, vous pouvez essayer l'une des autres suggestions de cette page :

• redémarrer en mode sans échec, puis revenir à la normale ;
• indiquer à Spotlight de ne pas indexer le volume/disque Time Machine ;
• en supprimant l'index Spotlight, .Spotlight-V100 (que je n'avais pas) ;
• en utilisant mdutil pour désactiver et réactiver l'indexation Spotlight sur le volume :
  • sudo mdutil -i off /Volumes/Time\ Machine\ Backups
  • sudo mdutil -i on /Volumes/Time\ Machine\ Backups

(voir cette discussion pour plus de détails et d'idées).

J'ai eu des problèmes similaires après avoir migré vers El Capitan - les sauvegardes (même les petites sauvegardes incrémentielles) ont été ralenties. J'ai donc fait un dump wireshark de la conversation entre le Mac et le NAS, et j'ai vu de nombreuses requêtes FPGetFileDirParms échouer. AFP est (était ?) le protocole que Time Machine utilise pour communiquer avec les disques NAS, mais j'ai lu qu'ils sont en train de passer à SMB.

174 0.390744    192.168.0.9 192.168.0.10    AFP 107 FPGetFileDirParms request: Vol=3 Did=62779 Name=._1b6c
176 0.391729    192.168.0.10    192.168.0.9 AFP 82  FPGetFileDirParms reply: object not found (-5018)[Malformed Packet]
178 0.392002    192.168.0.9 192.168.0.10    AFP 101 FPGetFileDirParms request: Vol=3 Did=93632
179 0.392909    192.168.0.10    192.168.0.9 AFP 82  FPGetFileDirParms reply: object is the wrong type (-5025)[Malformed Packet]

Je n'ai aucune idée de la raison pour laquelle ces requêtes ont échoué, mais le nombre de ces tentatives ratées est ÉNORME - les données effectivement transférées sont minuscules par rapport au nombre de ces requêtes ratées - d'où la vitesse lente et rampante.

Ce qui a marché pour moi, c'est :

1. Je suis allé dans Préférences Time Machine->Sélectionner un disque et j'ai supprimé le disque actuellement associé (qui était connecté à afp://MyBookLive.local/TimeMachine)
2. Je suis allé dans Finder->Go->Connecter au serveur. Saisissez l'adresse IP du disque NAS dans l'espace "Adresse du serveur" (smb://192.168.0.10 pour moi).
3. Connectez-vous. Une liste de volumes à monter s'est affichée - j'ai choisi le volume utilisé pour TimeMachine (TimeMachine pour moi). TimeMachine est monté dans /Volumes.

4. Depuis le terminal, j'ai couru :

   sudo tmutil setdestination /Volumes/TimeMachine

C'est ça. Time machine est maintenant associé à /Volumes/TimeMachine au lieu de afp://MyBookLive.local/TimeMachine. Les sauvegardes précédentes étaient bonnes, et les sauvegardes incrémentales qui ont eu lieu après cela ont été RAPIDES. Un dump wireshark que j'ai fait après cela n'a montré aucun échec de requête AFP (bien que l'AFP soit toujours le protocole utilisé).

Je n'ai pas réussi à résoudre le problème, mais j'ai découvert que ma Time Machine ralentit lorsqu'elle sauvegarde les données d'autres utilisateurs (non connectés). Il se peut qu'il y ait un problème de permission dans les fichiers des dossiers des autres utilisateurs. Lorsque j'ai ajouté cet utilisateur à la liste des exceptions, la TM fonctionne bien.