Mac mini M6 2026 : Time Machine suffit-il au serveur ?

Sur macOS, la documentation d’Ollama indique que ses modèles sont stockés dans ~/.ollama/models par défaut, et non dans un simple dossier de documents décrit dans sa documentation macOS. Ce seul emplacement suffit à montrer pourquoi Time Machine ne doit pas être la seule sauvegarde d’un Mac mini M6 2026 : il faut protéger séparément les fichiers, les volumes Docker, les bases applicatives, les index, les secrets et les modèles, puis vérifier qu’un autre Mac peut réellement remettre les services en ligne.

Notre conseil cette semaine : cartographiez les données persistantes, exportez une première copie applicative et effectuez une restauration logicielle sur une machine vierge avant de confier à ce serveur vos automatismes domestiques ou votre base documentaire.

Pour qui cette décision est-elle pertinente ?

Cet article s’adresse aux personnes qui veulent faire fonctionner un Mac mini M6 comme serveur familial permanent et redoutent une panne du disque, une réinstallation de macOS ou une corruption de Docker Desktop. Il concerne également les développeurs qui exécutent AnythingLLM et Ollama, ainsi que les petites équipes qui souhaitent tester leur plan de reprise sur un Mac distant temporaire avant de migrer la production.

Le Mac mini M6 a bien été annoncé par Apple, mais Apple indiquait une mise en vente à partir du 22 septembre 2026 dans son annonce du 25 août 2026 présentée dans Apple Newsroom. Nous ne prétendons donc pas disposer d’un test longue durée de sauvegarde ou de restauration sur ce modèle. Le raisonnement ci-dessous porte sur les couches logicielles documentées et reste valable pour un Mac mini déjà utilisé comme serveur.

Le bon critère : l’objectif de reprise

Une sauvegarde terminée avec succès ne signifie pas automatiquement qu’un service est restaurable. Nous séparons trois objectifs, car chacun exige un niveau de protection différent.

Apple décrit Time Machine comme un outil de sauvegarde des fichiers personnels, des applications, des photos, des courriels et de fichiers système dans son guide d’assistance. Cette couverture est utile pour l’hôte macOS, mais elle ne définit pas le comportement interne d’une base de données, d’un index vectoriel ou d’un volume géré par Docker.

Pour notre grille de décision, la question n’est donc pas « le fichier est-il présent dans la sauvegarde ? », mais plutôt : après restauration, le conteneur redémarre-t-il, retrouve-t-il ses données, conserve-t-il ses droits d’accès et produit-il le même résultat de recherche ?

La carte des données persistantes

Avant de choisir une fréquence ou un support, nous créons une carte qui distingue ce qui peut être régénéré de ce qui serait coûteux ou impossible à recréer.

Un volume nommé Docker est géré indépendamment du cycle de vie du conteneur ; Docker documente cette séparation entre le conteneur et le stockage persistant dans sa référence sur les volumes. Il serait donc imprudent de sauvegarder uniquement les fichiers Compose en supposant que docker compose up reconstituera la base et les données. Le fichier Compose reconstruit l’architecture ; il ne recrée pas les informations qui ont été ajoutées depuis le premier lancement.

Les bind mounts demandent une autre vérification. Leur contenu se trouve dans un répertoire de l’hôte, mais son emplacement exact, ses droits et son propriétaire doivent être conservés. Une archive qui restitue les fichiers avec des droits trop larges ou un mauvais utilisateur peut produire un conteneur « sain » en apparence, mais incapable d’écrire dans sa base.

Pour AnythingLLM, nous suivons la structure publiée dans le dépôt officiel : le stockage regroupe des éléments applicatifs qui ne doivent pas être traités comme une simple collection de documents voir la description du répertoire de stockage AnythingLLM. Les documents sources, la base de travail, les espaces de travail et les index doivent être considérés ensemble. Restaurer les PDF sans la base ou sans l’index peut laisser une interface accessible, tout en donnant des résultats incomplets.

Docker Desktop et la frontière de la machine virtuelle

