Workflow voor herstel van versleutelde datasets: sleutels, koppelingen, snapshots en hersteltests

De veilige aanpak is om een herstelworkflow die sleutelmateriaal beschermt, veilig importeert, de juiste versleutelingsroot laadt en een afzonderlijk herstel bewijst, te behandelen als een reeks waarneembare controlepunten, niet als één enkele opdracht.

Op een versleutelde ZFS-dataset op een thuis-NAS is het praktische risico dat een versleutelde dataset niet wordt aangekoppeld of dat de snapshots nog niet kunnen worden vertrouwd als herstelbare gegevens. Leg de huidige identiteit en het herstelpunt vast, begin met de minst ingrijpende onderscheidende controle, interpreteer geslaagde en mislukte resultaten voordat je een andere variabele wijzigt, en stop wanneer de opslag instabiel wordt of wanneer alleen de nog herstelbare kopie zou worden blootgesteld. De onderstaande workflow eindigt pas nadat de oorspronkelijke workload succesvol werkt of het bewijs een escalatiegrens bereikt.

Bescherm sleutels en leg de fouttoestand vast

Stop automatische imports, replicatie, scrubs en schrijfbewerkingen van applicaties totdat de fout is begrepen. Leg de pool, dataset-hiërarchie, versleutelingsroot, sleutelindeling en locatie, het laatst bekende mountpoint, de exacte fout en vast of de sleutel ooit op een andere herstelhost is getest.

Native ZFS-versleuteling scheidt het laden van sleutels van het aankoppelen van datasets. De ZFS-versleutelingsroots en het sleutelgedrag beschrijven versleutelingsroots en overgeërfde sleutels. Daarom kan het aanleveren van een geldige sleutel aan het verkeerde onderliggende element of het aannemen dat elke versleutelde dataset een onafhankelijke sleutel heeft, misleidende herstelpogingen veroorzaken.

Maak beveiligde kopieën van sleutelbestanden en herstelnotities zonder geheimen in de terminalgeschiedenis of supportlogs af te drukken. Stop onmiddellijk als er geen geverifieerde sleutel of back-up bestaat, de poolapparaten instabiel zijn of een opdracht destructief herstel voorstelt.

Importeer de pool zonder productiepadnamen bloot te stellen

Bevestig op de herstelhost de apparaatidentiteit en importeer de pool met een alternatieve root of zonder datasets op actieve paden aan te koppelen. Controleer de poolstatus en dataset-eigenschappen voordat je sleutels laadt. Een geslaagde poolimport bewijst alleen dat de metagegevens van de pool leesbaar zijn, niet dat versleutelde inhoud kan worden ontsleuteld.

Controleer recursief encryptionroot, keystatus, keylocation, canmount en mountpoint. Laad de sleutel alleen voor de bedoelde versleutelingsroot en controleer vervolgens of de status verandert in beschikbaar voordat je gecontroleerd aankoppelt onder een geïsoleerd pad.

Als het laden van de sleutel mislukt, maak dan onderscheid tussen verkeerd sleutelmateriaal, een ontoegankelijke sleutellocatie en beschadigde versleutelde metagegevens enerzijds en een gewoon conflict met het mountpoint anderzijds. Bewaar de exacte fout en probeer het alleen opnieuw nadat je één bekende oorzaak hebt gewijzigd; herhaalde gokpogingen kunnen operators de toegang tot betrouwbaar bewijs ontnemen.

Inspecteer snapshots zonder de bron te wijzigen

Geef snapshots weer en bevestig dat het verwachte herstelpunt bestaat. Als de bronpool gezond genoeg is, kloon dan de geselecteerde snapshot of repliceer deze naar afzonderlijke opslag in plaats van de productiedataset read-write aan te koppelen. Houd de oorspronkelijke snapshot tijdens het onderzoek onveranderlijk.

Ruwe versleutelde replicatie kan ciphertext en versleutelingseigenschappen behouden, maar aan de ontvangende kant is nog steeds de bijbehorende sleutelhiërarchie nodig. Een onafhankelijke ruwe versleutelde ZFS-replicatie illustreert het verschil tussen raw encrypted send en een normale stream. Kies daarom bewust in plaats van aan te nemen dat elke ontvangen dataset op dezelfde manier wordt ontgrendeld.

Gebruik de aangrenzende ZimaSpace-workflow voor een snapshot herstellen naar een kleiner bestandssysteem wanneer de doelcapaciteit afwijkt van de bron. Hier is het controlepunt eenvoudiger: de geselecteerde snapshot moet adresseerbaar zijn, de sleutel moet kunnen worden geladen en de testkopie mag geen bestaand mountpoint overschrijven.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Herstel naar een geïsoleerd doel en bewijs de leesbaarheid

Herstel of kloon het geselecteerde punt naar een afzonderlijke dataset met een tijdelijk mountpoint. Vergelijk representatieve bestands-hashes, ACL's, uitgebreide kenmerken, eigenaren, sparse bestanden en applicatiegegevens. Herstel bij een database de native back-up of start een gekopieerde instantie op geïsoleerde poorten in plaats van productiegegevensbestanden op hun oorspronkelijke locatie te openen.

Start de herstelomgeving opnieuw op of exporteer en importeer deze opnieuw, laad de sleutel weer vanaf de gedocumenteerde locatie en herhaal het aankoppelen. Hiermee bewijs je dat het succes niet afhankelijk was van een gecachte sleutel, een eenmalige shelltoestand of een toevallig van productie overgenomen mount.

Het herstel is pas voltooid wanneer een andere operator de sleutelprocedure kan volgen, de bedoelde dataset kan aankoppelen en geverifieerde gegevens zonder de oorspronkelijke host kan herstellen. Escaleer wanneer sleutels niet beschikbaar zijn, ontsleuteling op elke beschermde kopie mislukt of apparaatfouten optreden; geen enkel bestandssysteemherstel kan ontbrekende versleutelingssleutels reconstrueren.