Time Machine ne fonctionne pas ? 12 solutions aux erreurs de sauvegarde les plus courantes

Time Machine se trouve à l'intersection inconfortable de plusieurs sous-systèmes. Pour terminer une seule sauvegarde, il doit coordonner le système de fichiers, le démon d'événements du système de fichiers, les montages réseau, SMB ou AFP, l'enveloppe sparsebundle, les couches de chiffrement, les snapshots, et la propre supposition de l'utilisateur qu'aucun de ceux-ci n'échouera simultanément. Quand quelque chose échoue, l'erreur en surface est généralement un générique « une erreur s'est produite » sans contexte utile, et la cause réelle est l'une d'environ une douzaine de choses spécifiques.

Ce guide est la liste éprouvée sur le terrain de ces douze choses. Chaque correctif suit la même forme : à quoi ressemble le symptôme, ce qui ne va pas réellement en dessous, et les étapes exactes pour revenir à une sauvegarde fonctionnelle.

Premièrement : lisez les journaux

Avant de changer quoi que ce soit, regardez ce que Time Machine se dit réellement à lui-même. Ouvrez le Terminal et lancez :

log show --predicate 'subsystem == "com.apple.TimeMachine"' --info --last 1h

Cela vide la dernière heure d'activité Time Machine. Faites défiler pour les mots error, fail, denied ou copying. La cause racine réelle est presque toujours écrite quelque part là-dedans, même quand le dialogue côté utilisateur ne disait rien d'utile.

Pour un triage plus rapide, vous pouvez aussi lancer :

tmutil status
tmutil latestbackup

Le premier affiche l'état en direct du moteur de sauvegarde. Le second vous dit quand le dernier snapshot réussi a terminé. Si latestbackup a des jours ou semaines, vos notifications « Time Machine a terminé une sauvegarde » vous mentent.

Solution 1 : sauvegarde qui prend une éternité

Symptôme : la barre de progression avance lentement pendant des heures mais ne finit jamais. Le temps restant estimé continue de croître.

