Comment vérifier si Time Machine poursuit ou recrée l’historique des sauvegardes

Vous pouvez vérifier la continuité en contrôlant l’identité de la destination, l’historique des sauvegardes hérité, la liste des instantanés récents et le fait que la première nouvelle exécution se comporte comme un transfert incrémentiel ou complet.

La décision est importante lorsqu’un Mac se reconnecte à un NAS après une migration, un changement de nom de partage, une modification des identifiants ou une réparation de sparsebundle. Les deux états en concurrence sont les suivants : l’historique existant est hérité et étendu, ou un nouvel ensemble de sauvegardes est créé à côté de l’ancien. Commencez avec une configuration enregistrée et des données non critiques, observez une branche à la fois et arrêtez-vous si le test accroît le risque de perte de données, de problèmes d’autorisations ou d’indisponibilité.

Définir les conditions à l’origine de la décision sur la continuité de l’historique Time Machine

Notez l’environnement avant toute modification : versions des logiciels et des micrologiciels, identités des appareils, chemin de montage ou réseau, espace libre, autorisations et symptôme observable. La référence doit conserver suffisamment de détails pour reproduire la reconnexion d’un Mac à un NAS après une migration, un changement de nom de partage, une modification des identifiants ou une réparation de sparsebundle.

La première hypothèse est que l’historique existant est hérité et étendu. La seconde est qu’un nouvel ensemble de sauvegardes est créé à côté de l’ancien. Les vérifications de destination tmutil actuelles définissent le mécanisme ou la limite de commande utilisés lors du test ; elles ne remplacent pas l’observation effectuée depuis ce serveur domestique précis.

Rédigez la condition d’acceptation et la condition d’arrêt avant d’exécuter le test discriminant. Une réussite doit modifier les éléments probants prédits par une branche tout en laissant les services indépendants inchangés ; un échec doit restaurer le système à l’état enregistré plutôt que déclencher une série de corrections spéculatives.

Tester l’hypothèse sans réduire l’exigence initiale

Utilisez ce test discriminant : inspectez la destination et l’historique des instantanés avec tmutil, puis lancez une sauvegarde contrôlée tout en surveillant la quantité transférée et le bundle de destination. Conservez la charge, le client, le chemin, l’ensemble de fichiers et le calendrier constants afin que le résultat soit attribuable à la variable modifiée.

Utilisez les destinations Time Machine pour sélectionner le champ qui permet réellement de distinguer les branches, puis capturez son horodatage, son état de sortie, le texte de l’erreur, l’identité de l’appareil ou de l’instantané, la latence, le nombre d’octets transférés, les autorisations et l’état de récupération. Une sortie de commande correcte ne suffit pas lorsque l’identité, la durabilité ou l’état de l’application constitue l’hypothèse testée.

Répétez le test une fois après un redémarrage, une reconnexion, un remontage ou un cache froid lorsque cet événement fait partie de la condition initiale. Si la première exécution est destructive ou si l’environnement ne peut pas être restauré, arrêtez-vous et reproduisez le test sur une copie non critique.

tmutil destinationinfo
tmutil listbackups
tmutil status

Interpréter les résultats de réussite, d’échec et d’exception

RÉUSSITE : les nouveaux instantanés locaux s’attachent à la destination attendue et l’exécution ne transfère que les données modifiées. Notez précisément la version, l’identité et la charge qui ont réussi afin que la conclusion reste conditionnelle plutôt que de devenir une affirmation universelle.

ÉCHEC : un nouveau sparsebundle apparaît, l’historique est absent ou la quantité transférée se rapproche d’une référence complète. Un échec ne prouve pas automatiquement la branche opposée lorsque le réseau, la mémoire, les autorisations ou la cohérence de la source peuvent influencer les deux branches ; isolez ces dépendances communes avant toute escalade.

