Migrer un Mac mini cloud avant la fin de location : sauvegarde et transfert d'environnement

Vendredi après-midi, le collègue chargé des mises en production a posé la question dans le chat de l'équipe : « Notre Mac mini loué au mois arrive à échéance mercredi prochain, qu'est-ce qu'on fait des certificats, des données du simulateur et du cache Homebrew ? » Personne n'a su répondre immédiatement avec une liste complète — c'est le signe annonciateur classique d'une migration qui va mal se passer. Un Mac mini cloud est agréable à utiliser au quotidien, mais beaucoup d'états s'accumulent « pendant qu'on l'utilise sans y penser », et ce n'est que le jour de la clôture qu'on découvre qu'ils sont dispersés dans une dizaine de répertoires.

Pourquoi la migration en fin de location échoue si souvent

La plupart des gens comprennent la « migration » comme le simple fait de « recopier le dossier de projet en local ». Or, ce qui bloque réellement le build, c'est généralement la configuration cachée : les clés de déploiement émises dans ~/.ssh, les certificats de distribution stockés dans le Trousseau (Keychain), l'index de build incrémental sous ~/Library/Developer/Xcode/DerivedData, ainsi que les divers chemins de cache que les outils écrivent discrètement dans le répertoire utilisateur. Ces éléments passent inaperçus au quotidien, mais une fois la machine libérée à échéance, il devient impossible de les récupérer.

Migrer, ce n'est pas « sauvegarder des fichiers », c'est « reproduire une machine immédiatement opérationnelle ». Le critère n'est pas « tous les fichiers ont-ils été copiés », mais « un build lancé sur la nouvelle machine produit-il le même résultat que sur l'ancienne ».

Inventaire des actifs avant la migration : ce qu'il faut absolument emporter

Commencez par répartir ce qu'il faut emporter en deux catégories : cette classification permet déjà de réduire les oublis.

Configuration de l'environnement de développement

Cela comprend la configuration du shell (.zshrc/.zprofile), les clés SSH et le fichier known_hosts, la configuration Git globale et les identifiants, les certificats de signature Xcode et les profils de provisionnement, ainsi que les entrées du Trousseau exportées via la commande security. Ces fichiers sont légers mais indispensables : il est recommandé de les regrouper dans une archive dédiée.

Cache des projets et des dépendances

Cela inclut les dépôts de code (en théorie, tout devrait déjà être poussé sur le dépôt distant, mais il faut vérifier séparément les branches locales non poussées), les caches locaux de CocoaPods et SwiftPM, la liste des paquets installés via Homebrew (exporter un Brewfile avec brew bundle dump est beaucoup plus économique que de copier tout le répertoire /opt/homebrew), ainsi que les fichiers de verrouillage comme Podfile.lock et .xcode-version.

Stratégie de sauvegarde en trois couches : synchronisation incrémentale rsync + archive tar + téléchargement de snapshot

Ne comptez pas sur une seule méthode pour couvrir tous les scénarios : c'est la combinaison des trois couches qui garantit la fiabilité.

Synchronisation incrémentale avec rsync

Depuis votre poste local, synchronisez les répertoires clés du Mac mini vers votre machine ou un point de montage de stockage objet :

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

Exclure des répertoires régénérables comme DerivedData et node_modules permet de réduire le temps de synchronisation de plusieurs dizaines de minutes à quelques minutes seulement. Il est conseillé de lancer une synchronisation quotidienne dès la semaine précédant l'échéance, plutôt que d'attendre le dernier jour pour effectuer la première — la durée d'une première synchronisation complète est régulièrement sous-estimée.

Empaqueter des archives immuables

Pour les certificats et les clés, données qui changent rarement mais qu'on ne peut absolument pas se permettre de perdre, empaquetez-les séparément et chiffrez-les :

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

L'archive chiffrée passe ensuite par rsync ou un téléchargement direct, ce qui évite que des clés en clair ne transitent sur le réseau sans protection.

Le téléchargement de snapshot de la plateforme comme filet de sécurité

Si les deux premières couches n'ont pas pu se terminer pour des raisons réseau, le téléchargement complet du snapshot de la machine depuis la console peut servir de dernier recours — mais il faut estimer le volume au préalable : un disque système de 512 Go peut nécessiter plusieurs heures de téléchargement sur une connexion résidentielle. Prévoyez impérativement une marge de sécurité, sans attendre les dernières heures avant l'échéance pour vous lancer.

Pièges courants et liste de vérification

• Oublier d'exporter le Brewfile généré par brew bundle dump : sur la nouvelle machine, il faut alors réinstaller les logiciels de mémoire, avec des numéros de version qui ne correspondent plus.
• Ne sauvegarder que le code du projet, sans sauvegarder les variables d'environnement locales du fichier .env, ce qui provoque des erreurs de configuration manquante lors du build sur la nouvelle machine.
• Exécuter rsync avec des droits utilisateur ordinaires, en oubliant les droits de lecture nécessaires pour les fichiers de certificats système, ce qui rend l'archive incomplète sans qu'aucune erreur ne soit signalée.
• Ne commencer le téléchargement du snapshot que quelques heures avant l'échéance, et manquer de temps en cas de fluctuation de la bande passante.
• Ne pas nettoyer les clés et les jetons sur l'ancienne machine après la migration : après la fin de la location, ces identifiants restent théoriquement valides, ce qui constitue un risque de sécurité. Ils doivent être explicitement révoqués lors de la dernière connexion.

Vérification à froid sur la nouvelle machine après la migration

Le transfert terminé ne signifie pas que tout est joué : il faut effectuer une vérification complète dans le nouvel environnement pour clore réellement la migration :

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

Comparez les sorties shasum des deux builds, ancien et nouveau : ce n'est qu'en cas de correspondance exacte que la migration est réellement achevée. Cette étape est souvent négligée, alors qu'elle constitue la seule preuve objective que rien n'a été perdu dans l'environnement — bien plus fiable qu'une simple impression que « ça a l'air de fonctionner ».

Questions fréquentes