Diagnostic : deux causes courantes. Soit c'est réellement la première sauvegarde d'un grand jeu de données (auquel cas c'est juste lent), soit fseventsd a perdu la tête et Time Machine fait un balayage complet au lieu d'un incrémental.

Solution :

1. Si c'est votre toute première sauvegarde, laissez-la finir. Une sauvegarde initiale de 1 To sur USB 3 prend 6 à 12 heures ; la même sur Wi-Fi peut prendre des jours. Branchez en Ethernet si vous avez une destination cloud.
2. Si ce n'est pas la première sauvegarde, suspectez fseventsd. Lancez sudo rm -rf /.fseventsd sur le volume source, puis redémarrez. La sauvegarde suivante sera lente parce qu'elle doit reconstruire la base d'événements, mais les suivantes reviendront à la vitesse normale.
3. Vérifiez Moniteur d'activité pour backupd et backupd-helper. Si le CPU est haut mais l'I/O disque est bas, le goulot est l'analyse de métadonnées, pas le transfert de données. fseventsd est encore le suspect principal.

Solution 2 : bloqué sur « Préparation de la sauvegarde... »

Symptôme : le statut affiche « Préparation de la sauvegarde... » pendant des heures et ne progresse jamais.

Diagnostic : la phase de « préparation » est où Time Machine snapshote le volume source et parcourt le journal de changements pour déterminer quoi sauvegarder. Si le journal de changements est corrompu ou si le sparsebundle sur la destination a des métadonnées rances, cette phase peut bloquer indéfiniment.

Solution :

1. Ouvrez l'icône Time Machine dans la barre des menus, cliquez sur Sauter cette sauvegarde. Cela tue le travail bloqué.
2. Attendez 30 secondes, puis déclenchez Sauvegarder maintenant depuis le même menu.
3. Si la nouvelle exécution bloque aussi, éjectez et remontez le disque de destination.
4. Si le blocage persiste, lancez l'équivalent fsck sur le volume source depuis Utilitaire de disque (S.O.S).
5. Dernier recours : régénérez la base fseventsd avec sudo rm -rf /.fseventsd, redémarrez, puis sauvegardez.

Solution 3 : disque de sauvegarde plein, le sparsebundle continue de grossir

Symptôme : Time Machine signale que le disque de sauvegarde est plein, même si vous avez défini une limite de taille généreuse.

Diagnostic : les sparsebundles ne se réduisent pas automatiquement à mesure que les snapshots sont supprimés. Quand Time Machine amincit les anciens snapshots, l'espace libéré est signalé à l'intérieur du sparsebundle mais le fichier sparsebundle lui-même reste à la taille à laquelle il a grandi. Sur une destination partagée avec d'autres données, le système de fichiers hôte se remplit avant que Time Machine ne le remarque.

Solution :

1. Compactez le sparsebundle. Éjectez-le de Time Machine d'abord, montez-le manuellement, puis lancez : hdiutil compact /Volumes/Backups/MyMac.sparsebundle.
2. Si vous ne pouvez pas compacter, vous devrez peut-être copier les données vivantes, recréer le sparsebundle plus petit, et recopier.
3. Définissez un plafond de taille dur sur le sparsebundle si votre destination de sauvegarde le prend en charge. macOS lui-même n'expose pas cela dans l'interface ; vous devez utiliser tmutil setdestination ou un outil admin sur le serveur.
4. Envisagez une destination dédiée à Time Machine pour que d'autres fichiers ne se disputent pas l'espace. Les destinations cloud comme Capsule Backup attribuent un quota fixe qui ne peut être mangé par rien d'autre.

Solution 4 : Time Machine ne trouve pas le disque de sauvegarde

Symptôme : « Time Machine n'a pas pu trouver le disque de sauvegarde » même si vous le voyez dans le Finder.

Diagnostic : le disque est monté mais Time Machine a perdu la référence persistante (UUID ou identifiant de volume non concordant), ou le partage SMB a sauté et le remontage automatique a échoué.

Solution :

1. Pour les disques locaux : ouvrez Réglages Système → Général → Time Machine, retirez la destination, rajoutez-la. Time Machine détectera le dossier de sauvegarde existant et continuera plutôt que démarrer à neuf.
2. Pour les partages réseau : éjectez et reconnectez via ⌘K dans le Finder. Enregistrez les identifiants dans le trousseau pour que le remontage automatique fonctionne à l'avenir.
3. Vérifiez que le système de fichiers du disque est l'un de ceux que Time Machine prend en charge : APFS ou HFS+ pour les disques locaux, SMB3 pour le réseau. exFAT et NTFS ne sont pas des destinations prises en charge.

Solution 5 : « Une erreur s'est produite » sans autre information

Symptôme : le dialogue d'erreur générique classique sans rien d'actionnable dedans.

Diagnostic : c'est l'interface macOS qui abandonne. L'erreur réelle est dans les journaux.

Solution :

1. Lancez la requête de journal ci-dessus pour trouver l'erreur sous-jacente.
2. L'erreur est généralement l'un des autres éléments de cette liste : permission, réseau, corruption sparsebundle, disque plein, ou casse post-mise à jour. Identifiez-la et appliquez la solution pertinente.

Solution 6 : corruption du sparsebundle

Symptôme : Time Machine refuse de monter la destination, ou en plein milieu de sauvegarde se plaint que le sparsebundle est endommagé.

Diagnostic : un sparsebundle est un dossier de petits fichiers « band » qui forment ensemble un disque virtuel. Si un band est corrompu (souvent parce que la source a été débranchée en plein écriture ou que le réseau a sauté pendant une mise à jour de métadonnées critique), le volume devient non montable.

Solution :

1. Montez le partage, localisez le sparsebundle, et essayez de le monter manuellement en double-cliquant. Si macOS demande une réparation, acceptez.
2. Depuis le Terminal : hdiutil verify /path/to/MyMac.sparsebundle. Cela rapporte si le volume est récupérable.
3. Si verify échoue, essayez : hdiutil attach -noverify -nomount /path/to/MyMac.sparsebundle pour attacher sans monter, puis lancez S.O.S d'Utilitaire de disque contre l'image attachée.
4. Si la réparation réussit, lancez immédiatement une sauvegarde fraîche vers une destination différente. Un sparsebundle qui a eu besoin de réparation une fois est en sursis.
5. Si la réparation échoue : votre historique de snapshots est parti. Démarrez une nouvelle sauvegarde vers une nouvelle destination. Lisez plus là-dessus dans notre guide de restauration.

Solution 7 : le partage réseau continue de se déconnecter

Symptôme : les sauvegardes démarrent, tournent une heure ou deux, puis échouent avec une erreur réseau. Souvent associée à une notification du Finder disant que le serveur s'est déconnecté.

Diagnostic : la session SMB tombe. Les causes vont de l'instabilité Wi-Fi aux timeouts NAT du routeur, en passant par la politique de déconnexion en veille du serveur, ou un réglage économiseur d'énergie mal calibré qui met votre Mac en veille en plein transfert.

Solution :

1. Basculez du Wi-Fi vers Ethernet. La perte de paquets Wi-Fi sur un transfert de plusieurs heures s'accumule.
2. Réglages Système → Économiseur d'énergie → décochez « Mettre les disques durs en veille quand c'est possible » et « Réveil pour l'accès réseau ».
3. Réglages Système → Économiseur d'énergie → réglez « Éteindre l'écran après » à un intervalle plus long, et confirmez que « Empêcher la mise en veille automatique quand l'écran est éteint » est activé si vous êtes sur un ordinateur de bureau.
4. Pour les coupures de connexion spécifiques à SMB, modifiez (ou créez) /etc/nsmb.conf et ajoutez : [default] notify_off=yes signing_required=yes. Le premier réduit un chemin de notification bavard que certains serveurs gèrent mal.
5. Si votre serveur impose un timeout d'inactivité, planifiez de l'activité keep-alive ou déplacez-vous vers une destination conçue pour les sessions Time Machine de longue durée.

Solution 8 : sauvegardes incrémentales lentes

Symptôme : les sauvegardes horaires qui devraient prendre des secondes prennent 20 à 40 minutes chacune.

Diagnostic : soit fseventsd se reconstruit (voir Solution 1), soit le disque source a tellement de petits fichiers que la phase de métadonnées est naturellement lente.

Solution :

1. Ajoutez les coupables habituels à la liste d'exclusion : node_modules, ~/.gradle, ~/.m2, images disque de machines virtuelles, gros caches de conteneurs. Ceux-ci se régénèrent facilement et sont du pur bruit dans une sauvegarde.
2. Depuis le Terminal, excluez programmatiquement : tmutil addexclusion ~/projects/big-monorepo/node_modules. Répétez pour chaque chemin.
3. Confirmez que l'exclusion a pris : tmutil isexcluded ~/projects/big-monorepo/node_modules.

Solution 9 : erreurs de permission (« Operation Not Permitted »)

Symptôme : les journaux rapportent « Operation not permitted » sur des chemins spécifiques. Cibles courantes : ~/Library/Mail, ~/Library/Messages, ou les bacs à sable d'apps tierces.

Diagnostic : macOS utilise TCC (Transparency, Consent, and Control) pour contrôler l'accès à certaines données utilisateur. backupd a besoin de l'Accès complet au disque pour lire ces emplacements.

Solution :

1. Réglages Système → Confidentialité et sécurité → Accès complet au disque.
2. Confirmez que Time Machine apparaît dans la liste et que le commutateur est activé. S'il manque, ajoutez-le manuellement avec le bouton + et naviguez vers /System/Applications/Utilities/ ou cherchez-le simplement.
3. Pour certaines versions de macOS vous devez ajouter backupd directement. Le chemin est /System/Library/CoreServices/backupd.bundle/Contents/MacOS/backupd.
4. Redémarrez. Lancez un Sauvegarder maintenant manuel et vérifiez les journaux pour les erreurs de permission résiduelles.

Solution 10 : liste d'exclusion non respectée

Symptôme : vous avez ajouté un dossier à la liste d'exclusion, mais il apparaît encore dans la sauvegarde ou compte dans la taille de sauvegarde.

Diagnostic : l'exclusion a été ajoutée contre un ancien chemin (le dossier a été renommé ou déplacé), ou l'exclusion a été ajoutée via un mécanisme et Time Machine lit depuis un autre.

Solution :

1. Listez les exclusions actuelles : sudo tmutil listexclusions.
2. Si l'exclusion est mauvaise, retirez-la : tmutil removeexclusion /path/to/folder.
3. Rajoutez contre le chemin absolu canonique.
4. Forcez une nouvelle estimation de taille en lançant tmutil calculatedrift ou simplement en attendant la prochaine sauvegarde planifiée ; l'exclusion prendra effet immédiatement.

Solution 11 : le disque chiffré ne se déverrouille pas

Symptôme : Time Machine demande le mot de passe de chiffrement à chaque sauvegarde, ou refuse le mot de passe que vous savez correct.

Diagnostic : l'entrée du trousseau pour le disque de sauvegarde a été supprimée, corrompue ou remplacée. Cela arrive après une mise à niveau majeure de macOS, après un conflit de synchronisation du trousseau via iCloud, ou après une restauration du système depuis une autre sauvegarde.

Solution :

1. Ouvrez Trousseau d'accès et cherchez le nom du volume de sauvegarde. Supprimez les entrées en double ou rances.
2. Lancez un Sauvegarder maintenant et ressaisissez le mot de passe à l'invite. Cochez « Enregistrer dans le trousseau ».
3. Si le mot de passe est rejeté avec une erreur du type « mauvais mot de passe » mais que vous êtes sûr qu'il est correct, essayez de le saisir via Utilitaire de disque à la place. Montez le sparsebundle via le bouton « Monter » d'Utilitaire de disque et utilisez le mot de passe là. Si Utilitaire de disque l'accepte, le problème est purement un décalage d'entrée de trousseau et le ré-enregistrer le règle.
4. Si Utilitaire de disque rejette aussi : confirmez que vous ne saisissez pas le mot de passe FileVault par erreur, et lisez l'explication du chiffrement des sauvegardes Mac pour la différence entre les deux couches. Il n'y a pas de chemin de récupération pour un mot de passe de chiffrement Time Machine vraiment oublié.

Solution 12 : Time Machine cassé après une mise à jour macOS

Symptôme : les sauvegardes fonctionnaient hier. Aujourd'hui, après une mise à jour mineure de Sequoia, elles échouent.

Diagnostic : les mises à jour macOS ajustent routinièrement la pile SMB, la base TCC, ou les internes de Time Machine. La casse tombe presque toujours dans l'un de trois seaux : Accès complet au disque perdu, identifiants SMB perdus, ou un sparsebundle qui doit être re-béni pour la nouvelle version.

Solution :

1. Re-accordez l'Accès complet au disque à backupd comme dans Solution 9.
2. Remontez le partage SMB manuellement via ⌘K et ré-enregistrez les identifiants dans le trousseau.
3. Si la destination est un sparsebundle réseau, éjectez et rattachez. macOS doit parfois revalider les métadonnées du sparsebundle contre le nouvel OS.
4. Si rien de tout cela ne fonctionne, retirez la destination de Réglages Système → Général → Time Machine et rajoutez-la. Les snapshots existants seront détectés et continués, pas effacés.

Maintenance préventive

La plupart des défaillances Time Machine sont évitables avec un petit investissement continu.

• Vérifiez les sauvegardes trimestriellement. Restaurez un fichier au hasard via le navigateur Time Machine. Confirmez que le contenu correspond. Faites cela au calendrier. Si vous ne l'avez pas fait depuis six mois, faites-le aujourd'hui.
• Lancez hdiutil verify contre votre sparsebundle chaque mois. Montez-le, éjectez de Time Machine d'abord, puis vérifiez. Attrape la corruption avant qu'elle ne mange votre historique.
• Gardez deux destinations. SSD USB local pour récupération rapide, plus une destination cloud hors site pour reprise après désastre. macOS alterne entre elles automatiquement.
• Documentez votre mot de passe de chiffrement. Dans un gestionnaire de mots de passe. Aujourd'hui. Le jour où vous l'oubliez est le jour où vous en avez aussi besoin.
• Surveillez l'icône de la barre des menus. Cliquez dessus quotidiennement. Si la dernière sauvegarde réussie a plus d'un jour, enquêtez.

Quand tout recommencer (dernier recours)

Si vous avez appliqué chaque solution de ce guide et que Time Machine échoue encore, le bon mouvement est parfois de démarrer une toute nouvelle sauvegarde. Avant de le faire :

1. Ajoutez une nouvelle destination sur un disque séparé et laissez-la terminer une sauvegarde initiale complète.
2. Vérifiez la nouvelle sauvegarde avec un test de restauration.
3. Seulement ensuite, retirez la destination cassée.

Ne supprimez jamais la seule copie de votre historique de snapshots en espérant que la nouvelle sauvegarde fonctionnera, parce que si elle ne fonctionne pas, vous êtes maintenant sans aucune sauvegarde. Pour les détails sur le choix d'une nouvelle destination hors site, voir le guide de configuration Time Machine cloud, ou allez directement à notre pas à pas de configuration.

La vue d'ensemble

Time Machine est brillant quand il fonctionne et frustrant quand il échoue parce que les modes d'échec sont si opaques. Les douze solutions ci-dessus couvrent environ 95 % des défaillances que nous voyons en conditions réelles. Les 5 % restants tracent généralement vers une mort matérielle réelle, auquel cas aucune solution ne ranimera le disque et la bonne réponse est une destination différente, idéalement une que vous contrôlez de bout en bout. Capsule Backup existe en partie parce que les destinations Time Machine basées cloud contournent beaucoup de ces modes d'échec en supprimant entièrement le disque-comme-point-de-défaillance.