Pourquoi la réplication des instantanés ignore-t-elle un jeu de données enfant chiffré alors que les autres sont transférés ?
La réplication peut ignorer un jeu de données enfant chiffré lorsque sa portée de tâche, son ensemble d’instantanés, sa racine de chiffrement, son mode d’envoi, ses autorisations ou la politique de destination diffère de ceux de ses frères.
Le chiffrement n’empêche pas automatiquement la réplication des instantanés ZFS, et un envoi chiffré brut peut fonctionner même lorsque la clé est déchargée. L’enfant ignoré possède souvent une racine de chiffrement distincte, ne dispose pas du nom d’instantané sélectionné par la tâche récursive, est exclu par la tâche, nécessite l’autorisation d’envoi brut ou ne peut pas être reçu dans la configuration de chiffrement actuelle de la destination. Comparez les propriétés de l’enfant avec celles d’un frère fonctionnel, propriété par propriété.
Confirmer que le jeu de données enfant se trouve dans la portée de réplication
Notez le jeu de données source sélectionné, le paramètre récursif, les enfants exclus, les filtres de nommage, le chemin de destination et le message exact du journal concernant le jeu de données ignoré.
La documentation de TrueNAS sur la réplication à distance exige que la portée de la source et de la destination soit définie explicitement. Un enfant peut donc être omis tandis que ses frères sont transférés.
Si l’enfant n’apparaît jamais dans le plan de la tâche, corrigez la sélection ou l’exclusion avant de tester le chiffrement.
Vérifier que l’enfant possède l’instantané requis par la tâche
Répertoriez les instantanés de manière récursive et comparez l’enfant ignoré avec un frère fonctionnel, notamment le nom de l’instantané, sa date de création, ses conservations et sa base incrémentielle.
Le manuel FreeBSD décrit les instantanés comme des états propres à chaque jeu de données. Le nom d’un instantané parent ne prouve donc pas que chaque enfant indépendant possède l’instantané requis.
Créez ou alignez les instantanés au moyen de la tâche normale. Une chaîne incrémentielle incohérente peut nécessiter une nouvelle base.
Comparer la racine de chiffrement, l’état de la clé et son emplacement
Notez les propriétés encryption, encryptionroot, keystatus, keyformat et keylocation de l’enfant ignoré et d’un frère chiffré fonctionnel.
La référence des propriétés ZFS d’Ubuntu définit les propriétés de racine de chiffrement et de clé, révélant si l’enfant hérite de la clé de son parent ou possède sa propre racine.
Une clé déchargée ne bloque pas tous les envois bruts, mais elle bloque les flux de travail qui nécessitent un accès en clair.
Vérifier si la tâche nécessite un envoi chiffré brut
Comparez les options d’envoi brut, non brut, récursif, de conservation des propriétés, de compression et d’envoi incrémentiel pour les jeux de données fonctionnels et ignorés.
Oracle indique que la réplication chiffrée brute répond à des exigences précises concernant la source, la cible et le contexte de chiffrement.
Si l’enfant a déjà été reçu en mode non brut et que la tâche passe aux incrémentiels bruts, l’historique de la destination peut être incompatible.
Vérifier les autorisations d’envoi, d’envoi brut, d’instantané et de clé
Identifiez l’utilisateur de réplication et comparez les autorisations déléguées sur le parent, l’enfant ignoré et le frère fonctionnel.
OpenZFS documente les autorisations d’administration déléguées, ce qui explique pourquoi l’accès peut différer pour un enfant doté de sa propre racine de chiffrement.
Accordez uniquement l’opération manquante. Un accès administrateur étendu masque la véritable limite et augmente les risques.
Vérifier le chiffrement de la destination et les règles d’héritage
Comparez l’état de chiffrement du parent de destination, l’existence éventuelle de l’enfant cible, sa racine de chiffrement, les propriétés héritées et le comportement lors de la réception.
Le manuel zfs receive de FreeBSD explique que les flux bruts sont reçus tels quels, tandis que les flux non bruts peuvent suivre un héritage de chiffrement différent.
Un enfant de destination préexistant et incompatible peut rejeter uniquement ce jeu de données, tandis que les frères créés par la tâche réussissent.
Effectuer un test sur un seul jeu de données et préserver la réplication fonctionnelle
Mettez la planification en pause, générez une estimation d’envoi à blanc ou détaillée pour l’enfant ignoré, puis comparez-la avec celle d’un frère fonctionnel.
L’article de ZimaSpace sur les signes avant-coureurs indiquant qu’une clé de récupération chiffrée ne fonctionnera pas fournit la règle de sécurité complémentaire : vérifiez les dépendances de clé avant de supprimer l’unique copie chiffrée.
Le problème est résolu lorsque l’enfant est inclus dans la portée, possède les instantanés requis, utilise un mode d’envoi compatible, dispose des autorisations nécessaires et est reçu selon la configuration de chiffrement prévue.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
