Pourquoi un jeton de reprise d’envoi ZFS cesse-t-il de fonctionner après le redémarrage de la destination ?

Un redémarrage de la destination ne devrait normalement pas invalider un jeton de reprise ZFS, sauf si l’état de réception enregistré, le jeu de données ou l’historique source requis a été modifié.

Le jeton est une description opaque d’une réception interrompue précise, et non un signet réutilisable pour toute tentative de réplication ultérieure. Il appartient au système de fichiers ou au volume de destination qui a conservé l’état partiel lors d’une réception reprenable. Après un redémarrage, une tâche peut lire le mauvais jeu de données, importer le pool différemment, effacer l’état partiel, modifier la destination, perdre un instantané source requis ou générer un flux incompatible. Vérifiez le jeton aux deux extrémités avant de relancer un transfert complet.

Confirmer que l’état de réception partiel a survécu au redémarrage

Sur la destination, lisez la propriété receive_resume_token du système de fichiers ou du volume exact utilisé par la réception interrompue. Notez le nom du pool, le chemin du jeu de données, la valeur du jeton et l’espace utilisé par l’état partiel.

Le manuel FreeBSD explique que les réceptions reprenables préservent l’état partiel et conservent un jeton opaque sur le jeu de données de réception jusqu’à la fin du transfert ou à l’abandon explicite de cet état.

Si la propriété est vide après le redémarrage, la réception n’a pas été enregistrée avec l’option de reprise, l’état partiel a été terminé ou abandonné, le mauvais jeu de données est interrogé ou un nettoyage automatisé l’a supprimé. Ne réutilisez pas un jeton copié depuis un transfert antérieur.

Vérifier que le jeton appartient au jeu de données de destination exact

Vérifiez si le pool de destination a été importé sous le nom attendu et si la réplication cible toujours le même chemin de jeu de données. Soyez attentif aux racines alternatives, aux pools renommés, aux changements de chemin parent et aux options de tâche qui ajoutent ou suppriment des composants de chemin.

La référence des propriétés ZFS d’Ubuntu définit receive_resume_token comme une propriété de jeu de données, ce qui signifie que le jeton doit être lu depuis le système de fichiers ou le volume contenant cet état enregistré précis.

Un jeton récupéré depuis backup/pool/data ne peut pas être considéré comme pouvant reprendre sans risque une réception ciblant désormais backup/data. Corrigez le chemin de la tâche avant de modifier les instantanés ou de détruire la réception partielle.

Vérifier si la destination a été modifiée ou restaurée

Examinez les commandes, les tâches planifiées, les logiciels de réplication, la rétention des instantanés et l’activité des administrateurs depuis l’interruption. Recherchez une restauration, la promotion d’un clone, le renommage d’un jeu de données, l’abandon d’une réception ou une nouvelle réception vers la même cible.

Klara Systems indique que les outils de réplication gèrent l’état de destination autour de l’envoi et de la réception ZFS. Une tâche d’orchestration peut donc invalider le chemin de récupération initial en nettoyant ou en remplaçant l’état enregistré.

N’écrivez pas de fichiers ordinaires dans une destination de réplication pendant l’analyse. Même si le jeton existe toujours, des modifications de la destination peuvent bloquer le flux ou forcer une restauration qui détruira les données plus récentes de la destination.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Vérifier que la source possède toujours la chaîne d’instantanés ou de signets

Identifiez le jeu de données source ainsi que les instantanés ou signets encodés par le transfert interrompu. Comparez-les avec la rétention actuelle et avec les éventuels renommages ou suppressions d’instantanés survenus depuis l’arrêt du transfert.

Le manuel zfs-send de FreeBSD précise que zfs send -t génère un flux à partir du jeton de reprise de réception, reliant ainsi le nouveau flux à la réception interrompue plutôt qu’à un instantané actuel arbitraire.

Si la rétention a supprimé l’historique source requis, le jeton ne peut pas reconstruire des données qui n’existent plus. Préservez l’état partiel restant sur la destination jusqu’à ce que vous ayez déterminé si une autre copie source ou un nouvel envoi complet est nécessaire.

Vérifier les fonctionnalités du pool et les options de flux sur les deux systèmes

Notez les versions de ZFS, les fonctionnalités activées du pool, l’état du chiffrement et les options de flux d’origine, telles que les envois bruts, compressés, intégrés ou avec de grands blocs. Comparez-les après toute mise à niveau logicielle ou du pool.

La documentation Oracle sur la réplication reprenable décrit la reprise d’un transfert interrompu comme une opération coordonnée d’envoi et de réception. La compatibilité et le contexte du transfert d’origine restent donc importants après un redémarrage.

Un redémarrage seul ne modifie pas les indicateurs de fonctionnalité, mais une mise à niveau effectuée pendant l’interruption peut le faire. Reproduisez manuellement la commande de reprise avec une sortie détaillée avant de supposer que le jeton lui-même est corrompu.

Vérifier les services de réplication et SSH après le démarrage de la destination

Confirmez que le pool de destination est importé, que les jeux de données chiffrés requis sont déverrouillés, que SSH fonctionne, que l’utilisateur de réplication peut exécuter les commandes ZFS et que la tâche ne démarre qu’une fois le stockage prêt.

Les recommandations TrueNAS en matière de réplication distante exigent que les prérequis SSH et les jeux de données de destination soient disponibles après le redémarrage. Sinon, l’automatisation peut échouer avant même de tenter d’utiliser le jeton enregistré.

Testez l’authentification et une requête de propriété en lecture seule avant de lancer le flux repris. Une erreur de réseau ou d’autorisation peut ressembler à une erreur de jeton dans le journal d’une tâche de haut niveau.

Reprendre une fois ou abandonner délibérément la réception partielle

Générez un flux d’envoi repris à l’aide du jeton actuel et transmettez-le à une réception reprenable sur la même destination. Enregistrez l’intégralité de la sortie d’erreur et évitez de lancer des tâches de réplication parallèles.

Le guide de migration des données NAS de ZimaSpace fournit la règle de sécurité associée : préservez la source et le chemin de restauration jusqu’à ce que la destination ait été vérifiée.

Si le jeton est inutilisable et que l’état partiel n’a plus de valeur, abandonnez-le avec la commande prise en charge d’abandon de réception, uniquement après avoir confirmé qu’un transfert complet ou incrémentiel de remplacement peut être généré. L’abandon libère l’état partiel enregistré et est irréversible.

Foire aux questions

Un redémarrage de la destination invalide-t-il toujours un jeton de reprise ZFS ?

Non. Une réception partielle enregistrée est conçue pour survivre aux interruptions, y compris à un arrêt incorrect. Un échec après le redémarrage signifie généralement que la tâche lit un autre jeu de données, que l’état partiel a été effacé, que l’historique source requis a changé ou que des dépendances nécessaires au démarrage sont manquantes.

Peut-on générer un nouveau jeton de reprise uniquement depuis la source ?

Non. Le jeton opaque provient de l’état de réception partiel enregistré sur le jeu de données de destination. La source utilise ce jeton pour générer un flux de continuation, mais elle ne peut pas recréer seule un état de destination supprimé.

Quand faut-il abandonner la réception partielle ?

Abandonnez-la uniquement lorsque l’impossibilité de reprendre a été établie, que la source peut générer un transfert de remplacement et que l’état partiel de la destination n’est plus nécessaire à la récupération. Préservez les journaux et les instantanés disponibles avant de le supprimer.