Externe Festplatte schläft ein, obwohl «Ruhezustand für Festplatten» aus ist

René Zuch · 21. Oktober 2026

Du greifst auf die externe Platte zu, und der Mac steht. Der Finder zeigt den Regenbogen, zehn Sekunden vergehen, dann ist alles wieder normal. Beim nächsten Mal dasselbe.

Die naheliegende Lösung steht in jedem Forenbeitrag: Systemeinstellungen → Batterie → «Festplatten in den Ruhezustand versetzen» ausschalten. Oder, auf der Kommandozeile:

sudo pmset -a disksleep 0

Bei manchen hilft das. Bei vielen ändert es nichts. Und wer zu den letzteren gehört, findet im Netz vor allem Leute, die ihm versichern, es müsse doch funktionieren.

Es gibt zwei Zeitgeber, nicht einen

Eine externe Festplatte kann aus zwei verschiedenen Gründen einschlafen.

macOS kann es anordnen. Das ist der Zeitgeber, den disksleep steuert. Steht er auf 0, verlangt das System von der Platte nie, dass sie einschläft.

Die Platte kann es selbst entscheiden. In der Firmware — der Platte selbst oder des Gehäuses, in dem sie sitzt — steckt ein eigener Leerlauf-Zeitgeber. Er zählt, wie lange kein Zugriff kam, und lässt die Platte dann einschlafen. Dass dieser Zeitgeber in der Platte sitzt und nicht im Rechner, ist kein Geheimwissen: die Dokumentation des Linux-Werkzeugs hdparm beschreibt den entsprechenden ATA-Wert mit «This timeout value is used by the drive to determine how long to wait».¹

Dieser zweite Zeitgeber ist von aussen meist weder sichtbar noch abschaltbar. Und die macOS-Einstellung erreicht ihn bei vielen Gehäusen nicht.

Die Belege gehen in beide Richtungen — und das muss man wissen

Ich habe mir die Mühe gemacht, gezielt nach Gegenbelegen zu suchen, bevor ich diesen Beitrag schreibe. Das Ergebnis ist unbequem:

Dafür: Western Digital nennt für seine Gehäuse ausdrücklich einen eigenen «Sleep Timer» in der Firmware.² Es gibt also herstellerseitig bestätigte Firmware-Zeitgeber.

Dagegen: Derselbe Hersteller schreibt im gleichen Dokument, dass die Einstellungen des Betriebssystems Vorrang hätten. Und ein Gehäusehersteller behauptet frei heraus, der Platten-Ruhezustand werde «entirely by macOS» verwaltet.³

Und dann das Muster, das mich überzeugt hat: Im Apple-Forum melden Nutzer Erfolg mit pmset -a disksleep 0 — und widerrufen das Stunden später im selben Beitrag. «Seems I spoke too soon — HDDs went to sleep again», schreibt einer, und kommt für seine Gehäuse zum Schluss: der Ruhezustand sitze in deren Firmware.⁴

Das ist der eigentliche Grund, warum du zu diesem Thema widersprüchliche Ratschläge findest: beide Lager haben recht, nur über verschiedene Gehäuse. Und weil ein Erfolg erst nach Stunden widerlegt wird, melden viele ihn zu früh.

Was heisst das für dich? Dass du es bei dir selbst nachmessen musst. Fremde Erfolgsmeldungen taugen hier nichts.

Der Beleg bei mir

Auf meinem eigenen Mac steht die Einstellung seit Monaten aus:

$ pmset -g custom | grep disksleep
 disksleep            0

Trotzdem hat meine Time-Machine-Platte in dreissig Tagen 777-mal einen Zugriff gehabt, der dem Muster eines Anlaufs entspricht: nach mindestens zwei Minuten Ruhe, mit wenigen Operationen, und mit einer gemessenen Dauer von im Mittel knapp zehn Sekunden. Die Einstellung war die ganze Zeit aus.

Ein Teil davon geht auf Time Machine selbst zurück — die stündliche Sicherung weckt die Platte, und dabei sass niemand davor. Die Zahl belegt deshalb, dass die Platte trotz abgeschalteter Einstellung einschläft; sie belegt nicht, dass 777-mal jemand gewartet hat.