Sur macOS, les conteneurs Linux ne s’exécutent pas comme des processus Linux natifs directement dans le noyau macOS. Docker Desktop s’appuie sur une machine virtuelle et présente ensuite les volumes et les partages à l’environnement de développement. Cette architecture crée une frontière importante entre les fichiers visibles dans le Finder, les bind mounts et les données internes de Docker Desktop.

Le dossier de la machine virtuelle Docker Desktop ne doit pas être confondu avec une sauvegarde applicative lisible. Une copie brute peut être volumineuse, dépendante de la version et difficile à réimporter sur un autre hôte. Docker fournit d’ailleurs une procédure distincte de sauvegarde et de restauration de ses données dans sa documentation de maintenance Docker Desktop. Nous utilisons cette documentation pour identifier la méthode compatible avec la version installée, au lieu de copier arbitrairement un fichier interne.

La règle de séparation est la suivante :

• les fichiers Compose et les scripts servent à reconstruire le déploiement ;
• les bind mounts doivent être sauvegardés depuis leurs répertoires sources ;
• les named volumes doivent être exportés ou sauvegardés avec une méthode adaptée ;
• le stockage interne de Docker Desktop doit être traité selon la procédure de la version installée ;
• les images peuvent souvent être retéléchargées, alors que les données utilisateur et les secrets ne le peuvent pas.

Les réglages de partage de fichiers et de ressources de Docker Desktop peuvent également modifier le comportement d’un projet lors de la restauration. Nous conservons donc une copie de la configuration pertinente et de la version de Docker Desktop, en nous appuyant sur la documentation officielle des paramètres Docker Desktop.

La cohérence avant la copie

Copier un répertoire pendant qu’une base ou un index est en train d’écrire ne constitue pas une preuve de sauvegarde valide. Une archive peut contenir tous les fichiers attendus, mais capturer des fichiers à des états différents : journal de transaction non associé, index partiellement écrit, base active et fichiers de documents modifiés à des moments distincts.

Pour une sauvegarde de Docker, nous procédons ainsi :

1. nous relevons les versions de macOS, Docker Desktop, des images et des applications ;
2. nous identifions les conteneurs qui écrivent réellement dans un volume ou un bind mount ;
3. nous suspendons les ingestions, les tâches automatiques et les écritures de l’interface ;
4. nous arrêtons les conteneurs concernés, sauf si l’application fournit une méthode d’export à chaud documentée ;
5. nous exportons les volumes et copions les répertoires sources ;
6. nous calculons ou vérifions une empreinte des archives, puis nous enregistrons leur composition ;
7. nous redémarrons les services et vérifions qu’aucune écriture n’a été perdue.

Pour AnythingLLM, l’ordre est essentiel : nous cessons l’ajout de documents, arrêtons le service, sauvegardons le stockage applicatif complet, puis conservons aussi les documents originaux dans une copie distincte. La présence d’un dossier nommé « documents » ne prouve pas que les espaces de travail, les associations et l’index sont cohérents.

Pour Ollama, nous décidons en fonction de la rematérialisation. Sa documentation indique l’emplacement macOS par défaut et explique également comment modifier l’emplacement de stockage dans la foire aux questions Ollama. Si le modèle peut être téléchargé à nouveau dans l’environnement de reprise, nous sauvegardons prioritairement la liste exacte des modèles, leurs versions ou identifiants, les réglages et les données métier. Si le serveur doit fonctionner hors ligne, ou si le téléchargement est trop incertain, les fichiers de modèles deviennent une copie prioritaire.

La séparation contre les pannes

Time Machine peut protéger contre certaines suppressions ou erreurs de configuration, mais son emplacement détermine la panne qu’il peut absorber. Une capture locale APFS sur le même disque n’est pas une protection contre la panne physique de ce disque. Un disque Time Machine continuellement connecté au Mac n’est pas une stratégie complète contre une surtension, un vol, un sinistre ou une erreur qui chiffre toutes les copies accessibles.

Cette matrice montre pourquoi nous combinons trois familles de copies : Time Machine pour la récupération quotidienne de l’hôte, une sauvegarde applicative pour la cohérence des services, puis une copie isolée pour éviter que le même incident détruise la source et la sauvegarde.

La restauration sur une machine vierge

