Varför hoppar ögonblicksbildsreplikeringen över en krypterad underordnad dataset medan de andra överförs?
Replikering kan hoppa över en krypterad underordnad datamängd när dess aktivitetsomfattning, ögonblicksbildsuppsättning, krypteringsrot, sändningsläge, behörighet eller destinationspolicy skiljer sig från de andra.
Kryptering förhindrar inte automatiskt ZFS-ögonblicksbildsreplikering, och en rå krypterad sändning kan fungera även när nyckeln är urladdad. Den överhoppade underordnade datamängden har ofta en separat krypteringsrot, saknar det ögonblicksbildsnamn som valts av det rekursiva jobbet, undantas av aktiviteten, kräver behörighet för rå sändning eller kan inte tas emot enligt destinationens aktuella krypteringslayout. Jämför den underordnade datamängden med en fungerande motsvarighet egenskap för egenskap.
Bekräfta att den underordnade datamängden ingår i replikeringsomfattningen
Notera den valda källdatamängden, den rekursiva inställningen, undantagna underordnade datamängder, namnfilter, destinationssökväg och det exakta loggmeddelandet om den överhoppade datamängden.
TrueNAS dokumentation om fjärrreplikering kräver att källa och destination definieras uttryckligen, så en underordnad datamängd kan utelämnas medan de andra överförs.
Om den underordnade datamängden aldrig visas i aktivitetsplanen ska du korrigera urvalet eller undantagen innan du testar krypteringen.
Verifiera att den underordnade datamängden har den ögonblicksbild som aktiviteten kräver
Lista ögonblicksbilder rekursivt och jämför den överhoppade underordnade datamängden med en fungerande motsvarighet, inklusive ögonblicksbildsnamn, skapandetid, kvarhållningar och inkrementell bas.
FreeBSD-handboken beskriver ögonblicksbilder som datamängdsspecifika tillstånd, så ett ögonblicksbildsnamn på den överordnade datamängden bevisar inte att varje separat underordnad datamängd har den ögonblicksbild som krävs.
Skapa eller synkronisera ögonblicksbilder via den vanliga aktiviteten. En felaktig inkrementell kedja kan kräva en ny baslinje.
Jämför krypteringsrot, nyckelstatus och nyckelplats
Notera encryption, encryptionroot, keystatus, keyformat och keylocation för den överhoppade underordnade datamängden och en fungerande krypterad motsvarighet.
Ubuntus referens för ZFS-egenskaper definierar krypteringsrot och nyckelegenskaper, vilket visar om den underordnade datamängden ärver den överordnade datamängdens nyckel eller har en separat rot.
En urladdad nyckel blockerar inte alla råa sändningar, men den blockerar arbetsflöden som kräver åtkomst till klartext.
Kontrollera om aktiviteten kräver en rå krypterad sändning
Jämför alternativen för rå, icke-rå, rekursiv, egenskapsbevarande, komprimerad och inkrementell sändning för fungerande och överhoppade datamängder.
Oracle dokumenterar att rå krypterad replikering har särskilda krav på källa, mål och krypteringskontext.
Om den underordnade datamängden tidigare togs emot icke-rå och aktiviteten växlar till råa inkrementella sändningar kan destinationshistoriken vara inkompatibel.
Verifiera behörigheter för sändning, rå sändning, ögonblicksbilder och nycklar
Identifiera replikeringsanvändaren och jämför delegerade behörigheter på den överordnade datamängden, den överhoppade underordnade datamängden och den fungerande motsvarigheten.
OpenZFS dokumenterar delegerade administrationsbehörigheter, vilket förklarar varför åtkomsten kan skilja sig för en underordnad datamängd med en egen krypteringsrot.
Bevilja endast den åtgärd som saknas. Bred administratörsåtkomst döljer den verkliga gränsen och ökar risken.
Kontrollera destinationens kryptering och regler för arv
Jämför den överordnade destinationsdatamängdens krypteringstillstånd, om målets underordnade datamängd finns, dess krypteringsrot, ärvda egenskaper och mottagningsbeteende.
FreeBSD:s handbok för zfs receive förklarar att råa strömmar tas emot som de är, medan icke-råa strömmar kan följa andra regler för krypteringsarv.
En befintlig inkompatibel underordnad datamängd på destinationen kan avvisa just den datamängden medan de andra datamängderna som aktiviteten skapar lyckas.
Kör ett test med en datamängd och bevara fungerande replikering
Pausa schemat, generera en uppskattning av sändningen med torrkörning eller utförlig loggning för den överhoppade underordnade datamängden och jämför den med en fungerande motsvarighet.
ZimaSpace-artikeln om varningssignaler för krypterade återställningsnycklar innehåller den kompletterande säkerhetsregeln: verifiera nyckelberoenden innan du raderar den enda krypterade kopian.
Problemet är löst när den underordnade datamängden ingår i omfattningen, har de ögonblicksbilder som krävs, använder ett kompatibelt sändningsläge, klarar behörighetskontrollerna och tas emot enligt den avsedda krypteringslayouten.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