Wie du es bei dir selbst nachmisst — ohne Werkzeug

Du brauchst dafür nichts zu installieren. Die Methode ist simpel: Beschäftige die Platte, warte eine feste Zeit, greif wieder zu und stoppe die Dauer.

Schritt 0, und der ist der wichtigste: Sorg für Ruhe. Solange ein anderes Programm die Platte anfasst, misst du nichts als dessen Betriebsamkeit. Wer gerade offene Dateien darauf hat, verrät dieser Befehl:

lsof +D /Volumes/MeinePlatte

Beende, was dort auftaucht — und schalte ein etwaiges Wachhalte-Programm für diese Platte ab. Dann:

# Pfad anpassen
P=/Volumes/MeinePlatte

# Platte beschäftigen
dd if=/dev/zero of="$P/.test" bs=1m count=8 2>/dev/null; sync

# warten — hier 60 Sekunden
sleep 60

# und zugreifen, mit Zeitmessung
time dd if=/dev/zero of="$P/.test2" bs=64k count=1 conv=fsync 2>/dev/null

Antwortet der zweite Schreibvorgang in Millisekunden, war die Platte noch wach. Dauert er mehrere Sekunden, musste sie anlaufen — dann ist sie in der Wartezeit eingeschlafen.

Wiederhole das mit 30, 60, 120, 240 Sekunden Pause. Irgendwo dazwischen liegt der Zeitgeber deines Gehäuses. Räum die Testdateien hinterher weg.

Rechne mit einer Überraschung. Bei mir schläft eine Platte nach unter 45 Sekunden ein. Die Ratschläge im Netz gehen fast immer von rund zehn Minuten aus — das ist der Wert, den macOS voreingestellt hat, nicht der des Gehäuses.

«Bleibt wach» ist auch ein Ergebnis

Ich habe die Anleitung an einer meiner Platten durchlaufen lassen, und sie meldete über alle vier Stufen hinweg 0,03 Sekunden — die Platte war nie weg. Der Grund: Es ist eine SSD.

Flash-Speicher schläft nicht ein. Es gibt keinen Motor, der anlaufen müsste, und damit auch das Problem nicht. Das ganze Thema betrifft drehende Platten. Wenn dein Test durchweg Millisekunden meldet, prüf zuerst, was du da überhaupt vor dir hast:

diskutil info /Volumes/MeinePlatte | grep -i "solid state"

Steht dort Yes, bist du fertig — deine Platte hat dieses Problem nicht, und jedes Werkzeug, das sie «wachhält», schreibt ohne Grund auf deine SSD.

Und noch ein Ergebnis, das keines war

Danach habe ich es an einer drehenden USB-Platte wiederholt — und wieder Millisekunden gemessen, bei 20, 45 und 90 Sekunden Pause. Diesmal lag es nicht an der Platte. Es lag daran, dass Lightroom im Hintergrund lief und eine Datei auf genau dieser Platte offen hatte. lsof +D hätte mich vorher gewarnt; ich hatte den Schritt übersprungen.

Ich schreibe das hin, weil es der wahrscheinlichste Fehler bei dieser Messung ist: «bleibt wach» heisst nicht immer «schläft nicht ein». Es kann auch heissen, dass etwas anderes sie wachhält. Prüf es, bevor du dein Gehäuse freisprichst.

Was tatsächlich hilft

Wenn der Zeitgeber nicht abschaltbar ist, bleibt nur, ihn zurückzusetzen: regelmässig auf die Platte schreiben, bevor er abläuft. Dabei gibt es drei Fallstricke, an denen einfache Lösungen scheitern.

Fallstrick 1: Der Schreibvorgang erreicht das Medium nicht

Ein kleiner Schreibvorgang landet im Zwischenspeicher — des Betriebssystems oder des Gehäuses — und wird dort zusammengefasst. Das Medium sieht unter Umständen gar keinen Zugriff, und der Zeitgeber läuft ungerührt weiter.

Das ist keine Theorie, Apple schreibt es selbst. Zu fsync(): «the drive itself may not physically write the data to the platters for quite some time».⁵ Die Abhilfe heisst fcntl(fd, F_FULLFSYNC) — und Apple nennt auch die ausdrücklich nur eine Bitte: der Aufruf «asks the drive to flush all buffered data», und «certain FireWire drives have also been known to ignore the request».⁶ In der Shell kommt conv=fsync bei dd dem nahe; im Testbefehl oben steht es deshalb.