Une restauration crédible commence dans un environnement qui ne connaît pas déjà les anciens volumes. Sur une seconde machine, nous installons une version compatible de macOS, Docker Desktop et les outils nécessaires, puis nous documentons chaque écart de version. Il ne faut pas masquer les problèmes en utilisant un Mac qui possède déjà les mêmes volumes ou les mêmes variables d’environnement.

La séquence opérationnelle comporte au moins les étapes suivantes :

1. Préparer l’environnement propre. Installer macOS et Docker Desktop, puis noter les versions exactes et les réglages de partage nécessaires.
2. Reconstituer l’arborescence. Restaurer les fichiers Compose, les scripts, les fichiers de configuration et les répertoires destinés aux bind mounts.
3. Rétablir les secrets avec prudence. Réinjecter les variables d’environnement, certificats et clés uniquement depuis la copie chiffrée prévue à cet effet ; vérifier leurs droits avant le démarrage.
4. Importer les volumes Docker. Utiliser la méthode d’export documentée, recréer les volumes avec les bons noms et contrôler leur propriétaire depuis le conteneur.
5. Relancer les services dans un ordre contrôlé. Démarrer les bases et dépendances avant les applications, puis examiner les journaux plutôt que de conclure à partir du seul état « démarré ».
6. Restaurer AnythingLLM. Remettre la base, les documents, le stockage des espaces de travail et les index selon la structure sauvegardée ; éviter une nouvelle ingestion tant que l’état existant n’est pas vérifié.
7. Rétablir Ollama. Reconnecter le stockage des modèles ou télécharger les modèles référencés dans l’inventaire, puis vérifier que l’application pointe vers le bon service.
8. Tester après redémarrage. Redémarrer Docker Desktop et le Mac, puis contrôler que les montages, les permissions et les services reviennent automatiquement.
9. Consigner le résultat. Enregistrer les archives utilisées, les contrôles d’empreinte, les erreurs rencontrées et la durée observée pour décider du niveau de couverture nécessaire.

L’acceptation ne se limite pas à un code HTTP positif. Nous vérifions l’état de santé des conteneurs, l’ouverture des espaces de travail AnythingLLM, la présence de l’historique, la recherche d’un document connu, la réponse du modèle local, les permissions d’écriture et la persistance après redémarrage. Pour un usage audio, vidéo ou design, nous ajoutons également un fichier représentatif : session audio, rush vidéo, bibliothèque de ressources ou projet graphique, car les chemins et les droits ne sont pas toujours identiques à ceux d’un simple document texte.

AnythingLLM sur un autre Mac

Le transfert d’AnythingLLM ne consiste pas à installer l’application puis à recopier quelques PDF. Nous préparons une archive comprenant le stockage applicatif, les documents originaux, la configuration nécessaire et la correspondance avec le moteur vectoriel utilisé. Après restauration, nous testons une question dont la réponse dépend d’un passage précis d’un document connu. Si la réponse n’est plus retrouvée, la reprise est considérée comme incomplète, même si l’interface affiche le bon nom d’espace de travail.

Cette méthode distingue trois résultats souvent confondus : l’application démarre, les données historiques sont visibles et la recherche sémantique fonctionne. Seul le troisième confirme que la chaîne documentaire a été restaurée de manière exploitable.

Tester Docker sans posséder un second Mac

Lorsqu’aucun Mac physique de secours n’est disponible, une instance Mac temporaire peut servir à valider la partie logicielle : installation, restauration des volumes, lancement des conteneurs, connexion à AnythingLLM et récupération des modèles Ollama. Cette démarche est particulièrement pertinente avant de déplacer un serveur familial déjà utilisé, car elle évite de faire une première tentative sur la machine de production.

Elle ne remplace toutefois pas un test physique. Une instance distante ne valide ni le branchement d’un disque externe, ni les ports locaux, ni le comportement après coupure électrique, ni l’accès aux accessoires USB ou au réseau domestique. Nous la considérons comme une répétition de reprise logicielle, pas comme une preuve de continuité matérielle. Pour préparer ce type d’essai, nous pouvons aussi consulter notre guide consacré à l’exécution d’un environnement de développement Apple isolé, puis organiser l’accès temporaire via les options de location de JexMac.

Le coût réel des modèles et des copies

