Comment préserver l’identité d’une sauvegarde Time Machine avant de renommer ou de recréer un partage NAS

Time Machine est moins susceptible d’abandonner un historique NAS existant lorsque l’identité de sauvegarde du partage est préservée avant de renommer, de reconstruire ou de migrer ce partage.

Une destination Time Machine en réseau est plus qu’un dossier contenant un sparsebundle. Le Mac peut également dépendre du volume réseau annoncé, des capacités SMB, du chemin du partage, des identifiants et d’un identifiant de volume attribué par le service. Avant de modifier le NAS, consignez ces éléments d’identité et protégez le sparsebundle existant. Reconstruisez ou renommez ensuite une couche à la fois et vérifiez que le Mac reconnaît toujours la destination prévue avant d’autoriser le démarrage d’une nouvelle sauvegarde.

Consignez la destination réseau actuelle avant la maintenance

Enregistrez le nom d’hôte du NAS, l’adresse SMB, le nom du partage, le compte, la destination Time Machine sélectionnée, le nom du sparsebundle et la taille actuelle de la sauvegarde. Notez également la manière dont le partage est découvert, par exemple via une annonce Bonjour ou un chemin SMB monté manuellement.

Apple explique qu’un disque Time Machine réseau est sélectionné comme destination réseau, et qu’il ne s’agit pas simplement d’un dossier contenant des fichiers de sauvegarde.

Effectuez un instantané du NAS ou une copie indépendante du sparsebundle avant de modifier la définition du partage. Vous disposerez ainsi d’un point de restauration si le service reconstruit une autre identité de destination ou si le Mac démarre un nouvel historique.

Préservez l’UUID du volume Time Machine lorsque le NAS le permet

Si le NAS expose un UUID de volume Time Machine ou un identifiant persistant similaire, notez-le avant de supprimer ou de recréer le partage SMB. Ne supposez pas que le même nom de partage visible régénérera la même identité.

TrueNAS indique que son UUID Time Machine identifie le volume, et que la création ou la mise à jour d’un partage avec une valeur nulle peut générer un nouvel UUID.

Ne restaurez l’ancien identifiant que lorsque le partage reconstruit représente réellement la même destination de sauvegarde et que l’ancienne instance du serveur n’est plus active. Dupliquer un même UUID sur deux destinations actives crée sa propre ambiguïté.

Conservez la prise en charge SMB de Time Machine sur le partage reconstruit

Recréer un partage SMB standard au même chemin du système de fichiers ne suffit pas. Vérifiez que le partage reconstruit annonce toujours la prise en charge de Time Machine ainsi que les extensions SMB d’Apple attendues par le Mac.

Le module vfs_fruit de Samba indique que la prise en charge de Time Machine est annoncée via la capacité FULLSYNC du partage et l’enregistrement mDNS lorsque cette fonction est disponible.

Comparez les paramètres de l’ancien et du nouveau partage Samba ou NAS avant de reconnecter le Mac. Si la capacité a changé, corrigez d’abord la présentation du serveur plutôt que de supprimer ou de renommer le sparsebundle.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Ne réutilisez pas un identifiant de volume sans réflexion

Un identifiant de volume réseau préservé n’est utile que lorsqu’il désigne la même destination de sauvegarde logique. Si vous clonez l’ancien partage sur un second NAS actif, les deux serveurs ne doivent pas prétendre être exactement le même volume Time Machine.

Netatalk avertit que son UUID de volume assure une distinction fiable et ne doit pas être modifié ou copié machinalement sur un autre serveur.

Pendant la migration, ne gardez qu’une seule destination faisant autorité à la fois. Mettez le remplacement en ligne avec l’identité préservée uniquement après avoir arrêté le service précédent et terminé la copie du sparsebundle.

Préservez Bonjour et la sélection du partage pendant la bascule

Notez quel dossier partagé est explicitement désigné pour Time Machine et si Bonjour annonce ce dossier. Après avoir reconstruit le NAS, vérifiez que le même dossier est publié avant de le sélectionner à nouveau sur le Mac.

Les recommandations actuelles de Synology demandent aux administrateurs de définir le dossier Time Machine et d’activer la diffusion Bonjour de Time Machine lors de l’utilisation de cette méthode de découverte.

Si le nom d’hôte du NAS doit changer, vérifiez d’abord que le partage prévu est accessible via son nouveau chemin SMB et qu’il contient toujours le sparsebundle protégé. Ne laissez pas un partage de remplacement vide devenir la première destination visible par le Mac.

Testez l’historique existant avant de reprendre les sauvegardes automatiques

Après avoir suspendu les sauvegardes automatiques, reconnectez-vous à la destination reconstruite, confirmez que l’ancien sparsebundle est visible, puis parcourez ou restaurez un fichier connu de l’historique précédent. Surveillez le partage afin de détecter la création d’un second sparsebundle lors de la première sauvegarde contrôlée.

ASUSTOR recommande SMB pour les sauvegardes Time Machine sur les systèmes NAS pris en charge, ce qui confirme que la présentation SMB spécifique de Time Machine par le serveur fait partie intégrante de la destination.

La maintenance est terminée lorsque Time Machine ajoute des données à l’historique existant et qu’aucun second bundle n’apparaît. L’article ZimaSpace associé sur la création d’un nouveau sparsebundle Time Machine constitue la procédure de récupération si l’identité n’a pas été préservée et que le Mac a déjà commencé une nouvelle sauvegarde.

Foire aux questions

Conserver le même nom de partage SMB suffit-il ?

Non. Le nom visible n’est qu’un des éléments pris en compte. Le NAS peut recréer le partage avec une prise en charge Time Machine, une annonce de service, des identifiants ou une identité de volume différents.

Dois-je renommer le sparsebundle existant pour l’adapter au NAS reconstruit ?

Pas comme raccourci préventif. Préservez d’abord le bundle et maintenez l’identité de la destination stable : renommer l’image ne met pas automatiquement à jour les relations utilisées par Time Machine.

Puis-je tester le partage reconstruit alors que l’ancien serveur Time Machine est encore actif ?

Faites preuve de prudence. Deux destinations actives présentant la même identité logique peuvent perturber la découverte et rendre difficile l’identification du sparsebundle mis à jour. Préférez une bascule contrôlée avec un seul serveur faisant autorité.