Pourquoi une sauvegarde Time Machine devient-elle inaccessible via un partage NAS SMB ?

Une sauvegarde Time Machine peut devenir indisponible via un partage SMB NAS même si le NAS est en ligne, car Time Machine dépend de plus que l’accès simple aux fichiers. Le Mac doit redécouvrir la bonne destination de sauvegarde, s’authentifier avec le compte attendu, localiser le sparsebundle correspondant, monter cette image sans verrou obsolète, et trouver suffisamment d’espace inscriptible pour continuer en toute sécurité.

D’abord, séparez un partage indisponible d’une image de sauvegarde indisponible

Ouvrez le Finder et connectez-vous au partage SMB exact avec le compte assigné à Time Machine. Si le partage ne peut pas être monté ou si le sparsebundle n’est pas visible, dépannez d’abord la connectivité réseau, le nom du partage, les permissions et les identifiants. Si le partage s’ouvre mais que Time Machine rejette la sauvegarde existante, le problème se situe plus profondément dans la destination.

Cette distinction évite des suppositions destructrices. Recréer la destination Time Machine ne corrigera pas un échec de connexion SMB basique, tandis que supprimer les identifiants enregistrés ne réparera pas un sparsebundle qui ne se monte plus.

Vérifier si le Mac reconnaît toujours la même destination

Time Machine se souvient d’une cible réseau sélectionnée, pas simplement d’un dossier contenant des fichiers de sauvegarde. Un renommage du NAS, du partage, un changement de protocole ou une reconfiguration de destination peut rendre l’ancienne cible non sélectionnable. Dans un cas de NAS, les utilisateurs ont dû supprimer la destination manquante et ajouter à nouveau le partage réseau avant que le Mac puisse l’utiliser.

Avant de re-sélectionner, notez le nom d’hôte du NAS, l’adresse SMB, le nom du partage, l’utilisateur, le nom du sparsebundle et la taille de sauvegarde attendue. Pointer Time Machine vers un nouveau partage vide peut démarrer une seconde historique au lieu de reconnecter l’existant.

Vérifier la découverte SMB et la publicité des capacités de Time Machine

Un partage peut être monté manuellement alors que Time Machine échoue encore à le présenter ou à l’authentifier comme cible de sauvegarde. Un cas récent de dépannage NAS a révélé que la connexion SMB manuelle fonctionnait alors que Time Machine échouait ; l’absence de découverte de service et l’implémentation SMB active faisaient partie du diagnostic.

Pour un NAS domestique ZimaSpace, confirmez que le partage sélectionné est explicitement configuré pour un service SMB compatible Time Machine, pas seulement pour un partage de fichiers domestique général. Le redémarrage des services de découverte peut aider uniquement après vérification du chemin du partage et des permissions.

Supprimez les identifiants enregistrés conflictuels sans supprimer la sauvegarde

macOS peut conserver un ancien mot de passe NAS, une connexion invité ou un mappage de compte après un changement de compte serveur. Déconnectez toutes les montures vers ce NAS, vérifiez les identifiants enregistrés, puis reconnectez-vous une fois avec l’utilisateur dédié à Time Machine. Évitez de vous connecter simultanément au même serveur avec plusieurs identités lors des tests.

Confirmez que le compte peut lister, créer, renommer et supprimer un fichier test temporaire dans le partage de sauvegarde. Un accès en lecture seule suffit pour parcourir un nom de sparsebundle mais pas pour que Time Machine puisse le monter et le mettre à jour.

Vérifiez si un Sparsebundle est toujours marqué comme utilisé

Une perte réseau, un redémarrage du NAS ou la mise en veille du Mac pendant une sauvegarde active peut laisser un verrou d’image ou un état de session ouverte. Un symptôme courant est que l’image disque de sauvegarde est déjà utilisée alors qu’aucune sauvegarde visible n’est en cours. Un fil de discussion Mac documente l’état d’échec “déjà en cours d’utilisation” du sparsebundle.

Arrêtez Time Machine, déconnectez le partage, confirmez qu’aucun autre Mac n’utilise la même image, puis redémarrez le service SMB du NAS ou le NAS avant de modifier quoi que ce soit dans le bundle. Ne supprimez pas les fichiers liés au verrou sur la base d’une commande générique sans avoir une copie ou un instantané du sparsebundle.

