Waarom kan back-upversleuteling mislukken tijdens het herstellen van een thuis-NAS?

Versleuteling van back-ups kan mislukken tijdens het terugzetten van een thuis-NAS wanneer het archief intact blijft, maar de sleutel, metadata, keten, indeling of ontsleutelingsomgeving niet.

Een versleutelde back-up is geen zichzelf verklarend bestand. Voor herstel kunnen een repositorysleutel, een uit een wachtwoord afgeleide omwikkelsleutel, salt- en KDF-parameters, een catalogus, snapshotmetadata, incrementele bovenliggende back-ups, een applicatieversie en rechten om geheimen uit een ander systeem op te halen nodig zijn. Normale back-ups kunnen er gezond uitzien omdat de oorspronkelijke NAS elke afhankelijkheid lokaal in de cache heeft. Bij een schone hersteltest wordt zichtbaar wat nooit is geëxporteerd of gedocumenteerd. In de onderstaande secties wordt elke afhankelijkheid gevolgd, van herkenning van de versleutelde gegevens tot een geverifieerd hersteld bestand.

Versleutelde gegevens alleen vormen geen herstelbare back-up

De back-upbestemming kan terabytes aan intacte versleutelde blokken bevatten, maar het kleine sleutel- of metadataobject missen dat nodig is om ze te interpreteren. Duurzame opslag bewaart wat is gekopieerd, inclusief een onvolledige herstelset.

De noodherstelpakket voor back-ups van Home Assistant bestaat omdat herstelinformatie zowel de versleutelingssleutel als metadata over de back-up bevat. Datzelfde principe geldt voor thuis-NAS-tools, ook wanneer hun sleutelindeling verschilt.

Documenteer de minimale herstelbundel onafhankelijk van de actieve server: de locatie van de repository, de tool en versie, de bron van de sleutel of het wachtwoord, de accountidentiteit, de locatie van de catalogus en de opdracht of interface waarmee het herstel wordt gestart.

Een correct wachtwoord kan nog steeds de oorspronkelijke repositorysleutel nodig hebben

Sommige back-upsystemen leiden een sleutel rechtstreeks af van een wachtwoord, terwijl andere het wachtwoord gebruiken om een willekeurig gegenereerde repositorysleutel te ontgrendelen. Als die omwikkelde sleutel verloren gaat, kan het wachtwoord alleen onvoldoende zijn.

Borg documenteert dat een versleutelde repository ontoegankelijk blijft zonder de repositorysleutel en de bijbehorende beschermende wachtzin. Modi met een sleutelbestand en een repositorysleutel plaatsen die afhankelijkheid op verschillende locaties, dus noodherstel moet overeenkomen met de daadwerkelijk gebruikte modus.

Een onthouden wachtzin kan ook onjuist zijn door spaties, tekencodering, de toetsenbordindeling of een niet-gedocumenteerde wijziging. Test de exact opgeslagen herstelkopie in plaats van op uw geheugen te vertrouwen.

Bewaar de enige geëxporteerde sleutel niet in de back-uprepository die ermee wordt ontgrendeld. Door beschadiging, verwijdering, verlies van een account of een storing bij de provider kunnen beide onderdelen tegelijk verloren gaan.

Sleutelbestanden bevatten parameters die nodig zijn om ontsleuteling opnieuw uit te voeren

Versleutelde repositories slaan vaak salts, nonces, algoritme-identificaties, KDF-instellingen, authenticatietags en omwikkelde hoofdsleutels op naast de versleutelde gegevens. Deze velden zijn niet uitwisselbaar tussen repositories.

Het ontwerp van restic beschrijft een structuur van sleutelbestanden waarin de uit het wachtwoord afgeleide sleutel het materiaal van de hoofdsleutel van de repository authenticeert en ontsleutelt. Een beschadigd of niet-overeenkomend sleutelbestand kan daardoor een authenticatiefout veroorzaken, zelfs wanneer de datapakketten nog aanwezig zijn.

Alleen grote dataobjecten kopiëren en verborgen metadata, repositoryconfiguratie of kleine sleutel­mappen uitsluiten, kan een back-up opleveren die omvangrijk lijkt maar niet kan worden geopend.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Incrementele herstelpunten zijn afhankelijk van een complete keten

