Trois mois de sauvegardes fantômes, et zéro alerte pour me le dire. J’avais programmé ma copie de sécurité à 3 heures du matin pour ne jamais la sentir tourner en journée, convaincu d’avoir enfin réglé le problème une bonne fois pour toutes. Mais la tâche planifiée s’exécutait dans le vide depuis la première nuit, et Windows n’a jamais jugé utile de me prévenir que rien ne se passait. Le plus flippant dans cette histoire, ce n’est pas l’erreur elle-même : c’est le silence total qui l’a entourée pendant treize semaines.
À retenir
- Votre PC s’endort peut-être juste avant que la sauvegarde ne commence — et Windows ne vous le dit jamais
- Le compte système qui exécute la tâche n’a souvent pas accès à vos lecteurs réseau, même si tout fonctionne manuellement
- L’observateur d’événements révèle ce que l’interface cache : des trois mois d’exécutions fantômes
Le piège classique : la machine qui dort pendant que la tâche attend
Le coupable numéro un dans ce genre de mésaventure, c’est le mode veille. Par défaut, si c’est l’heure de la sauvegarde régulière et que l’ordinateur est éteint, en veille ou en hibernation, Windows Backup saute la sauvegarde et attend la suivante. Concrètement, si votre PC s’endort avant 3 heures du matin et ne se réveille pas tout seul, la tâche ne se déclenche jamais. Elle n’échoue même pas au sens strict : elle est simplement zappée, encore et encore, sans qu’aucune fenêtre d’erreur ne vienne perturber votre petit-déjeuner.
La solution existe depuis des années mais reste méconnue : il faut cocher l’option qui autorise la machine à se réveiller pour exécuter la tâche, en cliquant sur l’onglet « Conditions » et en s’assurant que « Réveiller l’ordinateur pour exécuter cette tâche » est activé. Un détail qui change tout, sauf qu’il ne suffit pas toujours : encore faut-il que les paramètres d’alimentation du PC autorisent ce réveil programmé. Sur certaines configurations, il faut développer les options « Veille » et « Minuteries de réveil » et vérifier que les modes sur secteur et sur batterie sont bien réglés sur activé. Sans ce réglage côté BIOS et côté Windows, la case cochée dans le planificateur de tâches ne sert littéralement à rien.
Le compte utilisateur, ce traître silencieux
Sleep mode mis à part, il existe une deuxième source de pannes muettes, encore plus vicieuse parce qu’elle touche même les PC qui ne s’endorment jamais : les droits d’accès du compte qui exécute la tâche. De nombreux logiciels de sauvegarde tournent en tâche de fond sous un compte système générique, et ce compte n’a souvent pas accès aux chemins réseau lorsqu’il s’exécute sous le compte système local, SYSTEM. Résultat : la sauvegarde vers un NAS ou un disque réseau échoue systématiquement en automatique, alors qu’elle fonctionne à la perfection quand on lance le bouton manuellement, ce qui brouille complètement les pistes et rassure à tort.
Il y a une raison technique précise à ce comportement absurde en apparence. Un service Windows ne peut pas accéder aux lecteurs réseau mappés, car ils ne sont pas disponibles dans la session de service et ne se reconnectent automatiquement que lorsque l’utilisateur ouvre sa propre session. la lettre de lecteur bien pratique que vous avez assignée à votre NAS n’existe tout simplement pas pour le processus qui tourne en arrière-plan à 3 heures du matin. La parade recommandée consiste à garantir l’utilisation du chemin réseau complet, du type \\NAS\backup, plutôt qu’un lecteur mappé. Un changement de deux minutes qui aurait pu m’éviter tout ce scénario.
Pourquoi personne ne vous prévient jamais
Le vrai scandale, dans toute cette histoire, c’est l’absence totale de retour utilisateur. Un témoignage recueilli sur un forum spécialisé résume bien le problème : la tâche de sauvegarde s’affiche comme n’étant pas en cours d’exécution, n’ayant pas échoué, rien du tout, et l’outil affiche simplement la prochaine sauvegarde comme étant demain, sans succès ni échec signalé. Le planificateur de tâches Windows n’a jamais été pensé pour hurler au moindre pépin, il note discrètement l’incident dans les journaux d’événements et passe à autre chose.
Heureusement, il existe une façon de forcer le système à devenir bavard. Lorsqu’une tâche planifiée ne démarre pas, un événement est inscrit dans le journal du planificateur de tâches, accessible via l’observateur d’événements de Windows. À partir de là, on peut créer une seconde tâche qui se déclenche précisément quand cet événement d’échec apparaît, et qui, elle, envoie un vrai signal : un mail, une notification, voire un redémarrage forcé pour attirer l’attention. C’est un peu tordu comme méthode, mais c’est la seule qui transforme un silence radio en vraie alerte exploitable.
Ce qu’il faut vérifier avant de faire confiance à sa sauvegarde
Après cette mésaventure, j’ai pris l’habitude de contrôler trois points précis avant de laisser tourner une sauvegarde sans surveillance : la date de dernière modification réelle du fichier de sauvegarde sur le disque cible (pas juste la date de création du dossier), l’historique du planificateur de tâches dans l’observateur d’événements, et le compte sous lequel la tâche s’exécute réellement. Ces trois vérifications prennent moins de cinq minutes et évitent de découvrir, un jour de crash disque, que la seule copie de vos fichiers date d’un mardi soir oublié depuis longtemps.
Le détail le plus ironique de toute cette affaire, c’est que ma sauvegarde manuelle fonctionnait parfaitement à chaque test. J’appuyais sur le bouton, tout se passait bien, je repartais confiant. Cette fausse impression de fiabilité, entretenue par des tests manuels qui contournent justement le problème (le compte utilisateur, les droits réseau, le réveil de la machine), est probablement la cause numéro un des mauvaises surprises en cas de sinistre réel.
Sources : iperiusbackup.fr | fr.softwareuser.asklobster.com