Comment vérifier que la réplication ZFS peut reprendre après un transfert interrompu

Oui, lorsque le côté réception conserve un jeton de reprise valide et que les instantanés source nécessaires à ce jeton existent toujours.

Cette décision est importante lorsqu'un zfs send brut ou incrémentiel est interrompu par une panne du réseau ou de la destination. Les deux états en concurrence sont le jeton de reprise de réception valide et l'absence de jeton ou la destruction de l'instantané source. Commencez avec une configuration enregistrée et des données jetables, observez une seule branche à la fois et arrêtez-vous si le test accroît le risque de perte de données, de permissions ou de disponibilité.

Définir les conditions qui sous-tendent la décision de réplication ZFS reprenable

Consignez l'environnement avant toute modification : versions des logiciels et des micrologiciels, identités des appareils, chemin de montage ou réseau, espace libre, permissions et symptôme observable. La base de référence doit conserver suffisamment de détails pour reproduire l'interruption d'un zfs send brut ou incrémentiel par une panne du réseau ou de la destination.

Le premier scénario est celui d'un jeton de reprise de réception valide. Le second est celui de l'absence de jeton ou de la destruction de l'instantané source. Le zfs send reprenable actuel définit le mécanisme ou la limite de commande utilisé dans le test ; il ne remplace pas l'observation effectuée sur 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 sans rapport inchangés ; un échec doit ramener le système à l'état enregistré plutôt que déclencher une succession de corrections spéculatives.

Tester l'affirmation sans réduire l'exigence initiale

Utilisez ce test discriminant : interrompez une réplication jetable, lisez le jeton, générez un flux send repris et comparez l'instantané final de destination. Gardez 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 l'envoi et la réception ZFS pour sélectionner le champ capable de distinguer réellement les branches, puis capturez son horodatage, son statut de sortie, le texte de l'erreur, l'identité de l'appareil ou de l'instantané, la latence, les octets transférés, les permissions et l'état de récupération. Une sortie de commande sans erreur ne suffit pas lorsque l'identité, la durabilité ou l'état de l'application constitue l'affirmation testée.

Répétez le test une fois après un redémarrage, une reconnexion, un remontage ou avec un cache froid lorsque cet événement fait partie de la condition initiale. Si le premier essai est destructeur ou si l'environnement ne peut pas être restauré, arrêtez-vous et reproduisez-le sur une copie jetable.

token=$(zfs get -H -o value receive_resume_token pool/dst)
zfs send -t "$token" | ssh nas zfs receive pool/dst

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

RÉUSSITE : le flux repris se termine et les instantanés source et destination partagent la lignée GUID attendue. Consignez la version exacte, l'identité et la charge qui ont réussi afin que la conclusion reste conditionnelle plutôt que de devenir une affirmation universelle.

ÉCHEC : aucun jeton n'existe, la destination a été restaurée à un état antérieur ou les instantanés source requis ont été supprimés. Un échec ne prouve pas automatiquement la branche opposée lorsque le réseau, la mémoire, les permissions ou la cohérence de la source peuvent influencer les deux ; isolez ces dépendances communes avant d'aller plus loin.

EXCEPTION OU RÉSULTAT AMBIGU : abandonnez la réception partielle uniquement après avoir décidé que le coût d'un redémarrage est acceptable. Conservez les journaux et n'exécutez aucune commande de réparation, de purge, de destruction, de repartitionnement ou de modification récursive des propriétaires avant de disposer d'une copie récupérable.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Confirmer la décision dans les conditions de charge initiales

Appliquez l'action correspondant à la branche observée, puis répétez la condition initiale plutôt qu'un substitut simplifié. La décision n'est valide que lorsque le flux repris se termine et que les instantanés source et destination partagent la lignée GUID attendue sur deux cycles ou lors du redémarrage, de la mise en veille, de l'interruption ou de la transition de charge concernés.

Utilisez les fenêtres de sauvegarde immuables pour vérifier le flux de travail dépendant le plus proche, mais conservez le déclencheur initial inchangé. Les ensembles de données, partages, conteneurs, utilisateurs et points de récupération sans rapport doivent conserver leur accès et leur calendrier précédents.

La limite d'arrêt est explicite : si aucun jeton n'existe, si la destination a été restaurée à un état antérieur ou si les instantanés source requis ont été supprimés, 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 si la branche est reproductible.

Une fois le résultat cible obtenu, comparez-le à la structure du dépôt local afin que la correction ne déplace pas le risque vers un service voisin. Un test cible réussi accompagné d'une nouvelle défaillance de sauvegarde, d'identité, de délai d'attente ou de disponibilité reste une modification échouée.

FAQ

Pour la réplication ZFS reprenable, les recherches restantes portent généralement sur les questions suivantes : chaque réception interrompue crée-t-elle un jeton, peut-on supprimer les anciens instantanés source après une interruption et comment vérifier la réplique finale. Les réponses ci-dessous maintiennent ces cas limites séparés de la décision principale.

La limite d'acceptation ne change pas : le flux repris se termine et les instantanés source et destination partagent la lignée GUID attendue. Si une condition de suivi 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 concerné par cette modification.

Arrêtez d'élargir l'expérience lorsqu'aucun jeton n'existe, que la destination a été restaurée à un état antérieur ou que les instantanés source requis ont été supprimés. À ce stade, abandonnez la réception partielle uniquement après avoir décidé que le coût d'un redémarrage est acceptable ; conservez les éléments probants avant de transmettre le problème au responsable de la plateforme, du stockage ou du matériel.

Chaque réception interrompue crée-t-elle un jeton ?

Non. La réception doit utiliser un comportement reprenable et échouer dans un état qui conserve un jeton.

Peut-on supprimer les anciens instantanés source après une interruption ?

Pas tant que le flux repris en dépend et que la destination n'a pas été vérifiée.

Comment vérifier la réplique finale ?

Comparez la lignée GUID des instantanés, les propriétés, les fichiers attendus et un échantillon de restauration, et pas uniquement le statut de sortie de la commande.

Pour la réplication ZFS reprenable, la réponse pratique reste conditionnelle : le flux repris se termine et les instantanés source et destination partagent la lignée GUID attendue. Lorsqu'aucun jeton n'existe, que la destination a été restaurée à un état antérieur ou que les instantanés source requis ont été supprimés, abandonnez la réception partielle uniquement après avoir décidé que le coût d'un redémarrage est acceptable ; une réussite partielle qui ne résiste pas aux conditions de charge initiales n'est pas une compatibilité.