Der sauberste Nachweis dafür, dass ein zu zahmer Zugriff nichts bewirkt, stammt vom Entwickler eines der unten genannten Programme. Er hielt es im eigenen Quelltext fest, nachdem er es an seiner Hardware reproduziert hatte: Das Lesen einer gerade geschriebenen 8-Byte-Datei werde «served from RAM in ~0ms and never touches the disk, so the drive slept.» Sein Zeitgeber feuerte alle 30 Sekunden, der Zugriff dauerte 0 ms — und die Platte schlief trotzdem ein.⁷

Fallstrick 2: Das Intervall ist geraten

Das ist der häufigere Fehler. Wer alle fünf Minuten schreibt, aber ein Gehäuse hat, das nach 45 Sekunden einschläft, hält die Platte nicht wach — er weckt sie alle fünf Minuten auf. Das ist schlimmer als nichts zu tun: dieselbe Wartezeit, nur jetzt auch nachts, wenn niemand davorsitzt.

Deshalb gehört die Messung vor die Massnahme. Ohne den gemessenen Wert ist jedes Intervall Glückssache.

Fallstrick 3: Eine Anweisung ans Betriebssystem ist kein Zugriff auf die Platte

Der dritte Fallstrick ist der grundlegendste, und er erklärt, warum der häufigste Ratschlag ins Leere geht. macOS kennt Anweisungen, mit denen ein Programm dem System das Einschlafen verbieten kann — auch das der Platten. Eine solche Anweisung ist aber eine Mitteilung an die Energieverwaltung des Rechners, kein Zugriff auf das Laufwerk. Der Zeitgeber in der Platte zählt davon unbeeindruckt weiter.

Das ist nicht meine Auslegung, sondern Apples eigene: in der Kopfdatei zu genau dieser Anweisung steht, sie hebe den Energiezustand der Platte nicht an, und der Aufrufer solle zusätzlich echte Zugriffe machen.⁸ Welches Programm das tut und welches nicht, steht im nächsten Abschnitt.

Die Werkzeuge, ehrlich verglichen

Ich habe für diesen Abschnitt nicht die Werbetexte verglichen, sondern dort nachgesehen, wo es nachprüfbar ist: in Apples eigenen Kopfdateien, in Man-Pages, und bei einem der Programme im offenen Quelltext. Wo ich nichts nachprüfen konnte, schreibe ich das hin.

caffeinate -m — mitgeliefert, und meistens das Falsche

Das ist die Antwort, die du in den Foren am häufigsten findest, oft als beste markiert. Was der Schalter tut, lässt sich genau sagen. Die Man-Page: «Create an assertion to prevent the disk from idle sleeping.» Im Programm selbst stecken genau vier solche Namen; -m setzt den mit der Bezeichnung PreventDiskIdle. Mehr kann es nicht — es schreibt nichts auf die Platte und schickt ihr kein eigenes Kommando.

Und jetzt kommt der Satz, der das ganze Thema aufklärt. Apple dokumentiert zu genau dieser Anweisung in der eigenen Kopfdatei IOPMLib.h:

«This assertion doesn't increase a disk's power state (it just prevents that device from idling). After creating this assertion, the caller should perform disk I/O on the necessary drives to ensure that they're in a usable power state.»⁸

Apple sagt also selbst: die Anweisung allein genügt nicht, es braucht zusätzlich echte Zugriffe. caffeinate -m macht diese Zugriffe nicht.

Dazu passt eine Beobachtung, die ich reizvoll finde. Im meistgelesenen Apple-Forenbeitrag zum Thema ist caffeinate -m als beste Antwort markiert — und der Fragesteller beantwortet seinen eigenen Beitrag anschliessend selbst damit, dass er das Problem mit einem anderen Programm gelöst habe.⁹ Die Sichtbarkeit dieser Antwort in Suchmaschinen stammt aus einem Beitrag, in dem sie nicht funktioniert hat.

