Varför kan säkerhetskopieringskryptering misslyckas vid återställning av en hem-NAS?

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.

Säkerhetskopieringskryptering kan fallera under en återställning till en hem-NAS när arkivet finns kvar men dess nyckel, metadata, kedja, format eller dekrypteringsmiljö inte gör det.

En krypterad säkerhetskopia är inte en självförklarande fil. Återställningen kan vara beroende av en förrådsnyckel, en lösenfrasbaserad omslagsnyckel, salt- och KDF-parametrar, en katalog, metadata för ögonblicksbilder, föregående inkrementella säkerhetskopior, applikationsversion och behörighet att hämta hemligheter från ett annat system. Vanliga säkerhetskopior kan verka felfria eftersom den ursprungliga NAS-enheten fortfarande har alla beroenden cachade lokalt. En ren återställning avslöjar vad som aldrig exporterades eller dokumenterades. Avsnitten nedan följer varje beroende från identifiering av chiffertext till en verifierad återställd fil.

Chiffertext ensam är inte en återställningsbar säkerhetskopia

Säkerhetskopieringsmålet kan innehålla terabyte av intakta krypterade block men sakna det lilla nyckel- eller metadataobjekt som krävs för att tolka dem. Lagringsbeständighet bevarar det som kopierades, inklusive en ofullständig återställningsuppsättning.

Home Assistants nödkit för säkerhetskopiering finns eftersom återställningsinformationen innehåller både krypteringsnyckeln och metadata som hör till säkerhetskopian. Samma princip gäller för verktyg för hem-NAS även när deras nyckelformat skiljer sig åt.

Dokumentera det minsta återställningspaketet separat från den aktiva servern: förrådets plats, verktyg och version, källa till nyckel eller lösenfras, kontoidentitet, katalogens plats samt kommandot eller gränssnittet som används för att starta återställningen.

Ett korrekt lösenord kan fortfarande kräva den ursprungliga förrådsnyckeln

Vissa säkerhetskopieringssystem härleder en nyckel direkt från ett lösenord, medan andra använder lösenordet för att låsa upp en slumpgenererad förrådsnyckel. Om den omslutna nyckeln förloras kan lösenordet vara otillräckligt.

Borg dokumenterar att ett krypterat förråd förblir otillgängligt utan förrådsnyckeln och den lösenfras som skyddar den. Lägena med nyckelfil och förrådsnyckel placerar detta beroende på olika platser, så katastrofåterställningen måste motsvara det läge som faktiskt användes.

En ihågkommen lösenfras kan också vara fel på grund av blanksteg, teckenkodning, tangentbordslayout eller en odokumenterad rotation. Testa den exakta lagrade återställningskopian i stället för att förlita dig på minnet.

Förvara inte den enda exporterade nyckeln i det säkerhetskopieringsförråd som den låser upp. Korruption, radering, förlorat konto eller leverantörsfel kan ta bort båda delarna samtidigt.

Nyckelfiler innehåller parametrar som behövs för att återskapa dekryptering

Krypterade förråd lagrar ofta salt, noncer, algoritmidentifierare, KDF-inställningar, autentiseringstaggar och omslutna huvudnycklar tillsammans med de krypterade data. Dessa fält kan inte bytas mellan olika förråd.

Restics design beskriver en nyckelfilstruktur där den lösenordsbaserade nyckeln autentiserar och dekrypterar förrådets huvudnyckelmaterial. En skadad eller felaktig nyckelfil kan därför leda till ett autentiseringsfel även när datapaketen fortfarande finns kvar.

Om endast stora dataobjekt kopieras medan dold metadata, förrådskonfiguration eller små nyckelkataloger utesluts kan resultatet bli en säkerhetskopia som ser omfattande ut men inte går att öppna.

-15% OFF
Single board computer zimaboard2

Inkrementella återställningspunkter är beroende av en komplett kedja

Ett inkrementellt arkiv registrerar ändringar i förhållande till ett tidigare fullständigt eller inkrementellt tillstånd. Att dekryptera den senaste filen återskapar inte data när ett nödvändigt föregående led saknas eller katalogrelationerna är skadade.

Veeam beskriver en säkerhetskopieringskedja som en fullständig säkerhetskopia plus beroende inkrementella filer och metadata. Applikationer för säkerhetskopiering till hem-NAS använder andra namn, men återställningsprincipen är densamma: alla nödvändiga beroenden för återställningspunkten måste finnas kvar och vara konsekventa.

Rensning enligt lagringspolicy, avbruten replikering, manuella filflyttar och livscykelregler för objektlagring kan ta bort en liten del av kedjan utan att den synliga senaste återställningspunkten raderas.

Kör kontroller av förrådet efter att säkerhetskopior har kopierats eller placerats i olika lagringsnivåer, inte bara efter att de skapats på den ursprungliga destinationen.

Förändringar i programvara och plattform kan bryta dekrypteringsvägen

En ny NAS kan köra en annan CPU-arkitektur, applikationsversion, containeravbildning, lokal, autentiseringsleverantör eller integration med ett nyckellager. Det krypterade formatet kan vara stabilt medan det omgivande återställningsarbetsflödet förändras.

Veritas varnar för att krypterade medier inte kan återställas utan de nödvändiga krypteringslösenfraserna. Kompatibilitetstester bör även verifiera att ersättningsmiljön känner igen förrådet, läser in rätt insticksprogram och stöder arkivets version.

Bevara en kopia av återställningsprogramvaran eller containerdefinitionen tillsammans med återställningsdokumentationen när formatet är beroende av ett specifikt verktyg. Exportera konfiguration separat från applikationsdata.

En återställning i en ren miljö är det enda beviset från början till slut

Testa från en maskin eller tillfällig miljö som inte innehåller den ursprungliga NAS-enhetens cache, monterade hemligheter eller sparade autentiseringsuppgifter. Hämta den dokumenterade nyckeln, öppna en gammal och en ny återställningspunkt och verifiera representativa filer.

ZimaSpaces arbetsflöde för återställningstestning skiljer mellan att säkerhetskopieringsdata finns och att hushållet faktiskt kan återställa den. Dokumentera tiden, nödvändiga autentiseringsuppgifter, saknade beroenden och eventuella manuella steg som upptäcktes under testet.

Verifiera mer än dekryptering. Bekräfta filnamn, behörigheter, kontrollsummor, applikationsdatabaser och möjligheten att använda den återställda datan på ersättningshårdvara.

En säkerhetskopia är godkänd först när en dokumenterad operatör kan återställa användbara data efter att den ursprungliga servern och dess lokalt cachade hemligheter blivit otillgängliga.

Vanliga frågor

Kan support återställa en förlorad krypteringsnyckel?

Vanligtvis inte när systemet är utformat för stark klientstyrd kryptering. Supporten kan reparera programvara eller metadata för förrådet, men kan inte härleda en okänd kryptografisk nyckel från chiffertext.

Bör krypteringsnyckeln lagras tillsammans med säkerhetskopian?

En krypterad kopia av nyckeln kan lagras tillsammans med vissa förråd, men en oberoende exporterad återställningskopia skyddar mot korruption eller radering av förrådet. Lösenfrasen och nyckeln bör inte dela alla felgränser.

Bevisar en lyckad kontroll av förrådet att återställningen kommer att fungera?

Nej. Den kan verifiera lagrade block och index utan att testa hämtning av nycklar, ersättningshårdvara, autentiseringsuppgifter, behörigheter, applikationskompatibilitet eller användbarheten hos de återställda filerna.

Teknik- och AI-hubb

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.