Comprendre pourquoi la mise en veille ou une coupure réseau peut laisser un verrou obsolète

Time Machine écrit via une image disque montée dont les bandes sont stockées comme des fichiers ordinaires sur le NAS. Si la connexion disparaît pendant une écriture, le serveur et le Mac peuvent ne pas être d'accord sur le fait que l'image est toujours active. Une analyse de récupération explique que une interruption réseau peut laisser l'état du jeton sparsebundle obsolète, ce qui fait que macOS refuse un nouvel attachement.

Vérifiez les journaux du NAS et du Mac autour du premier événement d'indisponibilité. Une défaillance unique après une perte de Wi-Fi suggère un état de session ; une perte répétée à la même taille de sauvegarde suggère une capacité, un dommage de l'image ou un problème de fichier spécifique.

Testez si le sparsebundle peut être attaché en lecture seule

Si le partage est accessible et que l'image n'est pas activement verrouillée, testez une attache en lecture seule ou inspectez-la à partir d'un ensemble de travail copié. Une discussion établie sur la réparation pour un sparsebundle qui ne se monte plus sépare l'attachement de l'image de la réparation du système de fichiers.

Ne lancez pas une réparation en écriture directement sur la seule image de sauvegarde sans avoir d'abord protégé les données du NAS. Si l'image se monte en lecture seule, copiez les fichiers critiques ou créez un autre instantané NAS avant de tenter la réparation.

Vérifiez le quota, l'espace libre et la capacité en écriture

Le NAS peut afficher une capacité libre du pool alors que le compte ou le partage Time Machine a atteint un quota. Les instantanés, corbeilles, espace réservé, croissance du sparsebundle ou la sauvegarde d'un autre Mac peuvent également consommer l'allocation en écriture. Comparez l'espace libre du pool, le quota du partage, le quota utilisateur et la taille réelle du sparsebundle.

Ne supprimez pas immédiatement des bandes aléatoires à l'intérieur du sparsebundle. Time Machine s'attend à ce que la structure de l'image disque reste cohérente en interne. Libérez de la capacité en ajustant la limite du partage ou en supprimant d'abord des données non liées, puis laissez Time Machine gérer son propre historique.

Utilisez cet ordre de récupération à faible risque

1. Mettez en pause Time Machine et empêchez les autres Mac d'utiliser le même partage.
2. Confirmez que le NAS, le partage SMB et le compte dédié sont accessibles.
3. Enregistrez le nom d'hôte original, le partage, le nom du sparsebundle et les quotas.
4. Supprimez les montages conflictuels et reconnectez-vous avec une seule identité.
5. Redémarrez les services SMB pour effacer les sessions obsolètes ordinaires.
6. Faites un instantané ou une copie du sparsebundle avant la réparation au niveau de l’image.
7. Testez la connexion en lecture seule et restaurez un fichier d’exemple.
8. Resélectionnez la cible existante uniquement après vérification de son identité et de son contenu.

Une fois l’image accessible, utilisez un emplacement isolé pour tester une restauration NAS sans écraser les fichiers en cours. La disponibilité ne suffit pas ; la sauvegarde doit aussi restituer des données exploitables.

FAQ

Peut-on déplacer un sparsebundle Time Machine vers un autre partage SMB ?

Cela peut être possible, mais il faut préserver le bundle complet, les permissions, la capacité de destination et l’identité. Testez à partir d’une copie avant de supprimer l’original.

Plusieurs Macs peuvent-ils utiliser le même partage Time Machine sur NAS ?

Oui, lorsque chaque Mac possède sa propre image de sauvegarde et que le NAS offre suffisamment de quota et de concurrence. Deux Macs ne doivent jamais écrire sur le même sparsebundle.

Changer l’adresse IP du NAS va-t-il casser Time Machine ?

Pas nécessairement si la découverte du nom d’hôte et l’identité de la cible restent stables, mais les montages en cache ou la sélection directe par IP peuvent faire apparaître l’ancienne destination comme indisponible.

Conclusion finale

Un partage SMB peut rester en ligne alors que sa sauvegarde Time Machine devient indisponible car la découverte de destination, les identifiants, les verrous de sparsebundle, la santé de l’image et les quotas sont des couches distinctes. Diagnostiquez-les dans l’ordre, préservez l’image existante avant la réparation, et effectuez une restauration d’exemple avant de faire confiance à l’historique récupéré.