Fair bleiben: Es gibt auch einen Erfolgsbericht, an einem Thunderbolt-Gehäuse.¹⁰ Für ein Gehäuse, dessen Zeitgeber macOS wirklich steuert, reicht der Befehl.

Amphetamine, «Drive Alive» — gratis, aber undurchsichtig

Das bekannteste Wachhalte-Programm für den Mac, gratis, und es hat eine Funktion namens «Drive Alive».

Was sie technisch tut, ist nicht öffentlich dokumentiert. Die gesamte offizielle Beschreibung besteht aus einem Satz; das Entwickler-Repository behandelt die Funktion nicht; die Rezension bei Macworld beschreibt nur die Wirkung, nicht den Mechanismus.¹¹

Wie wenig von aussen bekannt ist, zeigt ein Detail: Die einzige Beschreibung des Mechanismus, die ich überhaupt gefunden habe, stammt von einem Nutzer im Apple-Forum — und der beschreibt die Funktion als wiederholtes Lesen kleiner Dateien.¹² Lesen und Schreiben sind technisch verschiedene Dinge, und welches von beidem hier geschieht, sagt der Hersteller nirgends.

Zum Intervall finden sich nur Nutzerangaben. Ich nenne hier keine Zahl, weil ich keine belegen kann.

Wirksamkeit: Erfolgsmeldungen gibt es mehrere — und mindestens einen Nutzer, bei dem es nicht funktioniert hat.¹³ Was bei diesem Programm fehlt, ist nicht die Wirkung, sondern die Nachprüfbarkeit.

Drive Caffeine — gratis und offenliegend

Hier kann ich mehr sagen als bei allen anderen, weil der Quelltext offen ist. Nachgesehen, nicht der Werbung entnommen:⁷

• Es setzt keine Anweisung an die Energieverwaltung, sondern macht ausschliesslich echte Zugriffe.
• Standardmässig liest es: 64 KiB einer bereits vorhandenen Datei, und zwar mit abgeschaltetem Zwischenspeicher (F_NOCACHE) — genau der Fallstrick 1, umgangen.
• Ein optionaler Schreibmodus legt eine 8 Byte grosse versteckte Datei an und erzwingt das Durchschreiben mit F_FULLFSYNC.
• Intervall: 30 Sekunden voreingestellt, einstellbar zwischen 5 und 120 Sekunden.

Das ist handwerklich sauber und kostet nichts. Wenn du deinen Wert schon kennst und nur das Wachhalten brauchst, ist das eine gute Wahl — und ich sage das als jemand, der ein kostenpflichtiges Programm verkauft.

Wakeful — rund drei Franken, nicht nachprüfbar

Der Hersteller beschreibt die Arbeitsweise als «periodic, real disk I/O — genuine writes, not a fake ‚touch' that the OS can cache and ignore».¹⁴ Das klingt nach der richtigen Einsicht.

Nachprüfen kann ich es nicht: das Programm ist nicht quelloffen, ein Intervall nennt der Hersteller nirgends, und eine unabhängige Untersuchung gibt es nicht. Mehr als die Herstellerangabe habe ich dazu nicht.

DriveChief — mein eigenes, CHF 9

Hier bin ich befangen; lies den Abschnitt entsprechend.

Das Wachhalten selbst macht es wie Drive Caffeine: 64 KB schreiben, F_FULLFSYNC dahinter, voreingestellt alle 30 Sekunden, Minimum 10. Beim Abrunden auf den Maschinentakt geht es bewusst nach unten — zu früh schreiben kostet 64 KB, zu spät schläft die Platte ein.

Der Unterschied liegt nicht im Wachhalten, sondern davor: Es misst den Zeitgeber mit der Methode, die oben in diesem Beitrag steht — gestaffelte Pausen, Dauer des ersten Zugriffs — und übernimmt den gefundenen Wert als Intervall für genau diese Platte. Damit fällt Fallstrick 2 weg; das Intervall ist nicht mehr geraten. Und für SSDs bietet es das Wachhalten gar nicht an.

Es tut daneben noch anderes (Aufräumen, Zustandsprüfung, Netzlaufwerke), was hier nicht zur Sache gehört.

Kurz zusammengefasst

Offenlegung

