Arbetsflöde för återställning av krypterade datauppsättningar: nycklar, monteringar, ögonblicksbilder och återställningstester

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Det säkra tillvägagångssättet är att behandla ett återställningsarbetsflöde som skyddar nyckelmaterial, importerar säkert, laddar rätt krypteringsrot och bevisar en separat återställning som en serie observerbara kontrollpunkter, inte som ett enda kommando.

I en krypterad ZFS-datamängd på en hem-NAS är den praktiska risken att en krypterad datamängd inte monteras eller att dess ögonblicksbilder ännu inte kan litas på som återställningsbara data. Dokumentera den aktuella identiteten och återställningspunkten, börja med den minst ingripande särskiljande kontrollen, tolka godkända och underkända resultat innan du ändrar en annan variabel och stoppa när lagringen blir instabil eller den enda återställningsbara kopian skulle exponeras. Arbetsflödet nedan är inte avslutat förrän den ursprungliga arbetsbelastningen fungerar eller bevisläget når en eskaleringsgräns.

Skydda nycklar och dokumentera feltillståndet

Stoppa automatiska importer, replikeringar, scrubbar och programskrivningar tills felet har förståtts. Dokumentera poolen, datamängdshierarkin, krypteringsroten, nyckelformatet och platsen, den senast kända monteringspunkten, det exakta felet och om nyckeln någon gång har testats på en annan återställningsvärd.

Inbyggd ZFS-kryptering skiljer nyckelladdning från montering av datamängder. ZFS-krypteringsrötter och nyckelbeteende beskriver krypteringsrötter och ärvda nycklar, vilket är anledningen till att en giltig nyckel som tillhandahålls till fel underordnad datamängd, eller antagandet att varje krypterad datamängd har en oberoende nyckel, kan leda till missvisande återställningsförsök.

Skapa skyddade kopior av nyckelfiler och återställningsanteckningar utan att skriva ut hemligheter i terminalhistorik eller supportloggar. Stoppa omedelbart om det inte finns någon verifierad nyckel eller säkerhetskopia, om poolens enheter är instabila eller om ett kommando föreslår destruktiv reparation.

Importera poolen utan att exponera produktionssökvägar

Bekräfta enhetsidentiteten på återställningsvärden och importera poolen med en alternativ rot eller utan att montera datamängder över aktiva sökvägar. Kontrollera poolstatus och datamängdsegenskaper innan du laddar nycklar. En lyckad poolimport bevisar endast att poolmetadata kan läsas, inte att krypterat innehåll kan dekrypteras.

Kontrollera rekursivt encryptionroot, keystatus, keylocation, canmount och mountpoint. Ladda nyckeln endast för den avsedda krypteringsroten och verifiera sedan att dess status ändras till tillgänglig innan du försöker montera kontrollerat under en isolerad sökväg.

Om nyckelladdningen misslyckas ska du skilja mellan fel nyckelmaterial, otillgänglig nyckelplats och skadade krypterade metadata å ena sidan och en vanlig konflikt med monteringspunkten å andra sidan. Bevara det exakta felet och försök igen först efter att ha ändrat en känd orsak; upprepade gissningar kan hindra operatörer från att få tillförlitliga bevis.

Inspektera ögonblicksbilder utan att ändra källan

Lista ögonblicksbilder och bekräfta att den förväntade återställningspunkten finns. Om källpoolen är tillräckligt frisk ska du klona den valda ögonblicksbilden eller replikera den till separat lagring i stället för att montera produktionsdatamängden med läs- och skrivåtkomst. Håll den ursprungliga ögonblicksbilden oföränderlig under undersökningen.

Rå krypterad replikering kan bevara chiffertext och krypteringsegenskaper, men den mottagande sidan behöver fortfarande motsvarande nyckelhierarki. En oberoende rå krypterad ZFS-replikering illustrerar skillnaden mellan rå krypterad sändning och en vanlig dataström, så välj medvetet i stället för att anta att varje mottagen datamängd låses upp på samma sätt.

Använd det närliggande ZimaSpace-arbetsflödet för att återställa en ögonblicksbild till ett mindre filsystem när målets kapacitet skiljer sig från källans. Här är kontrollpunkten enklare: den valda ögonblicksbilden måste kunna adresseras, nyckeln måste kunna laddas och testkopian får inte skriva över en befintlig monteringspunkt.

-15% OFF
Single board computer zimaboard2

Återställ till ett isolerat mål och bevisa läsbarheten

Återställ eller klona den valda punkten till en separat datamängd med en tillfällig monteringspunkt. Jämför representativa filhashar, ACL:er, utökade attribut, ägare, glesa filer och programdata. För en databas ska du återställa dess ursprungliga säkerhetskopia eller starta en kopierad instans på isolerade portar i stället för att öppna produktionsfiler på plats.

Starta om eller exportera och importera återställningsmiljön på nytt, ladda nyckeln igen från den dokumenterade platsen och upprepa monteringen. Detta bevisar att framgången inte berodde på en cachad nyckel, ett tillfälligt skal- eller kommandotillstånd eller en oavsiktlig montering som ärvts från produktionen.

Återställningen är klar först när en annan operatör kan följa nyckelproceduren, montera den avsedda datamängden och återställa verifierade data utan den ursprungliga värden. Eskalera när nycklar saknas, dekrypteringen misslyckas på alla skyddade kopior eller enhetsfel uppstår; ingen filsystemsreparation kan återskapa saknade krypteringsnycklar.

Support och tips

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.