Waarom kan een integriteitscontrole van een repository slagen terwijl één bestand nog steeds niet kan worden hersteld?

Een repositorycontrole kan slagen terwijl één bestand niet kan worden hersteld, wanneer de controle metadata of steekproefsgewijze gegevens valideert in plaats van precies dat herstelpad.

Back-upverificatie is geen universele handeling. Sommige controles bevestigen de structuur van de repository, indexen, manifesten en verwezen chunks zonder elke opgeslagen byte te lezen. Andere nemen steekproeven, slaan bestanden over die nooit zijn vastgelegd of zeggen niets over de namen, machtigingen, ACL's, labels, vrije ruimte en applicatievergrendelingen van het doelbestandssysteem. Behandel het mislukte bestand als een pad van snapshotselectie via opgeslagen objecten naar het aanmaken op de bestemming.

Identificeer precies wat de geslaagde controle heeft geverifieerd

Sla de controleopdracht, opties, versie van de back-uptool, repositorybackend, snapshot-ID en het volledige logboek op. Bepaal of de controle de repositorystructuur, archiefmetadata, verwezen chunks, opgeslagen gegevens of een daadwerkelijke extractie heeft gecontroleerd.

Borg vermeldt dat de standaard archiefcontrole metadata leest, maar standaard geen bestandsgegevens tenzij gegevensverificatie expliciet wordt aangevraagd.

Een groen resultaat kan dus bewijzen dat verwijzingen intern consistent zijn, terwijl sommige payloadchunks niet zijn gelezen. Beschouw de repository pas als volledig herstelbaar nadat representatieve bestanden zijn uitgepakt.

Bepaal of de opgeslagen gegevens van het bestand daadwerkelijk zijn gelezen

Zoek het bestand op in de bedoelde snapshot en identificeer de packs, chunks of objecten die nodig zijn om het opnieuw op te bouwen. Vergelijk het mislukte herstel met het bereik van de gegevenslezing door de repositorycontrole.

Restic documenteert controles met read-data en read-data-subset, waaruit blijkt dat een routinematige structuurcontrole en een volledige lezing van de payload verschillende verificatieniveaus zijn.

Als slechts een subset is gelezen, kan het mislukte bestand afhankelijk zijn van een niet-gecontroleerd pack. Voer een ondersteunde gerichte of volledige gegevenscontrole uit voordat u reparatie probeert.

Bevestig dat het bestand in die snapshot is opgenomen

Geef het exacte relatieve pad in de geselecteerde snapshot weer. Controleer filters, uitsluitingen, waarschuwingen over onleesbare bronnen, symlinkregels, mountgrenzen en of de herstelinterface een andere versie heeft geselecteerd.

Kopia waarschuwt dat ignore-beleid overeenkomende paden weglaat, waardoor de repositoryconsistentie kan slagen terwijl het gewenste bestand nooit is vastgelegd.

Een plaatshouderpad of een item voor de bovenliggende map bewijst niet dat de payload van het bestand bestaat. Vergelijk de inventaris van de snapshot, de grootte, hash en tijdstempel met de verwachte brongegevens.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Controleer beperkingen voor bestandsnamen en paden op de bestemming

Herstel hetzelfde bestand naar een kort, leeg lokaal pad met een eenvoudige naam. Vergelijk ongeldige tekens, gereserveerde namen, conflicten door hoofdlettergebruik, afsluitende spaties, padlengte en Unicode-normalisatie.

De richtlijnen van Microsoft voor bestandsnamen documenteren beperkingen voor Windows-bestandsnamen en -paden waardoor één hersteld pad kan worden geweigerd terwijl de repository zelf gezond blijft.

Als het bestand naar een tijdelijk kort pad kan worden hersteld, is de opgeslagen inhoud beschikbaar. Corrigeer de indeling van de bestemming of de naamtoewijzing in plaats van de repository te repareren.

Controleer het herstel van ACL's, uitgebreide attributen en eigenaarschap

Herhaal het herstel met uitgeschakelde metadatabehoudopties, maar alleen naar een wegwerpdoel, en vergelijk dit met het normale metadatabewuste herstel. Noteer welk attribuut als eerste mislukt.

GNU tar documenteert afzonderlijk het herstellen van ACL's en uitgebreide attributen, wat laat zien waarom bestandsgegevens leesbaar kunnen zijn terwijl het toepassen van metadata mislukt.

Accepteer een herstel zonder metadata niet als productieve oplossing wanneer applicaties afhankelijk zijn van ACL's, eigenaarschap, sparse-bereiken of uitgebreide attributen. Gebruik dit alleen om de laag te identificeren die faalt.

Controleer beveiligingslabels en beleid op de bestemming

Controleer SELinux-labels, antivirus- of endpointbeveiliging, bescherming tegen ransomware, onveranderlijke vlaggen, machtigingen op gedeelde mappen en applicatievergrendelingen op het hersteld doel.

Red Hat documenteert het herstellen van standaardbeveiligingscontexten wanneer bestanden zonder of met onjuiste labels aankomen.

Een bestand dat wel wordt uitgepakt maar niet kan worden geopend, kan te maken hebben met beleid op de bestemming in plaats van met een repositoryprobleem. Test met dezelfde gebruiker en applicatie die het herstelde bestand nodig heeft.

Voer een geïsoleerd herstel uit voordat u reparaties uitvoert

Herstel het mislukte bestand, de metadata van de bovenliggende map en verschillende bestanden in de buurt naar een lege dataset of tijdelijke map. Sla hashes, logboeken en de repositorystatus op voordat u reparatieopdrachten uitvoert.

De ZimaSpace-gids voor checksum- en metadataverificatie verduidelijkt het verwante onderscheid tussen de integriteit van opgeslagen inhoud en bruikbaar applicatieherstel.

Het probleem is opgelost wanneer het geselecteerde bestand vanuit de bedoelde snapshot wordt hersteld, overeenkomt met de verwachte inhoud, de vereiste metadata krijgt en via het productiepad van de applicatie kan worden geopend.

Veelgestelde vragen

Bewijst een geslaagde repositorycontrole dat elk bestand kan worden hersteld?

Nee. Dat hangt ervan af of de controle alle opgeslagen gegevens heeft gelezen en of de bestemming elk pad en de bijbehorende metadata kan aanmaken.

Moet ik na één mislukte herstelpoging onmiddellijk een reparatie uitvoeren?

Nee. Test eerst een andere bestemming, bevestig dat het bestand in de snapshot bestaat en voer een ondersteunde gegevenscontrole uit. Een reparatie kan beschadigde metadata of objecten verwijderen.

Is een geslaagde testherstelactie sterker dan een verificatierapport?

Ja, voor het geteste herstelpad. Het bewijst de selectie, ontsleuteling, het lezen van de payload, het aanmaken op de bestemming en de verwerking van metadata voor die specifieke steekproef.