Time Machine nach El Capitan-Upgrade lächerlich langsam

Ein Teil des Problems besteht darin, dass Input/Output-Operationen (I/O) mit niedriger Priorität jetzt stark gedrosselt zu werden scheinen. Sie können es über Terminal überprüfen (kann über Spotlight gefunden werden (normalerweise an gebunden ⌘Space) und Eingabe von terminal) und dann an der Bash-Eingabeaufforderung eingeben:

sudo fs_usage backupd

und suchen Sie nach den THROTTLEDEinträgen. Wenn Sie sie sehen, ist die Sicherung gedrosselt.

Wenn Sie also eine Menge Dateien haben, dauert nur die Zeit, die zum Ausführen der E / A benötigt wird, ewig, selbst wenn die Dateien klein sind (weil sie eine Menge mehr E / A-Operationen xattrsusw. ausführt als früher).

Gehen Sie zu einem Terminal und geben Sie Folgendes ein:

sudo sysctl debug.lowpri_throttle_enabled=0

Für mich beschleunigt dies von 72 Stunden auf ~ 4 Stunden auf einem Dateisystem mit 2,5 Millionen Dateien.

Es ist auch eine gute Idee, die Drosselung wieder zu aktivieren, nachdem Ihr Backup mit dem folgenden Befehl erfolgreich abgeschlossen wurde

sudo sysctl debug.lowpri_throttle_enabled=1

Ich bestätige, dass der Befehl:

sudo sysctl debug.lowpri_throttle_enabled=0 

funktioniert perfekt.

Wenn Sie es über den Neustart hinweg dauerhaft machen möchten, können Sie Folgendes tun.

• Erstellen Sie eine Datei unter/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>
  

• Stellen Sie sicher, dass die Datei zu root gehört

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

• den Befehl ausgeben

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

Den Inhalt der Datei finden Sie in diesem Gist

Ich habe diesen Artikel in den Apple-Diskussionsforen über die Meldung gefunden, die in der Konsole angezeigt wird (während sie nichts tut oder mit 10 Bytes/Sekunde sichert):

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

In meinem Fall konnte ich alle alten Backups verwerfen, also habe ich das Volume vom problematischen Mac getrennt, das Laufwerk/die Netzwerkfreigabe von einem anderen Computer (kein Mac) gemountet, das gesamte .sparsebundleVerzeichnis gelöscht (was überraschend lange gedauert hat) und dann die Sicherung erneut gestartet. Es hat eine neue erstellt .sparsebundleund sichert jetzt mit etwa 10 MB/s.

Wenn Sie Ihre vorhandenen Sicherungen nicht löschen möchten, können Sie einen der anderen Vorschläge auf dieser Seite ausprobieren:

• Neustart im abgesicherten Modus und dann wieder normal;
• weisen Sie Spotlight an, das Volume/die Festplatte von Time Machine nicht zu indizieren;
• Löschen des Spotlight-Index .Spotlight-V100(den ich nicht hatte);
• Verwendung mdutilzum Deaktivieren und erneuten Aktivieren der Spotlight-Indizierung auf dem Volume:
  • sudo mdutil -i off /Volumes/Time\ Machine\ Backups
  • sudo mdutil -i on /Volumes/Time\ Machine\ Backups

(Siehe diese Diskussion für weitere Details und Ideen).

Ich hatte ähnliche Probleme, nachdem ich zu El Capitan gewechselt war – Backups (selbst kleine inkrementelle) verlangsamten sich zu einem echten Schneckentempo. Also habe ich einen Wireshark-Dump des Geschwätzes zwischen dem Mac und dem NAS erstellt und zahlreiche fehlgeschlagene FPGetFileDirParms-Anforderungen gesehen. AFP ist (war?) das Protokoll, das die Zeitmaschine verwendet, um mit NAS-Laufwerken zu kommunizieren, aber ich habe gelesen, dass sie zu SMB wechseln.

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]

Ich habe keine Ahnung, warum diese Anfragen fehlgeschlagen sind, aber die Anzahl dieser fehlgeschlagenen Versuche ist RIESIG - die tatsächlich übertragenen Daten sind winzig im Vergleich zur Anzahl dieser fehlgeschlagenen Anfragen - und daher die langsame, kriechende Geschwindigkeit.

Was für mich funktionierte, war:

1. Ich ging zu Time Machine Preferences->Select Disk und entfernte die aktuell zugeordnete Festplatte (die mit afp://MyBookLive.local/TimeMachine verbunden war)
2. Ging zu Finder->Gehe zu->Mit Server verbinden. Geben Sie die IP-Adresse des NAS-Laufwerks in das Feld "Serveradresse" ein (smb://192.168.0.10 für mich)
3. Anschließen. Es warf eine Liste der zu mountenden Volumes auf - wählte das Volume aus, das für die Zeitmaschine verwendet wurde (TimeMachine für mich). TimeMachine wurde in /Volumes gemountet.

4. Vom Terminal lief:

   sudo tmutil setdestination /Volumes/TimeMachine
   

Das ist es. Time Machine ist jetzt mit /Volumes/TimeMachine anstelle von afp://MyBookLive.local/TimeMachine verknüpft. Frühere Backups waren gut und inkrementelle Backups, die danach durchgeführt wurden, waren SCHNELL. Ein Wireshark-Dump, den ich danach erstellte, zeigte keine fehlgeschlagenen AFP-Anforderungen (obwohl AFP immer noch das verwendete Protokoll war).

Ich konnte das Problem nicht beheben, aber ich habe herausgefunden, dass meine Zeitmaschine langsamer wird, wenn sie Daten anderer Benutzer (nicht angemeldet) sichert. Möglicherweise besteht ein Problem mit der Berechtigung in den Ordnerdateien der anderen Benutzer. Als ich diesen Benutzer in die Ausnahmeliste aufgenommen habe, rockt TM.

In Bezug auf Daniel Berlins Antwort oben (aber ich bin neu hier, habe also nicht genug Glaubwürdigkeit, um dort nur einen Kommentar abzugeben), fand ich, dass sein Terminalbefehl in OSX 10.11.3 GROSSARTIG für mich funktioniert. 30-Stunden-Backup in 4 Stunden verwandelt! Es bleibt jedoch nicht nach einem Neustart.

Ich wollte nicht bei jedem Neustart in das Terminal tippen müssen, also ...

Da ich mit Shell-Skripten nicht sehr vertraut bin, habe ich genug gegoogelt, um einen Automator-Workflow zu erstellen, der den Benutzer auffordert, das Root-Passwort einzugeben, und dann den Terminalbefehl ausführt. Ich habe mich entschieden, den Erfolg mit einer Benachrichtigungszentrale zu bestätigen.

Ich habe den Workflow als Anwendung gespeichert und zu meinen Anmeldeobjekten hinzugefügt. Also werde ich jetzt bei jeder Anmeldung aufgefordert, mein Passwort erneut einzugeben, um Time Machine zu entdrosseln.

Es gibt Möglichkeiten, den Prozess mit Shell-Skripten unsichtbar zu machen, aber es ist ein bisschen kompliziert, den Root-Zugriff zu benötigen, der durch den Befehl sudo erlangt wird. Man könnte das Passwort auch in der Automator-App festverdrahten, wenn man sich nicht um die Sicherheit kümmert. (Nicht zu empfehlen.)

Ich würde die Workflow-App hier posten, kann aber anscheinend keine Datei in diese Antwort hochladen. Also werde ich ein JPG davon anhängen, damit jeder es nachbauen kann, wenn er möchte. PS Beachten Sie die Pass-Eingabe "als Argument" für das Shell-Skript

Mein Problem wurde durch den Artikel von DWHoard behoben : Neustart im abgesicherten Modus, dann zurück (für mich schien sich der Computer während des sicheren Bootens selbst herunterzufahren).

Macbook Air Mitte 2011, OS X 10.11.3, Backing to Time Capsule.

Bearbeiten: Tatsächlich scheint Time Machine nach dem sicheren Start und dem normalen Start nur etwa 41/55 GB (innerhalb einer Stunde) erreicht zu haben und wurde wieder gecrawlt (hat seitdem nur 2,75 GB innerhalb von 12 Stunden erreicht. Schade - ich Ich habe die Time Capsule gekauft, um diese Art von Inkompatibilitäten zu vermeiden, und hier bin ich - alle Apple-Geräte und eine miese Erfahrung, Zeitverschwendung. Ich hoffe, Sie finden eine dauerhafte Lösung.

Die Konsole erhält mdworkerungefähr jede Sekunde einen neuen Eintrag - ist das normal, während eine Sicherung durchgeführt wird?

Edit 2: Erfolgreich! Der Laptop hat zwei Benutzerkonten und es kann sein, dass die Anmeldung beim zweiten dazu geführt hat, dass die restlichen Sicherungen fortgesetzt wurden. Es lohnt sich zu testen, wenn Sie in einer ähnlichen Situation sind.

Ich habe das gleiche Problem und ich habe eine Lösung gefunden (nicht wunderbar, aber es funktioniert)

Formatieren Sie Ihre externe Festplatte und überprüfen Sie, ob Sie eine wirklich gute Bandbreite haben (testen Sie Ihr USB3) Achten Sie auf Ihre TM-Einstellungen, hier habe ich so viele andere Partitionen und Disk-Images vergessen, die ich nicht sichern möchte, es würde die Backzeit verlängern . Starten Sie das erste Backup. Starten Sie Ihren Computer ALLE 2-3 Stunden neu. (Ja, macht keinen Spaß, aber ich habe festgestellt, dass die erste Stunde normalerweise schnell ist und danach langsamer wird.) Das ist alles, ich konnte 1,5 To an einem Morgen sichern. .

Bitte beachten Sie diesen Hinweis von Apple :

OS X El Capitan: Wenn Time Machine langsam ist

Probieren Sie diese Vorschläge aus, wenn Time Machine langsam ist.

• Wenn Sie Time Machine zum ersten Mal verwenden, richten Sie es abends ein, damit die erste Sicherung über Nacht erfolgen kann.

• Wenn Ihre Backup-Festplatte eine Time Capsule ist, lassen Sie Ihren Mac für die erste Sicherung im selben Raum wie die Time Capsule oder verwenden Sie ein Ethernet-Kabel, um Ihren Mac mit einem der Ethernet-Anschlüsse der Time Capsule zu verbinden.

• Virenscanner-Software kann Backups von Time Machine sehr langsam machen. Wenn Sie Norton AntiVirus oder ein ähnliches Produkt verwenden, versuchen Sie, Ihre Backup-Festplatte vom automatischen Scannen auszuschließen. Stellen Sie außerdem sicher, dass Sie die neueste Version der Virenscan-Software verwenden.