En bref : vérifiez la date du fichier le plus récent dans la sauvegarde, pas celle du dossier. L'horodatage d'un dossier change pour des raisons qui n'ont rien à voir avec la fin d'une sauvegarde.
Si le fichier le plus récent à l'intérieur date d'avant hier, la sauvegarde n'a pas tourné, quoi que vous dise l'outil.
La plupart des conseils de sauvegarde portent sur la mauvaise catastrophe. Ils imaginent un drame : un disque qui meurt, un portable volé, une inondation. C'est rare et tout le monde comprend.
Le cas courant est banal. Le disque a été débranché pour faire de la place et n'a jamais été rebranché. Le NAS a redémarré après une coupure de courant et le partage ne s'est pas remonté. Le portable était fermé au moment prévu, chaque nuit, pendant un mois. Un script s'est terminé sur une erreur que personne n'a lue, car personne ne lit un journal qui va bien depuis un an.
Dans chacun de ces cas, rien n'est cassé. Aucune erreur n'apparaît là où quelqu'un regarde. Le dossier de sauvegarde est toujours là, toujours plein de fichiers, toujours de la bonne taille. La seule chose qui a changé, c'est qu'il a cessé de se mettre à jour, et rien dans le système ne juge utile de le mentionner.
Pointez ceci vers votre destination de sauvegarde. Il trouve le fichier modifié le plus récemment n'importe où à l'intérieur et affiche sa date :
find /Volumes/Backup -type f -print0 | xargs -0 stat -f '%m %N' | sort -rn | head -5La première colonne est un horodatage Unix. Pour le lire directement :
find /Volumes/Backup -type f -newermt '-2 days' | headSi cela n'affiche rien, rien n'a été écrit depuis deux jours. C'est la réponse, et elle est plus fiable que n'importe quel écran d'état, car c'est une propriété des fichiers eux-mêmes.
Pour Time Machine en particulier :
tmutil latestbackupqui affiche le chemin de l'instantané le plus récent, avec sa date dans le nom, ou une erreur s'il n'y en a pas.
Le réflexe est de regarder le dossier de sauvegarde dans le Finder et de lire la colonne Date de modification. Ce nombre n'est pas ce que vous croyez.
La date de modification d'un dossier change quand on y ajoute ou en retire quelque chose, pas quand le contenu d'un fichier à l'intérieur change. L'indexation Spotlight, un .DS_Store réécrit, un antivirus, un client cloud qui touche ses propres métadonnées : n'importe lequel peut faire croire qu'un dossier de sauvegarde périmé a été écrit ce matin.
Les fichiers à l'intérieur font foi. Le dossier, non.
launchd avec StartCalendarInterval ne tourne pas pendant que le Mac dort, et ne rattrape pas son retard ensuite sauf si vous l'avez demandé. Un portable fermé à minuit a une sauvegarde de minuit qui n'a jamais eu lieu.launchd écrit sa plainte dans un fichier, et ce fichier est le seul à savoir.Si vous le faites vous-même, la solution est un dispositif d'homme mort : quelque chose qui se plaint quand une sauvegarde n'a pas eu lieu. C'est un événement différent d'un échec, et seul le premier couvre les cas ci-dessus.
La version la plus simple est une tâche qui vérifie l'âge du fichier le plus récent et crie s'il est trop vieux :
if [ -z "$(find /Volumes/Backup -type f -newermt '-2 days' 2>/dev/null | head -1)" ]; then
osascript -e 'display notification "No backup in two days" with title "Backup"'
fiExécutez cela selon son propre calendrier, séparé de la sauvegarde, pour qu'un calendrier de sauvegarde cassé ne casse pas aussi ce qui le surveille. Ce dernier point est celui que les gens ratent : une vérification qui tourne dans la tâche de sauvegarde ne peut pas signaler que la tâche de sauvegarde n'a pas tourné.
Ce que vous voulez vraiment, c'est que l'absence soit l'alarme, et que l'outil nomme ce qui manque.
Copy Shelter repose sur cette idée. Il suit la date de dernière écriture et de dernière vérification de chaque destination, et il le signale après sept jours sans sauvegarde réussie. Il nomme l'emplacement, vous obtenez donc « le disque du tiroir n'a pas été vu depuis le 14 août ». Et comme il relit la sauvegarde et vérifie chaque morceau par rapport à l'empreinte sous laquelle il a été stocké, une sauvegarde qui tourne mais produit un résultat illisible est aussi détectée, ce qui est la panne un cran au-delà de cette page.
Le score qu'il affiche ne compte que ce qui a été vérifié récemment. Une sauvegarde qui n'a pas tourné n'est pas une sauvegarde que vous avez, et le nombre le dit.
Vous ne devriez pas avoir à le faire. C'est tout l'objet de cette page : une vérification faite à la main est une vérification que vous cesserez de faire, généralement environ trois semaines après l'avoir mise en place. Automatisez l'alarme d'absence, et réservez la vérification manuelle au moment où elle vous le demande.
Cela aide, dans une certaine limite. Time Machine avertit au bout de dix jours sans sauvegarde terminée, et la notification est facile à ignorer et facile à ne plus remarquer. Il ne peut pas non plus vous dire que la sauvegarde qu'il a terminée est illisible, car sur un disque local il ne vérifie pas.
C'est le cas des autorisations, et il est plus sournois car chaque indicateur d'état affiche un succès. Comparez le nombre de fichiers à la destination avec celui de la source. Si une sauvegarde censée contenir des dizaines de milliers de fichiers en contient quarante, macOS refuse l'accès aux dossiers et la tâche n'en est pas informée.
Différemment, et oui. Les clients de synchronisation se déconnectent, atteignent leur quota et se mettent en pause, et le badge qui vous le dirait est une petite icône dans une barre des menus que vous ne regardez pas. Les fichiers restent aussi exactement où ils étaient, donc rien ne semble anormal.
En grande partie, oui. Deux destinations qui tombent en panne pour des raisons différentes, vérifiées séparément, valent mieux que n'importe quelle surveillance d'une seule. La surveillance vous dit que la copie a disparu ; la deuxième copie fait que cela n'a pas d'importance. Voir la règle 3-2-1.
À lire aussi : vérifier qu'une sauvegarde est vraiment lisible, et la règle 3-2-1.