Le problème ne venait ni du disque dur, ni d’un bug caché dans les entrailles du code de Timeshift. Il tenait dans une seule ligne de l’onglet Location : le nom du périphérique sélectionné comme cible des sauvegardes avait changé sans que je m’en rende compte, et Timeshift continuait pourtant à afficher ses jolis snapshots hebdomadaires comme si de rien n’était.
Pendant des mois, j’ai eu cette fausse impression de sécurité. Chaque dimanche, une nouvelle entrée apparaissait dans la liste, avec sa date, son tag « Weekly », tout semblait nickel. Mais ces snapshots ne pointaient plus vers le disque externe que j’avais choisi au départ. Ils s’accumulaient tranquillement sur la partition système, celle-là même que Timeshift est censé protéger, pas engraisser.
À retenir
- Timeshift peut basculer silencieusement sur le disque système sans vous prévenir
- L’UUID du disque de sauvegarde change après un reformatage — et Timeshift ne suit pas
- Une simple vérification dans /etc/timeshift/timeshift.json révèle où vos données partent réellement
Le symptôme trompeur : tout semble marcher, rien ne marche vraiment
Timeshift fonctionne d’une manière assez particulière comparée à d’autres outils de sauvegarde. Contrairement à des outils similaires programmés pour lancer les sauvegardes à une heure fixe, Timeshift est conçu pour tourner une fois par heure et créer des snapshots uniquement quand c’est nécessaire, ce qui convient mieux aux utilisateurs de bureau qui allument leur machine quelques heures par jour. Concrètement, ça veut dire que le logiciel vérifie en permanence en arrière-plan si un snapshot est dû, et qu’il s’exécute dès que la fenêtre de temps s’y prête.
Le hic, c’est que cette mécanique tourne indépendamment de la validité du périphérique cible. Si le disque externe configuré à l’origine n’est plus détecté sous le même identifiant, Timeshift ne plante pas forcément avec un message d’erreur explicite. Dans certains cas, il continue simplement d’utiliser le disque système par défaut, celui qui héberge déjà votre installation Linux. Un utilisateur confronté à ce genre de mésaventure décrivait exactement ce scénario sur GitHub, avec les logs à l’appui : Using system disk as snapshot device for creating snapshots in BTRFS mode Mounted à /run/timeshift/backup, alors qu’il pensait viser son disque externe fraîchement configuré.
L’onglet Location, le vrai responsable de la mécanique
Timeshift identifie son périphérique de sauvegarde non pas par un chemin de dossier classique, mais par un UUID, cet identifiant unique attribué à chaque partition. Un fichier de configuration exemple de la documentation officielle le montre bien, avec une ligne comme « backup_device_uuid » : « root-partition UUID » qui fait toute la différence entre sauvegarder sur le bon disque et sauvegarder ailleurs sans le savoir.
Le problème, c’est que cet UUID change dès qu’on reformate le disque, qu’on le remplace ou même parfois après certaines manipulations de partitionnement. Timeshift, lui, continue de chercher l’ancien UUID enregistré dans sa configuration. S’il ne le trouve pas, deux scénarios possibles : soit il affiche une erreur bloquante du type espace disque insuffisant, comme documenté dans un autre rapport de bug où l’utilisateur voyait apparaître E: Not enough disk space (< 8.0 GB) E: Select another device or free up some space, soit il bascule silencieusement sur le disque système, ce qui est nettement plus vicieux parce que rien ne vous alerte visuellement dans l'interface.
Autre piège classique avec les disques externes : le format du système de fichiers compte énormément. Un disque externe destiné à Timeshift doit impérativement utiliser un système de fichiers compatible Linux, sans quoi il ne sera même pas proposé dans la liste des cibles disponibles. Et question stockage distant, on peut oublier tout de suite : les solutions en réseau ou dans le cloud ne sont tout simplement pas prises en charge par l’outil.
Comment vérifier que vos snapshots partent vraiment au bon endroit
La première chose à faire, c’est d’ouvrir les paramètres de Timeshift et de foncer directement sur l’onglet Location. Ne vous fiez pas au nom affiché du disque, regardez plutôt son état de connexion et sa taille disponible en temps réel. Si l’interface indique un espace libre qui ne correspond pas du tout à votre disque externe habituel, c’est le signal d’alarme numéro un.
Deuxième réflexe : inspecter directement le fichier de configuration situé dans /etc/timeshift/timeshift.json. C’est là que se cache la fameuse ligne backup_device_uuid, et comparer cette valeur avec l’UUID réel de votre disque externe (récupérable via un simple lsblk -f dans un terminal) permet de trancher en dix secondes. Si les deux ne correspondent pas, vous avez trouvé votre coupable.
Troisième point, souvent négligé sur les systèmes Arch ou dérivés : Timeshift dépend d’un planificateur cron pour exécuter ses vérifications programmées. Il faut installer le paquet Timeshift et activer ou démarrer le planificateur cron choisi pour garantir que les snapshots programmés dans l’application s’exécutent comme prévu. Sans ce service actif, l’interface graphique peut très bien afficher un planning cohérent qui, dans les faits, ne se déclenche jamais tout seul.
Un dernier détail mérite d’être rappelé, parce qu’il change complètement la donne pour ceux qui pensent avoir « tout » sauvegardé : Timeshift ne protège que le système, pas vos documents personnels. Timeshift est conçu pour protéger les fichiers système et paramètres, ce n’est pas un outil de sauvegarde et il n’est pas destiné à protéger les données utilisateur, le contenu entier des répertoires personnels étant exclu par défaut. même quand la ligne UUID pointe correctement vers votre disque externe, vos photos de vacances et vos projets en cours ne font jamais partie du voyage. Pour ça, il faudra un outil complémentaire, pensé spécifiquement pour les données, et pas pour l’état du système d’exploitation.
Sources : github.com | github.com