Quand faut-il réinitialiser une chaîne de réplication ZFS interrompue ?

Réensemencez lorsque vous ne pouvez pas prouver l’existence d’une base commune valide ou lorsque la réparation de la chaîne nécessiterait un retour en arrière non vérifié de la destination. Préservez d’abord la dernière réplique lisible.

Sur un NAS domestique, le raccourci tentant consiste à forcer l’envoi incrémentiel suivant jusqu’à ce qu’il s’exécute. Cela peut masquer l’absence d’un instantané parent, une destination divergente ou une cible de réception qui n’est plus le jeu de données que vous pensez. Commencez par inventorier les deux côtés sans modifier l’un ou l’autre, vérifiez qu’une base partagée existe toujours et utilisez un réensemencement complet par étapes lorsque les éléments disponibles ne permettent pas de poursuivre l’incrémentation en toute sécurité.

Vérifiez que les deux côtés partagent toujours la même base

Commencez par un inventaire en lecture seule du jeu de données source, du jeu de données de destination, des instantanés, des signets et de tout état de reprise de réception. Ne vous contentez pas de faire correspondre un nom d’instantané pratique : confirmez que la base candidate appartient aux jeux de données prévus et représente le même historique de réplication. Enregistrez les listes avant tout nettoyage afin de pouvoir expliquer le choix de l’action suivante.

La réplication incrémentielle ZFS dépend de la présence, sur le récepteur, d’une base existante. Une séquence de réplication d’instantanés pratique préserve donc délibérément l’historique partagé au lieu de supposer que des libellés identiques prouvent la continuité.

Si une base vérifiée existe des deux côtés, passez à un test incrémentiel non destructif. Si le nom existe mais que l’identité ou le chemin du jeu de données diffère, considérez la chaîne comme non vérifiée. Si aucune base commune ne subsiste, ne supprimez pas davantage d’instantanés et ne forcez pas la destination à revenir en arrière ; la décision s’est déjà orientée vers un réensemencement par étapes.

Testez le plan incrémentiel sans modifier la réplique

Construisez l’envoi proposé avec la base vérifiée et la cible la plus récente, mais ne l’envoyez pas encore vers la destination active. Utilisez une exécution à blanc, une estimation détaillée ou le mode d’aperçu de l’outil de réplication. Confirmez le chemin source, le chemin de destination, l’instantané de base, l’instantané cible, les options de récursivité et la taille attendue du flux avant qu’une réception puisse modifier les données.

Un ordonnanceur qui signale l’absence d’instantané de base commun refuse une supposition dangereuse ; il ne demande pas simplement une nouvelle tentative. Des tentatives répétées ne recréent pas un historique partagé supprimé.

Un flux de taille correspondant aux seules différences, produit depuis la base et la cible exactes, permet d’envisager la réparation de la chaîne. Un flux proche de la taille totale du jeu de données, un jeu de données inattendu ou toute exigence de retour en arrière forcé signifie que l’aperçu a échoué. Arrêtez-vous là et préservez la réplique actuelle ; modifier les options jusqu’à ce que la commande s’exécute ne constitue pas une vérification.

Ne choisissez la réparation que lorsque l’historique et l’état de la destination concordent

Réparez le chemin incrémentiel uniquement lorsque la base commune est vérifiée, que la destination n’est pas devenue une copie de travail indépendante et que l’aperçu propose la différence attendue. Gardez la destination en lecture seule pendant la fenêtre de réparation. Envoyez d’abord les données vers un nouveau jeu de données enfant ou une cible intermédiaire lorsque l’outil le permet, puis comparez-les avant de les promouvoir.

Réensemencez lorsqu’aucune base valide n’existe, que la destination a divergé, que le retour en arrière requis supprimerait des instantanés dont vous avez encore besoin ou que le temps consacré à prouver la chaîne dépasse le coût maîtrisé d’un nouveau transfert complet. Les discussions sur l’ascendance des instantanés incrémentiels confirment que les noms intermédiaires sont moins importants que la conservation d’un point commun utilisable.

N’effacez pas l’ancienne destination pour libérer de l’espace à moins qu’une autre copie vérifiée n’existe. Un réensemencement plus sûr écrit vers un jeu de données ou un pool distinct, vérifie la nouvelle copie, puis retire seulement la chaîne défaillante. S’il n’y a pas assez de capacité pour conserver les deux, interrompez l’opération et obtenez de l’espace temporaire plutôt que de transformer la dernière réplique lisible en terrain d’expérimentation.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Validez la nouvelle chaîne sur deux cycles de réplication

Une seule réception complète réussie prouve uniquement qu’un flux est arrivé. Créez un petit fichier de test ou modifiez une propriété sur la source, prenez l’instantané planifié suivant et exécutez un deuxième cycle incrémentiel en utilisant la nouvelle base commune. Comparez les propriétés des jeux de données, les listes d’instantanés, un échantillon de fichiers et le journal de réplication après les deux exécutions.

Si le comportement de reprise faisait partie de l’échec initial, gardez le chemin d’échec du jeton de reprise distinct de l’absence d’ascendance afin que le même symptôme ne vous oriente pas vers la mauvaise réparation.

La récupération est réussie lorsque le nouveau réensemencement est lisible, que le deuxième transfert incrémentiel est réussi et de taille correspondant aux différences, et que les instantanés et fichiers attendus apparaissent après un redémarrage ou une exécution planifiée. Conservez l’ancienne réplique jusqu’à la réussite de ces vérifications. Faites remonter le problème si les identités changent à nouveau, si la destination ne peut pas rester en lecture seule ou si l’outil sélectionne régulièrement une base inattendue.