Ich habe DriveChief geschrieben, eines der hier genannten Programme. Es soll CHF 9 im Mac App Store kosten; erschienen ist es, während ich das schreibe, noch nicht. Ich verdiene daran, wenn du es kaufst — also lies den Vergleich oben mit der gebotenen Skepsis.

Was mich zu dem Programm gebracht hat, war nicht das Wachhalten; das können andere auch, teils gratis, und ich habe oben hingeschrieben welche. Es war die Frage, wie oft das Problem bei mir überhaupt auftritt — und dass macOS darauf keine Antwort gibt.

Was sich nicht messen lässt

Zum Schluss die Grenzen, weil ein Ratgeber ohne sie nichts wert ist.

Ob die Platte wirklich eingeschlafen ist, lässt sich nicht direkt beobachten. Es gibt keinen Sensor, den man abfragen könnte. Man schliesst es aus dem Muster: lange Ruhe, dann ein erster Zugriff, der ungewöhnlich lange dauert. Das ist ein guter Schluss, aber ein Schluss.

Ob jemand gewartet hat, erst recht nicht. Dass kurz vorher eine Taste gedrückt wurde, heisst nicht, dass derselbe Mensch auf diese Platte gewartet hat.

SMART hilft hier nicht weiter. Die Zähler Start_Stop_Count (#4) und Load_Cycle_Count (#193) führen zwar Anläufe, aber nur als Summe über die Lebensdauer — ohne Zeitstempel, ohne Dauer, und das Auslesen spricht selbst mit der Platte.

Und das Systemprotokoll meldet etwas anderes. Es verzeichnet, wenn ein Prozess blockiert war — nicht, wenn eine Platte anlaufen musste. In meinem Messzeitraum standen 321 erkannten Anläufen sieben Protokolleinträge gegenüber, und keiner davon beschrieb einen der Anläufe.

Wo der zweite Zeitgeber genau sitzt, weiss ich nicht. Dass er in der Firmware der Platte oder des Gehäuses steckt, ist gut belegt. Verbreitet ist die genauere Behauptung, er sitze im Brückenchip des Gehäuses. Ich habe dafür kein Datenblatt gefunden, und sie wird vor allem von Anbietern solcher Programme wiederholt — also von interessierter Seite. Für die Praxis macht es keinen Unterschied; für die Genauigkeit dieses Beitrags schon.

Hast du andere Werte gemessen? Ich sammle sie — unterschiedliche Gehäuse, unterschiedliche Zeitgeber. Schreib mir.

Belege

1. hdparm(8), Beschreibung von -S — linux.die.net ↩
2. Western Digital, Support-Antwort 50916 (Sleep Timer in WD Drive Utilities) — support-en.wd.com ↩
3. OWC, Wissensdatenbank, «Why do my drives keep going to sleep» — software.owc.com ↩
4. Apple Support Communities, Beitrag 255263910 (Erfolgsmeldungen und deren Widerruf) — discussions.apple.com ↩
5. Apple, fsync(2) — developer.apple.com ↩
6. Apple, fcntl(2), Abschnitt F_FULLFSYNC — developer.apple.com ↩
7. Drive Caffeine, Quelltext (MIT) — · Zitat aus Sources/DriveCaffeineKit/ReadTarget.swift, Mechanik in DiskIO.swift und VolumeState.swift — github.com ↩ ↩
8. Apple, IOKitUser, pwr_mgt.subproj/IOPMLib.h, zu kIOPMAssertPreventDiskIdle — github.com ↩ ↩
9. Apple Support Communities, Beitrag 253815224 — discussions.apple.com ↩
10. Apple Support Communities, Beitrag 253434491 (Erfolg mit caffeinate -i -m an einem Thunderbolt-Gehäuse) — discussions.apple.com ↩
11. Macworld, Glenn Fleishman, Amphetamine-Rezension, 5.11.2021 — macworld.com ↩
12. Apple Support Communities, Beitrag 253434491 (widersprüchliche Beschreibungen von «Drive Alive») — discussions.apple.com ↩
13. Apple Support Communities, Beitrag 254821088 — discussions.apple.com ↩
14. Wakeful, Herstellerangabe im Mac App Store — apps.apple.com ↩