Sauvegarder tous les répertoires par automatisme peut consommer beaucoup d’espace sans améliorer la reprise. Nous classons chaque élément avec quatre critères : impossibilité de le recréer, fréquence de modification, durée nécessaire pour le récupérer et taille de la copie.

Les documents originaux, les métadonnées AnythingLLM, les fichiers Compose et les secrets correctement protégés sont généralement prioritaires, car ils concentrent la valeur métier et l’état difficilement reproductible. Les images de conteneur peuvent souvent être téléchargées de nouveau, à condition de conserver leurs versions et de vérifier qu’elles restent disponibles. Les modèles Ollama se situent entre les deux : leur sauvegarde intégrale est justifiée pour un serveur hors ligne, un environnement soumis à des restrictions réseau ou une reprise qui doit être immédiate ; ailleurs, un inventaire précis peut suffire.

Nous séparons donc :

• une copie fréquente des documents et configurations modifiées ;
• une copie cohérente des bases et volumes après arrêt contrôlé ;
• une copie périodique des modèles selon la possibilité réelle de les télécharger ;
• une copie isolée, déconnectée ou distante, pour les scénarios de panne du Mac et du disque ;
• une répétition planifiée de restauration, déclenchée après une mise à jour majeure de macOS, Docker Desktop, AnythingLLM ou Ollama.

La liste de validation avant mise en service

• [ ] Les objectifs de reprise sont définis : fichier, machine complète et services.
• [ ] Les versions de macOS, Docker Desktop, Compose, AnythingLLM et Ollama sont consignées.
• [ ] Les fichiers Compose, scripts, variables d’environnement et secrets sont archivés séparément.
• [ ] Chaque bind mount possède un chemin source documenté et une copie vérifiée.
• [ ] Chaque named volume possède une méthode d’export et une procédure d’import testée.
• [ ] Le stockage AnythingLLM, les documents originaux et les index sont sauvegardés ensemble.
• [ ] L’emplacement des modèles Ollama et leur inventaire sont connus.
• [ ] Les écritures sont arrêtées ou exportées avec une méthode compatible avant la copie.
• [ ] Une copie se trouve hors du Mac et hors de son disque interne.
• [ ] Un environnement vierge a restauré au moins un service Docker.
• [ ] Une recherche AnythingLLM vérifie un document précis après restauration.
• [ ] Le fonctionnement a été contrôlé après redémarrage, avec les permissions attendues.
• [ ] Les limites du test distant sont notées si aucun Mac physique de secours n’est disponible.

Le choix recommandé selon le risque

Pour un serveur léger qui héberge uniquement des fichiers peu changeants, Time Machine peut constituer une première ligne raisonnable. Dès que Docker Desktop, AnythingLLM ou Ollama porte un état utile, nous retenons plutôt la combinaison « Time Machine plus sauvegarde applicative plus copie sur un autre environnement ». Elle demande davantage de préparation, mais elle répond à la vraie question : combien de temps faut-il pour retrouver un service fonctionnel, et quelles données seront réellement présentes ?

Si le Mac mini M6 doit rester le serveur principal pendant une longue période avec une charge stable, l’achat d’une machine dédiée peut être plus rationnel qu’une location répétée, notamment lorsque des périphériques physiques, des ports locaux ou une disponibilité permanente sont indispensables. À l’inverse, tester une restauration directement sur le serveur de production expose les automatismes familiaux, les bases et les secrets à une manipulation risquée. Une solution distante temporaire évite aussi de conserver une seconde machine inutilisée uniquement pour un exercice occasionnel.

Dans ce contexte, JexMac apporte un environnement Mac temporaire pour valider la procédure logicielle avant une migration : vous pouvez restaurer le paquet Docker, vérifier AnythingLLM, reconnecter Ollama et mesurer le travail restant sans effacer le serveur actif. Cette approche est plus pertinente que de découvrir les limites de Time Machine le jour où le Mac principal ou son disque devient indisponible. Vous pouvez d’abord consulter les ressources françaises de JexMac pour préparer ce scénario, puis décider de la durée de location en fonction du niveau de reprise à vérifier, plutôt que de louer ou d’acheter sans test préalable.