Ja. En raw send kan replikera krypterade block och krypteringsmetadata utan att läsa in datasetnyckeln på det mottagande systemet.
Beslutet är viktigt när en off-site-NAS ska lagra en ZFS-replik men inte får ha klartextnycklar. De två konkurrerande tillstånden är raw encrypted send och receive samt non-raw send, inkompatibla funktioner eller ett fel i nyckelhanteringen. Börja med en sparad konfiguration och engångsdata, observera en gren i taget och avbryt om testet ökar risken för dataförlust, behörighetsproblem eller otillgänglighet.
Definiera villkoren bakom beslutet om raw-krypterad ZFS-replikering
Dokumentera miljön innan du ändrar något: programvaru- och firmwareversioner, enhetsidentiteter, monterings- eller nätverkssökväg, ledigt utrymme, behörigheter och det observerbara symtomet. Baslinjen måste innehålla tillräckligt med detaljer för att återskapa situationen där en off-site-NAS ska lagra en ZFS-replik men inte får ha klartextnycklar.
Den första kandidaten är raw encrypted send och receive. Den andra är non-raw send, inkompatibla funktioner eller ett fel i nyckelhanteringen. Den aktuella raw encrypted ZFS send definierar mekanismen eller kommandogränsen som används i testet; den ersätter inte observationer från just den här hemservern.
Skriv ned godkännandekriteriet och stoppkriteriet innan du kör särskiljningstestet. Ett godkänt resultat måste ändra de bevis som förutsägs av en gren, samtidigt som orelaterade tjänster förblir oförändrade; ett underkänt resultat måste återställa systemet till det sparade tillståndet i stället för att utlösa en kedja av spekulativa korrigeringar.
Testa påståendet utan att sänka det ursprungliga kravet
Använd detta särskiljningstest: skicka en krypterad ögonblicksbild med engångsdata i raw-läge, ta emot den utan att läsa in den, granska krypteringsegenskaperna och återställ sedan på ett system som har nyckeln. Håll arbetsbelastning, klient, sökväg, filuppsättning och tidsförlopp konstanta så att resultatet kan tillskrivas den ändrade variabeln.
Använd ZFS encryption behavior för att välja det fält som faktiskt kan skilja grenarna åt och samla sedan in dess tidsstämpel, avslutningsstatus, feltext, enhets- eller ögonblicksbildsidentitet, fördröjning, överförda byte, behörigheter och återställningstillstånd. Ett felfritt kommandoavslut räcker inte när identitet, beständighet eller programtillstånd är det som testas.
Upprepa testet en gång efter en omstart, återanslutning, ny montering eller tom cache när en sådan händelse ingår i det ursprungliga villkoret. Om den första körningen är destruktiv eller miljön inte kan återställas ska du avbryta och återskapa testet på en engångskopia i stället.
zfs send -w pool/secure@snap | ssh backup zfs receive backup/secure
Tolka godkända, underkända och avvikande resultat
GODKÄNT: Mottagaren lagrar och tar ögonblicksbilder av datasetet medan klartext förblir otillgänglig tills nyckeln läses in någon annanstans. Dokumentera den exakta versionen, identiteten och arbetsbelastningen som godkändes så att slutsatsen förblir villkorad i stället för att bli ett universellt påstående.
UNDERKÄNT: Mottagarsidan kan montera klartext, egenskaper omvandlas oväntat eller den inkrementella härstamningen bryts. Ett underkänt resultat bevisar inte automatiskt den motsatta grenen när nätverk, minne, behörigheter eller källans konsistens kan påverka båda; isolera dessa gemensamma beroenden innan du eskalerar.
AVVIKANDE ELLER TVETYDIGT RESULTAT: Förstör endast den tillfälliga repliken och korrigera raw-send samt nyckelhantering innan produktion. Bevara loggarna och kör inte reparations-, rensnings-, förstörings-, ompartitionerings- eller rekursiva ägarskapskommandon förrän det finns en återställningsbar kopia.
Bekräfta beslutet under den ursprungliga arbetsbelastningen
Tillämpa åtgärden som motsvarar den observerade grenen och upprepa sedan det ursprungliga villkoret i stället för en förenklad ersättning. Beslutet gäller endast när mottagaren lagrar och tar ögonblicksbilder av datasetet medan klartext förblir otillgänglig tills nyckeln läses in någon annanstans under två cykler eller den relevanta övergången vid omstart, viloläge, avbrott eller belastning.
Använd de oföränderliga säkerhetskopieringsfönstren för att kontrollera det närmast beroende arbetsflödet, men låt den ursprungliga utlösaren vara oförändrad. Orelaterade dataset, utdelningar, containrar, användare och återställningspunkter måste behålla sin tidigare åtkomst och tidsåtgång.
Stoppgränsen är tydlig: om mottagarsidan kan montera klartext, egenskaper omvandlas oväntat eller den inkrementella härstamningen bryts ska du återgå till den senast verifierade konfigurationen, behålla bevisen och eskalera till ett djupare plattforms- eller hårdvarutest endast när grenen kan reproduceras.
När målresultatet har uppnåtts ska du jämföra det med replikverifieringen så att lösningen inte flyttar risken till en närliggande tjänst. Ett lyckat måltest med ett nytt fel i säkerhetskopiering, identitet, tidsgräns eller tillgänglighet är fortfarande en misslyckad ändring.
Vanliga frågor
För raw-krypterad ZFS-replikering gäller de återstående frågorna vanligtvis om destinationen behöver krypteringsnyckeln, om raw-sändningar kan vara inkrementella och om datasetnamn och storlekar är dolda. Svaren nedan håller dessa specialfall åtskilda från huvudbeslutet.
Godkännandegränsen flyttas inte: mottagaren lagrar och tar ögonblicksbilder av datasetet medan klartext förblir otillgänglig tills nyckeln läses in någon annanstans. Om ett uppföljande villkor ändrar filsystemet, identiteten, nätverkssökvägen eller programversionen ska du upprepa endast det särskiljningstest som påverkas av ändringen.
Sluta bredda experimentet när mottagarsidan kan montera klartext, egenskaper omvandlas oväntat eller den inkrementella härstamningen bryts. Förstör då endast den tillfälliga repliken och korrigera raw-send samt nyckelhantering före produktion; bevara bevisen innan du eskalerar till plattforms-, lagrings- eller hårdvaruansvarig.
Behöver destinationen krypteringsnyckeln?
Inte för raw-mottagning och lagring; den behöver en nyckel endast för att läsa in och komma åt klartext.
Kan raw-sändningar vara inkrementella?
Ja, när ögonblicksbildens härstamning och funktionskompatibilitet bevaras.
Är datasetnamn och storlekar dolda?
Nej. Raw-kryptering skyddar innehåll och viss metadata, men inte all driftinformation som är synlig för pooladministratören.
För raw-krypterad ZFS-replikering är det praktiska svaret fortfarande villkorat: mottagaren lagrar och tar ögonblicksbilder av datasetet medan klartext förblir otillgänglig tills nyckeln läses in någon annanstans. När mottagarsidan kan montera klartext, egenskaper omvandlas oväntat eller den inkrementella härstamningen bryts ska du förstöra endast den tillfälliga repliken och korrigera raw-send samt nyckelhantering före produktion; en delvis lyckad körning som inte klarar den ursprungliga arbetsbelastningen är inte kompatibilitet.
Support och tips
Mer att läsa

Kan ett egenhostat galleri bevara parkopplingen mellan Apple Live Photos?
Ett villkorat beslut för hemmaservern om parkoppling med Apple Live Photo, med kontrollerade tester, resultattolkning, återställning och fokuserade vanliga frågor.

Kan du importera Google Takeout och telefonbackuper till ett enda fotobibliotek?
Ett villkorat beslut för en hemmaserver för kombinerad fotoimport, med kontrollerade tester, resultattolkning, återställning och fokuserade vanliga frågor.

Kan Immich använda ett externt bibliotek utan att ta över ägandet av filerna?
Ett villkorat beslut för hemservern om ägarskap av externa bibliotek i Immich, med kontrollerade tester, resultattolkning, återställning och fokuserade vanliga frågor.

