Locke
...s'il y a plusieurs instantanés, il faut bien qu'ils soient stockés quelque part.
J'avoue que je ne m'étais pas intéressé à la question, pour des raisons « pratiques » : je ne suis pas un utilisateur de «
TimeMachine» mais de
clones - aussi les subtilités de «
TimeMachine» n'excitent pas spontanément ma faculté spéculative.
Mais puisque tu en fais une question « théorique » > alors cela suffit pour stimuler ma faculté de raisonnement.
----------
J'ai démarré sur la version
APFS de
High Sierra (que je n'utilise pas au quotidien). «
Time Machine» y est désactivé et je maintiens ce statut. Mais cela n'empêche nullement de gérer des
snapshots en manuel, sans le secours du logiciel graphique
TM.
Dans le «
Terminal» > passer la commande :
Bloc de code:
sudo tmutil localshapshot
permet de créer un instantané local indexé par une date (la commande prend un petit moment à s'exécuter).
Cet instantané local a-t-il bien été créé > alors même que j'ai maintenu la désactivation de «
Time Machine» ? - pour le savoir > je passe la commande informative :
Bloc de code:
sudo tmutil listlocalsnapshot /
(il faut indique le point de montage du volume-cible - ici le volume démarré)
J'obtiens en retour un :
Bloc de code:
com.apple.TimeMachine.2017-11-03-172947
Voici donc l'instantané local
apfs (
snapshot) que je viens de créer précédemment.
----------
Ignorons pour l'instant la question de sa localisation > pour expérimenter son
usage. Il est nécessaire de re-démarrer par
⌘R en mode
Recovery. Le
RecoveryOS sur lequel s'effectue le démarrage n'est en rien le
RecoveryOS contenu dans le volume
APFS Recovery > mais son
clone créé à la volée dans un
RAMDisk > ce qui fait que le démarrage s'effectue sur un disque
indépendant du disque physique du Mac. Cela explique la lenteur aggravée de ce démarrage. C'est prouvé par une commande :
dans le «
Terminal»
Recovery > qui retourne la liste de toutes les images-disques montées en volume : une image-disque de la taille de la
Recovery (dans les
2 Go) se trouve désignée comme un
fichier-RAM (
ramfile) --> donc le disque est bien en
RAM.
Je lance l'option : "
Récupérer une sauvegarde Time Machine" (alors que je n'en ai aucune sur un disque dédié à des sauvegardes
TM classiques) --> l'application activée n'y voit aucun inconvénient > car une fois effectué le scan des volumes montés des disques attachés au Mac > elle affiche le volume de mon OS
APFS comme source possible de restauration. Je le choisis > et le
snapshot précédemment créé :
Bloc de code:
com.apple.TimeMachine.2017-11-03-172947
se trouve affiché comme source de restauration.
J'active cette restauration (ce sera bien la première fois que ça m'arrive d'utiliser une restauration de type
Time Machine) > et après un temps d'environ 15 à 20 secondes j'obtiens le message disant que le disque a été restauré à son état exact de la date du
snapshot.
Une re-démarrage automatique s'effectue > et me voici dans ma session recréée au contexte précis de la prise de l'instantané local.
Je reconnais que ce résultat me paraît impressionnant. Pourquoi s'embêter à se mettre dans les affres avant une MÀJ de sécurité par exemple ? Par une commande dans le «
Terminal» de l'OS :
Bloc de code:
sudo tmutil localshapshot
je crée un instantané local juste avant l'opération > et si j'ai des ennuis (genre : écran noir) > hop ! je démarre en mode
Recovery (en
RAM donc) > j'active la restauration
TM d'après l'instantané local du volume de l'OS > et 20 secondes après j'ai tout restauré comme avant la MÀJ foireuse.
Ce doit être un réflexe à prendre - en tout cas ça va plus vite qu'avec un clone.
----------
Alors
mézoùestdoncornicar - càd. où est stocké l'instantané local ?
Des recherches en ligne de commande avec
find et l'intitulé du
snapshot ne donnent absolument rien.
D'ailleurs il suffit d'un simple raisonnement pour exclure la possibilité que le
snapshot soit socké comme un fichier parmi les fichiers du volume-Système -->
- et si une foirade m'efface des kilomètres de fichiers du Système ? - si le snapshot était stocké comme un fichier dans les fichiers du volume > il serait balayé du même coup. Trop risqué.
- il est stipulé dans le man de tmutil (version High Sierra) que la restauration à partir d'un snapshot restaure tous les volumes APFS du Conteneur impliqué (et pas le simple volume-Système). Peut-on raisonnablement imaginer qu'un fichier local du volume du Système pourrait servir de source à ce type de restauration "systémique" ou 'structurale" complète ? Non - ça ne me paraît pas vraisemblable.
De fil en aiguille de cette spéculation "vagabonde" > je me dis que pour que le
snapshot puisse restaurer pas moins que l'
ensemble du
Conteneur APFS > il faut qu'il ait une "
position-racine" pour pouvoir exercer cette "
fonction-racine".
Je me décide donc à lancer une commande :
Bloc de code:
diskutil verifyVolume disk1
(où
disk1 est l'identifiant de disque logique du
Conteneur APFS global)
J'obtiens un affichage d'opérations complexes > impliquant à la fois le dispositif-racine "collectif" du
Conteneur et chacun des dispositifs locaux des volumes (un peu comme s'il s'agissait d'un "système de fichiers de systèmes de fichiers") > et vers la fin de la vérification > voici ce qui s'affiche :
Bloc de code:
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots
Checking snapshot 1 of 1
Eurêka ! Voici l'objet cherché et trouvé : le
snapshot. Il
n'appartient pas aux fichiers du volume monté > il
appartient aux fichiers du système de fichiers APFS.
Bref rappel : un système de fichiers ancré sur un en-tête de partition de disque définit un
point de montage sur la partition > qui est le
point de montage du volume (
dev node). Le volume monte comme
espace de répertoire affichant des écritures en forme de
fichiers interprétables. Mais jamais le système de fichiers ne se montre lui-même comme un fichier du volume. Non : le système de fichiers est une "pré-structure" de fichiers, toujours extérieure au volume qui en est l'effet.
Les
snapshots (ou instantanés
APFS) ne sont donc
pas des fichiers résidents d'un volume > mais des
composants du système de fichiers qui permet le montage du volume. D'après la vérification > un "fichier" (si je puis dire) intitulé le «
snapshot metadata tree » --> "arbre de métadonnées de snapshots". La localisation est donc interne à la
cause (le système de fichiers) > pas à l'
effet (le volume monté).
Ce qui explique qu'aussi longtemps qu'on ne reformate pas (n'efface pas le
Conteneur APFS) > le
snapshot reste indemne des péripéties des volumes montés à partir du système de fichiers
APFS.
Cette fantastique innovation doit quand même avoir des limites : je ne pense pas qu'un volume puisse être recréé en tant que volume s'il a été supprimé du
Conteneur, car la « branche logique » lui correspondant dans l'« arbre logique » du système de fichiers doit avoir du même coup été coupée.
Bonus : je m'explique la raison du démarrage
Recovery sur un
clone en
RAM : il faut cette position indépendante d'aucun volume monté du
Conteneur > pour que le «
snapshot metadata tree » du système de fichiers-racine puisse avoir une puissance de restauration de tous les volumes du
Conteneur APFS.