Een incrementeel archief registreert wijzigingen ten opzichte van een eerdere volledige of incrementele toestand. Het ontsleutelen van het nieuwste bestand reconstrueert de gegevens niet wanneer een vereiste bovenliggende back-up ontbreekt of catalogusrelaties beschadigd zijn.

Veeam beschrijft een back-upketen als een volledige back-up plus afhankelijke incrementele bestanden en metadata. Thuis-NAS-back-upapplicaties gebruiken andere benamingen, maar het herstelprincipe is hetzelfde: alle vereiste afhankelijkheden van herstelpunten moeten beschikbaar en consistent blijven.

Opschoningsregels voor bewaartermijnen, onderbroken replicatie, handmatige bestandsverplaatsingen en levenscyclusregels voor objectopslag kunnen een klein onderdeel van de keten verwijderen zonder het zichtbare nieuwste herstelpunt te verwijderen.

Voer repositorycontroles uit nadat u back-ups hebt gekopieerd of naar een andere opslaglaag hebt verplaatst, niet alleen nadat u ze op de oorspronkelijke bestemming hebt gemaakt.

Wijzigingen in software en platform kunnen het ontsleutelingspad verbreken

Een nieuwe NAS kan een andere CPU-architectuur, applicatierelease, containerimage, landinstelling, referentieprovider of integratie met een sleutelopslag gebruiken. De versleutelde indeling kan stabiel blijven, terwijl de omliggende herstelworkflow verandert.

Veritas waarschuwt dat versleutelde media niet kunnen worden hersteld zonder de vereiste wachtzinnen voor versleuteling. Compatibiliteitstests moeten ook controleren of de vervangende omgeving de repository herkent, de juiste plug-in laadt en de versie van het archief ondersteunt.

Bewaar een kopie van de herstelsoftware of containerdefinitie bij de hersteldocumentatie wanneer de indeling afhankelijk is van een specifieke tool. Exporteer de configuratie afzonderlijk van de applicatiegegevens.

Alleen herstel in een schone omgeving biedt end-to-end bewijs

Test vanaf een machine of tijdelijke omgeving die geen caches van de oorspronkelijke NAS, gekoppelde geheimen of opgeslagen referenties bevat. Haal de gedocumenteerde sleutel op, open een oud en een recent herstelpunt en controleer representatieve bestanden.

De workflow voor hersteltests van ZimaSpace maakt onderscheid tussen het bestaan van back-upgegevens en bewijs dat het huishouden deze kan herstellen. Noteer het tijdstip, de vereiste referenties, ontbrekende afhankelijkheden en eventuele handmatige stappen die tijdens de test aan het licht komen.

Controleer meer dan alleen de ontsleuteling. Bevestig bestandsnamen, rechten, checksums, applicatiedatabases en de mogelijkheid om de herstelde gegevens op vervangende hardware te gebruiken.

Een back-up is pas geslaagd wanneer een gedocumenteerde beheerder bruikbare gegevens kan herstellen nadat de oorspronkelijke server en de lokaal opgeslagen geheimen niet meer beschikbaar zijn.

Veelgestelde vragen

Kan support een verloren versleutelingssleutel herstellen?

Meestal niet wanneer het systeem is ontworpen voor sterke versleuteling die door de client wordt beheerd. Support kan software of repositorymetadata repareren, maar kan geen onbekende cryptografische sleutel uit versleutelde gegevens afleiden.

Moet de versleutelingssleutel bij de back-up worden opgeslagen?

Een versleutelde kopie van de sleutel kan bij sommige repositories worden opgeslagen, maar een onafhankelijk geëxporteerde herstelkopie beschermt tegen beschadiging of verwijdering van de repository. De wachtzin en sleutel mogen niet aan alle dezelfde storingsrisico’s worden blootgesteld.

Bewijst een geslaagde repositorycontrole dat herstel zal werken?

Nee. De controle kan opgeslagen blokken en indexen verifiëren zonder het ophalen van de sleutel, vervangende hardware, referenties, rechten, applicatiecompatibiliteit of bruikbaarheid van herstelde bestanden te testen.