EXCEPTION OU RÉSULTAT AMBIGU : arrêtez l’exécution avant que les deux historiques ne consomment le quota et restaurez l’identité de destination précédente. Conservez les journaux et n’exécutez aucune commande de réparation, d’élagage, de destruction, de repartitionnement ou de modification récursive des propriétaires avant de disposer d’une copie récupérable.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Confirmer la décision avec la charge initiale

Appliquez l’action correspondant à la branche observée, puis répétez la condition initiale plutôt qu’un substitut réduit. La décision n’est valide que lorsque les nouveaux instantanés locaux s’attachent à la destination attendue et que l’exécution ne transfère que les données modifiées sur deux cycles ou lors du redémarrage, de la mise en veille, de l’interruption ou de la transition de charge pertinente.

Utilisez les quotas Time Machine pour vérifier le flux de travail dépendant le plus proche, mais conservez le déclencheur initial inchangé. Les jeux de données, partages, conteneurs, utilisateurs et points de récupération indépendants doivent conserver leur accès et leur délai précédents.

La limite d’arrêt est explicite : si un nouveau sparsebundle apparaît, si l’historique est absent ou si la quantité transférée se rapproche d’une référence complète, revenez à la dernière configuration vérifiée, conservez les éléments probants et ne passez à un test plus approfondi de la plateforme ou du matériel que lorsque la branche est reproductible.

Une fois le résultat cible obtenu, comparez-le à la vérification de restauration afin que la correction ne déplace pas le risque vers un service voisin. Un test cible réussi accompagné d’un échec de nouvelle sauvegarde, d’identité, de délai d’expiration ou de disponibilité reste une modification échouée.

FAQ

Pour la continuité de l’historique Time Machine, les recherches restantes portent généralement sur les questions suivantes : une première exécution volumineuse signifie-t-elle toujours que l’historique a été perdu, deux sparsebundles peuvent-ils avoir des noms similaires et faut-il supprimer l’ancien bundle après le démarrage d’une nouvelle sauvegarde ? Les réponses ci-dessous séparent ces cas particuliers de la décision principale.

La limite d’acceptation ne change pas : les nouveaux instantanés locaux s’attachent à la destination attendue et l’exécution ne transfère que les données modifiées. Si une condition ultérieure modifie le système de fichiers, l’identité, le chemin réseau ou la version de l’application, répétez uniquement le test discriminant affecté par cette modification.

Arrêtez d’élargir l’expérience lorsqu’un nouveau sparsebundle apparaît, que l’historique est absent ou que la quantité transférée se rapproche d’une référence complète. À ce stade, arrêtez l’exécution avant que les deux historiques ne consomment le quota et restaurez l’identité de destination précédente ; conservez les éléments probants avant toute escalade vers le responsable de la plateforme, du stockage ou du matériel.

Une première exécution volumineuse signifie-t-elle toujours que l’historique a été perdu ?

Non. Les mises à niveau du système d’exploitation, les exclusions, les modifications du système de fichiers ou les longues interruptions peuvent produire de gros transferts incrémentiels ; vérifiez l’identité de la destination et la filiation des instantanés.

Deux sparsebundles peuvent-ils avoir des noms similaires ?

Oui. Utilisez l’identité de la machine et les métadonnées de destination, pas le nom de fichier seul.

Faut-il supprimer l’ancien bundle après le démarrage d’une nouvelle sauvegarde ?

Non, pas avant d’avoir prouvé la continuité ou que le nouvel historique complet a réussi un test de restauration.

Pour la continuité de l’historique Time Machine, la réponse pratique reste conditionnelle : les nouveaux instantanés locaux s’attachent à la destination attendue et l’exécution ne transfère que les données modifiées. Lorsqu’un nouveau sparsebundle apparaît, que l’historique est absent ou que la quantité transférée se rapproche d’une référence complète, arrêtez l’exécution avant que les deux historiques ne consomment le quota et restaurez l’identité de destination précédente ; une réussite partielle qui ne résiste pas à la charge initiale n’est pas une compatibilité.