Cloud Mac mini vor Mietende migrieren: Backup und Umzug der Entwicklungsumgebung

Freitagnachmittag fragte der Kollege, der bei uns für Releases zuständig ist, kurz in den Chat: „Unser monatlich gemieteter Mac mini läuft nächsten Mittwoch aus – was passiert mit den Zertifikaten, den Simulator-Daten und dem Homebrew-Cache?" Niemand konnte spontan eine vollständige Liste liefern – genau das ist das typische Vorzeichen einer verpatzten Migration. Ein Cloud Mac mini fühlt sich im Alltag an wie ein normaler Rechner, aber viele Zustände gerät man beim Arbeiten aus dem Blick – erst am Tag des Abschlusses merkt man, dass sie über ein Dutzend Verzeichnisse verstreut sind.

Warum die Migration vor Mietende so oft scheitert

Die meisten verstehen unter „Migration" nur „Projektordner zurück auf den lokalen Rechner kopieren". Was den Build aber wirklich blockiert, ist meist die versteckte Konfiguration: die im ~/.ssh-Verzeichnis ausgestellten Deploy-Keys, die Distribution-Zertifikate im Schlüsselbund, der inkrementelle Build-Index unter ~/Library/Developer/Xcode/DerivedData sowie diverse Cache-Pfade, die Tools still und heimlich im Home-Verzeichnis anlegen. Im Alltag fällt das nicht auf – sobald die Maschine aber nach Vertragsende freigegeben wird, sind diese Daten unwiederbringlich weg.

Migration bedeutet nicht „Dateien sichern", sondern „eine sofort arbeitsfähige Maschine reproduzieren". Der Maßstab ist nicht „sind alle Dateien kopiert", sondern „liefert ein Build auf der neuen Maschine dasselbe Ergebnis wie auf der alten".

Asset-Inventar vor der Migration: Was unbedingt mitgenommen werden muss

Teilen Sie die mitzunehmenden Dinge zunächst in zwei Kategorien – allein diese Einteilung reduziert schon das Risiko, etwas zu übersehen.

Konfiguration der Entwicklungsumgebung

Dazu zählen die Shell-Konfiguration (.zshrc/.zprofile), SSH-Keys samt known_hosts, die globale Git-Konfiguration mit Credentials, Xcode-Signaturzertifikate und Provisioning-Profiles sowie über den security-Befehl exportierte Schlüsselbund-Einträge. Diese Dateien sind klein, aber unverzichtbar – am besten packt man sie in ein eigenes Archiv.

Projekt- und Dependency-Caches

Dazu gehören Code-Repositories (theoretisch sollten diese vollständig remote liegen, aber lokal noch nicht gepushte Branches müssen zusätzlich geprüft werden), lokale CocoaPods- und SwiftPM-Caches, die Liste der über Homebrew installierten Pakete (ein per brew bundle dump exportiertes Brewfile ist deutlich günstiger als das komplette /opt/homebrew-Verzeichnis zu kopieren) sowie Lock-Dateien wie Podfile.lock und .xcode-version.

Dreistufige Backup-Strategie: rsync-Inkrement + tar-Archiv + Snapshot-Download

Verlassen Sie sich nicht auf ein einziges Mittel für alle Szenarien – erst die Kombination aus drei Ebenen ist wirklich verlässlich.

Inkrementelle Synchronisation mit rsync

Lokal initiiert, synchronisieren Sie die wichtigen Verzeichnisse des Mac mini auf den eigenen Rechner oder einen Object-Storage-Mountpoint:

rsync -avz --delete \
  --exclude 'DerivedData' \
  --exclude 'node_modules' \
  dev@hk1.oncemini.com:~/projects/ \
  ~/backup/mac-mini-hk1/projects/

Wenn Sie regenerierbare Verzeichnisse wie DerivedData und node_modules ausschließen, sinkt die Sync-Zeit von mehreren zehn Minuten auf wenige Minuten. Es empfiehlt sich, eine Woche vor Vertragsende täglich einen Sync zu fahren, statt erst am letzten Tag den ersten Durchlauf zu starten – die Dauer des ersten vollständigen Syncs wird regelmäßig unterschätzt.

Unveränderliche Archive packen

Für Zertifikate und Keys, die sich selten ändern, aber unter keinen Umständen verloren gehen dürfen, packen Sie separat und verschlüsseln:

tar czf keychain-backup.tar.gz \
  ~/Library/Keychains \
  ~/.ssh
gpg -c keychain-backup.tar.gz

Das verschlüsselte Archiv geht anschließend per rsync oder Direktdownload weiter, sodass Klartext-Keys nicht ungeschützt auf der Übertragungsstrecke landen.

Plattform-Snapshot-Download als letzte Absicherung

Falls die beiden ersten Ebenen aus Netzwerkgründen nicht durchlaufen konnten, kann der komplette Systemsnapshot-Download aus der Konsole als letzte Sicherung dienen – kalkulieren Sie das Volumen aber vorher ein: Eine 512-GB-Systemplatte kann über eine Heimbandbreite mehrere Stunden zum Download benötigen. Planen Sie unbedingt Puffer ein und starten Sie nicht erst wenige Stunden vor Vertragsende.

Häufige Fallstricke und Checkliste

• Das per brew bundle dump erzeugte Brewfile wird nicht exportiert, sodass auf der neuen Maschine alle Pakete aus dem Gedächtnis nachinstalliert werden müssen – Versionsnummern passen dann nicht mehr.
• Nur der Projektcode wird gesichert, die lokalen Umgebungsvariablen aus .env fehlen, sodass der Build auf der neuen Maschine wegen fehlender Konfiguration fehlschlägt.
• rsync läuft mit normalen Benutzerrechten, wodurch die Leseberechtigung für systemweite Zertifikatsdateien fehlt – das Archiv ist dann unvollständig, ohne dass eine Fehlermeldung erscheint.
• Der Snapshot-Download wird erst wenige Stunden vor Vertragsende gestartet, und bei Bandbreitenschwankungen reicht die Zeit nicht mehr.
• Nach der Migration werden Keys und Tokens auf der alten Maschine nicht bereinigt – nach Vertragsende bleiben diese Credentials theoretisch weiterhin gültig, was ein Sicherheitsrisiko darstellt. Sie sollten beim letzten Login aktiv widerrufen werden.

Kaltstart-Verifikation auf der neuen Maschine

Der Umzug allein reicht nicht – erst ein vollständiger Verifikationslauf in der neuen Umgebung schließt die Migration wirklich ab:

brew bundle install --file=Brewfile
pod install --repo-update
xcodebuild -workspace App.xcworkspace \
  -scheme App -configuration Release \
  clean build
shasum -a 256 build/App.app/App

Vergleichen Sie die shasum-Ausgaben aus altem und neuem Build – nur bei Übereinstimmung ist die Migration wirklich abgeschlossen. Dieser Schritt wird oft ausgelassen, ist aber der einzige objektive Beweis dafür, dass in der Umgebung nichts verloren gegangen ist – deutlich verlässlicher als der bloße Eindruck „scheint zu laufen".

Häufig gestellte Fragen