Perché la replica degli snapshot salta un dataset figlio crittografato mentre gli altri vengono trasferiti?
La replica può saltare un dataset figlio crittografato quando l’ambito dell’attività, il set di snapshot, la radice di crittografia, la modalità di invio, le autorizzazioni o i criteri della destinazione differiscono da quelli dei dataset fratelli.
La sola crittografia non impedisce automaticamente la replica degli snapshot ZFS e un invio crittografato raw può funzionare anche quando la chiave non è caricata. Il dataset figlio ignorato spesso ha una radice di crittografia separata, non dispone del nome dello snapshot selezionato dall’attività ricorsiva, è escluso dall’attività, richiede l’autorizzazione per l’invio raw oppure non può essere ricevuto con l’attuale configurazione di crittografia della destinazione. Confronta il dataset figlio con un dataset fratello funzionante, proprietà per proprietà.
Conferma che il dataset figlio rientri nell’ambito della replica
Annota il dataset sorgente selezionato, l’impostazione ricorsiva, i figli esclusi, i filtri di denominazione, il percorso di destinazione e il messaggio esatto del registro relativo al dataset ignorato.
La documentazione di TrueNAS sulla replica remota richiede che l’ambito di origine e destinazione sia definito esplicitamente, quindi un figlio può essere omesso mentre i dataset fratelli vengono trasferiti.
Se il figlio non compare mai nel piano dell’attività, correggi prima la selezione o le esclusioni, quindi verifica la crittografia.
Verifica che il dataset figlio disponga dello snapshot richiesto dall’attività
Elenca ricorsivamente gli snapshot e confronta il dataset figlio ignorato con un dataset fratello funzionante, includendo il nome dello snapshot, l’ora di creazione, i blocchi e la base incrementale.
Il manuale di FreeBSD descrive gli snapshot come stati specifici del dataset, quindi il nome dello snapshot del genitore non dimostra che ogni figlio indipendente disponga dello snapshot richiesto.
Crea o allinea gli snapshot tramite l’attività standard. Una catena incrementale non corrispondente potrebbe richiedere una nuova baseline.
Confronta la radice di crittografia, lo stato della chiave e la posizione della chiave
Annota encryption, encryptionroot, keystatus, keyformat e keylocation per il dataset figlio ignorato e per un dataset fratello crittografato funzionante.
Il riferimento alle proprietà ZFS di Ubuntu definisce la radice di crittografia e le proprietà della chiave, mostrando se il figlio eredita la chiave del genitore o possiede una radice separata.
Una chiave non caricata non blocca ogni invio raw, ma blocca i flussi di lavoro che richiedono l’accesso in chiaro.
Verifica se l’attività richiede un invio crittografato raw
Confronta le opzioni di invio raw, non raw, ricorsivo, con conservazione delle proprietà, compresso e incrementale per i dataset funzionanti e ignorati.
Oracle documenta che la replica crittografata raw ha requisiti specifici per la sorgente, la destinazione e il contesto di crittografia.
Se il figlio è stato precedentemente ricevuto in modalità non raw e l’attività passa agli incrementali raw, la cronologia della destinazione potrebbe non essere compatibile.
Verifica le autorizzazioni per invio, invio raw, snapshot e chiavi
Identifica l’utente della replica e confronta le autorizzazioni delegate sul genitore, sul figlio ignorato e sul dataset fratello funzionante.
OpenZFS documenta le autorizzazioni di amministrazione delegate, spiegando perché l’accesso può differire per un figlio con una propria radice di crittografia.
Concedi solo l’operazione mancante. Un accesso amministrativo ampio nasconde il vero confine e aumenta i rischi.
Verifica la crittografia della destinazione e le regole di ereditarietà
Confronta lo stato di crittografia del genitore di destinazione, verifica se il figlio di destinazione esiste, la sua radice di crittografia, le proprietà ereditate e il comportamento durante la ricezione.
Il manuale di zfs receive di FreeBSD spiega che i flussi raw vengono ricevuti così come sono, mentre i flussi non raw possono seguire regole diverse di ereditarietà della crittografia.
Un figlio di destinazione preesistente e incompatibile può rifiutare solo quel dataset, mentre i dataset fratelli creati dall’attività vengono trasferiti correttamente.
Esegui un test su un solo dataset e preserva la replica funzionante
Metti in pausa la pianificazione, genera una stima dell’invio in modalità di prova o dettagliata per il dataset figlio ignorato e confrontala con quella di un dataset fratello funzionante.
L’articolo di ZimaSpace sui segnali di allarme delle chiavi di ripristino crittografate fornisce la regola di sicurezza correlata: verifica le dipendenze delle chiavi prima di eliminare l’unica copia crittografata.
Il problema è risolto quando il figlio rientra nell’ambito, dispone degli snapshot richiesti, utilizza una modalità di invio compatibile, supera il controllo delle autorizzazioni e viene ricevuto secondo la configurazione di crittografia prevista.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
