Wer Arbeitsordner vom Mac auf eine externe SSD auslagert, hat danach mehr Platz auf der internen SSD und oft das Gefühl, die Daten seien jetzt „extern“ und damit irgendwie sicherer. Das Gegenteil kann der Fall sein. Ausgelagerte Daten liegen weiterhin nur einmal vor, nur eben auf einem Gerät, das an einem Kabel hängt, gelegentlich in eine Tasche wandert und herunterfallen kann. Und das Backup, das bisher alles erfasst hat, erfasst sie womöglich nicht mehr.
Dieser Beitrag erklärt, warum das so ist, wie Time Machine mit ausgelagerten Ordnern umgeht, welche Daten wirklich eine zweite Kopie brauchen und wie ein realistisches Backup-Konzept für einen Entwickler-Mac mit externer SSD aussieht.
Ein Umzug ist keine Kopie
Beim Auslagern werden Daten verschoben, nicht vervielfältigt. Nach dem Umschalten existiert deine Arbeitskopie auf der SSD, und am alten Ort steht nur noch ein symbolischer Link. Ein vorübergehend aufbewahrtes Original ändert daran wenig: Es spiegelt den Stand vom Zeitpunkt des Umzugs, nicht deine Arbeit danach, und spätestens mit der Freigabe verschwindet es.
In DevSpace Manager, unserer macOS-App von BRUNIQO, heißt dieser aufbewahrte Stand Quarantäne. Er dient einem möglichen Rollback, falls nach dem Umzug etwas nicht funktioniert. Ein Backup ist er nicht: Er liegt auf demselben Mac, er wird nicht fortgeschrieben, und er wird gelöscht, sobald du die Freigabe bestätigst. Deshalb steht auf der Übersichtsseite der App ausdrücklich: Die Auslagerung ersetzt kein unabhängiges Backup.
Wie Time Machine mit ausgelagerten Ordnern umgeht
Time Machine ist für viele Mac-Nutzer die Grundsicherung. Zwei Eigenschaften sind nach dem Auslagern entscheidend.
Erstens sichert Time Machine einen symbolischen Link als Link. Im Backup deiner internen SSD steht an der Stelle von ~/Projekte nur noch der Verweis auf /Volumes/Arbeit-SSD/Projekte, nicht die Dateien selbst. Stellst du später aus diesem Backup wieder her, bekommst du einen Wegweiser zurück, aber keine Projekte.
Zweitens schließt Time Machine externe Laufwerke standardmäßig aus. Eine neu angeschlossene SSD landet auf der Ausschlussliste, ohne dass du etwas tun musst. Die Daten auf der SSD werden also nicht gesichert, bis du das änderst.
Die Lösung ist einfach, wenn man sie kennt: Öffne die Time-Machine-Einstellungen, rufe die Optionen auf und entferne die SSD aus der Liste der ausgeschlossenen Objekte. Wo genau die Schaltflächen liegen, unterscheidet sich je nach macOS-Version leicht. Achte danach darauf, dass dein Backup-Laufwerk groß genug ist, denn es muss jetzt die interne und die externe SSD aufnehmen. Prüfe nach der nächsten Sicherung stichprobenartig, ob ausgelagerte Dateien tatsächlich im Backup auftauchen.
Nutzt du ein anderes Backup-Programm, stellst du dort dieselben zwei Fragen: Folgt es symbolischen Links oder sichert es nur den Link? Und ist das externe Laufwerk in der Auswahl der gesicherten Orte enthalten?
Eine SSD für Arbeitsdaten und Backup?
In Foren taucht regelmäßig die Frage auf, ob man eine große externe SSD gleichzeitig für Time Machine und als Speicher nutzen kann. Technisch ist das mit getrennten Volumes möglich. Als Sicherung taugt es trotzdem wenig. Ein Backup soll dich vor dem Verlust eines Geräts schützen. Liegen Original und Sicherung auf derselben SSD, verlierst du bei einem Defekt, einem Sturz oder einem Diebstahl beides zugleich.
Für ausgelagerte Arbeitsdaten gilt deshalb: Die Arbeits-SSD und das Backup-Laufwerk sind zwei verschiedene Geräte. Das Backup-Laufwerk muss nicht dauerhaft angeschlossen sein, es sollte aber regelmäßig zum Einsatz kommen. Eine Sicherung, die nur einmal im Quartal läuft, schützt die Arbeit der letzten Wochen nicht.
Was wirklich ins Backup gehört
Nicht alles, was auf eine externe SSD umzieht, braucht eine zweite Kopie. Entscheidend ist, ob sich die Daten neu erzeugen lassen.
| Daten | Ins Backup? | Warum |
|---|---|---|
| Projektordner | ja | Ein Git-Remote enthält nur, was committet und gepusht ist, nicht lokale Branches, Stashes oder ungetrackte Dateien. |
| Xcode-Archive | ja | Die Debug-Symbole ausgelieferter Builds brauchst du für Absturzberichte, und du kannst sie nicht einfach neu erzeugen. |
| Medienbibliotheken | ja | Fotos, Videos und Audioaufnahmen sind oft Unikate. |
| DerivedData | nein | Xcode baut den Inhalt beim nächsten Build neu auf. |
Paket-Caches und node_modules | nein | Sie lassen sich aus Paketquellen und Lockfiles wiederherstellen. |
| Simulator-Runtimes | nein | Xcode kann sie erneut laden. |
| Docker-Images | meist nein | Sie lassen sich neu bauen oder laden; Daten in Docker-Volumes dagegen gehören gesichert. |
Regenerierbare Ordner kannst du bewusst vom Backup ausschließen. Time Machine erlaubt dafür eigene Einträge in der Ausschlussliste. Das spart Platz auf dem Backup-Laufwerk und Zeit bei jeder Sicherung. Schließe aber nur aus, was du wirklich neu erzeugen kannst, und nicht den ganzen Projektordner, nur weil darin auch node_modules liegt.
Besondere Vorsicht verdienen Dateien mit Zugangsdaten, etwa .env-Dateien in Projekten. Sie gehören in ein verschlüsseltes Backup und nicht in ungesicherte Kopien auf wechselnden Laufwerken.
Git ist kein Backup, aber ein guter Baustein
Viele Entwickler verlassen sich darauf, dass ihr Code ohnehin auf einem Git-Server liegt. Für den committeten und gepushten Stand stimmt das. Alles andere fehlt dort: Änderungen, die noch nicht committet sind, lokale Branches, Stashes, ungetrackte Dateien, lokale Konfiguration und alles, was bewusst in .gitignore steht. Gerade in einem Projektordner, der vor Kurzem auf eine SSD umgezogen ist, steckt oft genau diese Arbeit der letzten Tage.
Häufiges Pushen verkleinert das Risiko, ersetzt aber kein Backup des gesamten Projektordners. Umgekehrt ersetzt ein Backup nicht die Versionsgeschichte, die Git dir gibt. Beides zusammen deckt den Alltag gut ab.
Den Ernstfall einmal durchdenken
Stell dir vor, die SSD fällt morgen aus. Was müsstest du tun, um weiterzuarbeiten? Du bräuchtest ein Ersatzlaufwerk, die Daten aus deinem Backup und eine Liste, welche Ordner auf der SSD lagen und wohin die Links zeigten. Regenerierbare Daten wie DerivedData oder node_modules entstehen danach von selbst neu. Wer Liste und Backup hat, verliert im schlimmsten Fall ein paar Stunden. Wer sie nicht hat, verliert womöglich Arbeit, die sich nicht wiederherstellen lässt.
Halte deshalb fest, welche Ordner du ausgelagert hast und wohin. Eine kurze Textdatei genügt, solange sie selbst im Backup liegt und nicht nur auf der SSD.
Die 3-2-1-Regel, pragmatisch
Eine bewährte Faustregel für Backups lautet 3-2-1: drei Kopien deiner Daten, auf zwei verschiedenen Medien, eine davon außer Haus. Für einen Entwickler-Mac mit externer SSD kann das so aussehen: Die Arbeitskopie liegt auf der SSD, eine Time-Machine-Sicherung auf einem zweiten Laufwerk, und eine dritte Kopie liegt an einem anderen Ort, etwa bei einem Online-Backup-Dienst oder auf einem Laufwerk, das du regelmäßig mit einem zweiten tauschst.
Das klingt nach Aufwand, ist aber vor allem eine Frage der Einrichtung. Einmal eingerichtet, sichert Time Machine automatisch, sobald das Backup-Laufwerk verbunden ist. Die dritte Kopie muss nicht täglich aktualisiert werden, sollte aber nicht monatelang veralten. Wichtig ist, dass du weißt, wie alt deine jüngste Kopie außer Haus ist.
Verschlüsselung nicht vergessen
Eine externe SSD, die mit dem MacBook unterwegs ist, kann verloren gehen. Das Festplattendienstprogramm bietet APFS auch in einer verschlüsselten Variante an; beim Anschließen fragt macOS dann nach dem Passwort. Time Machine kann Backups ebenfalls verschlüsseln. Beides schützt nicht vor Datenverlust, aber davor, dass Fremde deine Projekte, Zugangsdaten oder Kundendaten lesen können. Bewahre die Passwörter so auf, dass du sie im Ernstfall findest, denn ohne Passwort ist auch deine eigene Sicherung wertlos.
Die Wiederherstellung einmal üben
Ein Backup ist erst dann eines, wenn die Wiederherstellung funktioniert. Nimm dir nach dem Auslagern einmal die Zeit, einen einzelnen Ordner aus der Sicherung der SSD zurückzuholen. Öffne dazu Time Machine, wechsle zu einem Zeitpunkt nach dem Umzug und stelle eine Datei an einem neuen Ort wieder her. Prüfe, ob sie vollständig und lesbar ist. So merkst du rechtzeitig, falls die SSD doch noch auf der Ausschlussliste steht oder das Backup-Laufwerk zu klein geworden ist.
Wiederhole diese Probe gelegentlich, vor allem nach größeren Änderungen: einer neuen SSD, einem neuen Backup-Laufwerk oder einem macOS-Update, das die Einstellungen verändert haben könnte.
Wann das Original gelöscht werden darf
Die Reihenfolge ist entscheidend. Lösche das aufbewahrte Original erst, wenn drei Bedingungen erfüllt sind: Die Kopie auf der SSD wurde vollständig geprüft, du hast mit dem neuen Aufbau eine Weile normal gearbeitet, und dein Backup enthält die Daten auf der SSD. Wie eine gründliche Prüfung aussieht, beschreibt die Seite Kopierte Ordner per Prüfsumme prüfen.
Wie lang die Probezeit sein sollte, hängt von den Daten ab. Bei Projektordnern, mit denen du täglich arbeitest, zeigt sich nach einigen normalen Arbeitstagen, ob alles funktioniert. Bei Archiven, die du selten öffnest, ersetzt ein gezielter Test die Probezeit: ein Archiv im Organizer öffnen, eine Datei aus der Medienbibliothek abspielen.
DevSpace Manager bildet diese Reihenfolge ab: Die App vergleicht Quelle und Ziel vollständig, bevor sie umschaltet, und die Freigabe des Originals erfordert eine eigene Bestätigung, vor der die Daten auf der SSD erneut geprüft werden. Ob dein Backup die SSD enthält, kann die App aber nicht für dich entscheiden. Das bleibt deine Aufgabe.
Was DevSpace Manager beiträgt und was nicht
Die Sicherungsmechanismen der App schützen den Umzug: ein vollständiger Dateivergleich mit SHA-256-Prüfsummen, ein Transaktionsjournal für jede Phase, die Quarantäne des Originals, ein Rollback und eine Prüfung der Volume-Identität, die Änderungen bei fehlender oder falscher SSD blockiert. Sie schützen nicht die Daten auf der SSD, nachdem der Umzug abgeschlossen ist. Fällt die SSD Monate später aus, hilft nur ein Backup.
Wie du die SSD im Alltag stabil betreibst, beschreibt die Seite Externe SSD dauerhaft am Mac. DevSpace Manager ist für den Mac App Store vorgesehen und derzeit noch nicht veröffentlicht; alle Funktionen findest du auf der Übersichtsseite der App.
Checkliste für ausgelagerte Daten
- Die externe SSD steht nicht mehr auf der Ausschlussliste von Time Machine.
- Das Backup-Laufwerk ist ein anderes Gerät als die Arbeits-SSD und groß genug für beide Datenbestände.
- Regenerierbare Ordner wie DerivedData und Paket-Caches sind bewusst ausgeschlossen, Projekte und Archive nicht.
- Eine dritte Kopie wichtiger Daten liegt an einem anderen Ort.
- Eine Liste der ausgelagerten Ordner und ihrer Ziele liegt selbst im Backup.
- Portable Laufwerke und Backups sind verschlüsselt, die Passwörter sicher verwahrt.
- Du hast mindestens einmal eine Datei aus der Sicherung der SSD wiederhergestellt.
- Das Original wird erst gelöscht, wenn Prüfung, Probezeit und Backup abgeschlossen sind.
DevSpace Manager
Große Arbeitsordner auf eine dauerhaft angeschlossene SSD auslagern: mit Dateiprüfung, Transaktionsjournal und aufbewahrtem Original für einen möglichen Rollback.
Zur App ↗