Hoe u kunt bepalen of een back-upfout afkomstig is van de repository of van bronbestanden

Test repositorylezingen onafhankelijk vanaf een kleine stabiele bron en test daarna verdachte bronpaden naar een nieuwe tijdelijke repository.

De beslissing is belangrijk wanneer een back-up stopt met lees-, checksum-, toestemmings-, pack- of indexfouten. De twee concurrerende toestanden zijn schade aan de repository of bestemming en lees-, toestemmings- of wijzigingsfouten in bronbestanden. Begin met een opgeslagen configuratie en tijdelijke gegevens, observeer één vertakking tegelijk en stop als de test het risico op gegevensverlies, toestemmingsproblemen of verminderde beschikbaarheid vergroot.

Maak onderscheid tussen schade aan repository of bestemming en lees-, toestemmings- of wijzigingsfouten in bronbestanden

Leg de omgeving vast voordat je iets wijzigt: software- en firmwareversies, apparaatidentiteiten, koppel- of netwerkpad, vrije ruimte, toestemmingen en het waarneembare symptoom. De nulmeting moet voldoende details behouden om te reproduceren dat een back-up stopt met lees-, checksum-, toestemmings-, pack- of indexfouten.

De eerste mogelijkheid is schade aan de repository of bestemming. De tweede is een lees-, toestemmings- of wijzigingsfout in bronbestanden. De huidige Restic-probleemoplossingsreeks definieert de mechanisme- of opdrachtgrens die in de test wordt gebruikt; deze vervangt niet de observatie van deze specifieke homeserver.

Schrijf de acceptatievoorwaarde en stopvoorwaarde op voordat je de onderscheidende test uitvoert. Een geslaagde test moet het bewijs veranderen dat door één vertakking wordt voorspeld, terwijl niet-gerelateerde services ongewijzigd blijven; bij een mislukte test moet het systeem worden teruggebracht naar de opgeslagen toestand, in plaats van een keten van speculatieve oplossingen te starten.

Voer één gecontroleerde onderscheidende test uit

Gebruik deze onderscheidende test: voer een repositorycontrole en een hersteltest uit, maak daarna een back-up van een vaste leesbare testset en controleer afzonderlijk de bronfouten. Houd werklast, client, pad, bestandenset en timing constant, zodat het resultaat aan de gewijzigde variabele kan worden toegeschreven.

Gebruik de onafhankelijke Restic-werkstroom om het veld te selecteren dat de vertakkingen daadwerkelijk van elkaar kan onderscheiden, en leg de tijdstempel, afsluitstatus, fouttekst, apparaat- of snapshotidentiteit, latentie, overgedragen bytes, toestemmingen en herstelstatus vast. Een geslaagde afsluiting van de opdracht is niet voldoende wanneer identiteit, duurzaamheid of applicatiestatus de te testen bewering vormt.

Herhaal de test één keer na een herstart, nieuwe verbinding, nieuwe koppeling of lege cache wanneer die gebeurtenis deel uitmaakt van de oorspronkelijke toestand. Als de eerste uitvoering destructief is of de omgeving niet kan worden hersteld, stop dan en reproduceer het probleem op een tijdelijke kopie.

restic check
restic restore latest --include /canary --target /tmp/restore-test

Interpreteer welke vertakking door het bewijs wordt ondersteund

GESLAAGD: repositorycontroles of herstelbewerkingen mislukken voor meerdere bronnen, of alleen specifieke bronpaden mislukken terwijl de repository gezond blijft. Noteer de exacte versie, identiteit en werklast die slaagden, zodat de conclusie voorwaardelijk blijft en geen algemene bewering wordt.

MISLUKT: netwerk- en geheugenfouten beïnvloeden beide tests, dus reproduceer het probleem lokaal voordat je verklaart dat een van beide zijden beschadigd is. Een mislukte test bewijst niet automatisch de tegenovergestelde vertakking wanneer netwerk, geheugen, toestemmingen of bronconsistentie beide kunnen beïnvloeden; isoleer die gedeelde afhankelijkheden voordat je escaleert.

UITZONDERLIJK OF AMBIGU RESULTAAT: bevries destructief onderhoud, kopieer de logs en bescherm de laatste goede toestand van de repository. Bewaar de logs en voer geen herstel-, prune-, vernietigings-, herpartitionerings- of recursieve eigendomsopdrachten uit totdat er een herstelbare kopie bestaat.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Pas de bijbehorende actie toe en reproduceer de oorspronkelijke fout

Pas de actie toe die bij de waargenomen vertakking hoort en herhaal daarna de oorspronkelijke toestand, niet een vereenvoudigd alternatief. De beslissing is alleen geldig wanneer repositorycontroles of herstelbewerkingen voor meerdere bronnen mislukken, of wanneer alleen specifieke bronpaden mislukken terwijl de repository gedurende twee cycli of de relevante herstart-, slaap-, onderbrekings- of belastings overgang gezond blijft.

Gebruik de Restic-packgrootte om de dichtstbijzijnde afhankelijke werkstroom te controleren, maar laat de oorspronkelijke trigger ongewijzigd. Niet-gerelateerde datasets, shares, containers, gebruikers en herstelpunten moeten hun eerdere toegang en timing behouden.

De stopgrens is expliciet: als netwerk- en geheugenfouten beide tests beïnvloeden, reproduceer het probleem dan lokaal voordat je verklaart dat een van beide zijden beschadigd is; keer terug naar de laatst geverifieerde configuratie, bewaar het bewijs en escaleer alleen naar een diepere platform- of hardwaretest wanneer de vertakking reproduceerbaar is.

Nadat het beoogde resultaat is bereikt, vergelijk je dit met de verificatiefrequentie, zodat de oplossing het risico niet naar een naburige service verplaatst. Een geslaagde doeltest met een nieuwe back-up-, identiteits-, time-out- of beschikbaarheidsfout is nog steeds een mislukte wijziging.

Veelgestelde vragen

Bij het isoleren van back-upfouten gaan de resterende zoekopdrachten meestal over de vraag of een geslaagde repositorycontrole de dekking van de bron kan bewijzen, of de repository onmiddellijk moet worden hersteld en welke bronfouten gemakkelijk worden gemist. De antwoorden hieronder houden die randgevallen gescheiden van de primaire beslissing.

De acceptatiegrens verandert niet: repositorycontroles of herstelbewerkingen mislukken voor meerdere bronnen, of alleen specifieke bronpaden mislukken terwijl de repository gezond blijft. Als een vervolgtoestand het bestandssysteem, de identiteit, het netwerkpad of de applicatieversie wijzigt, herhaal dan alleen de onderscheidende test die door die wijziging wordt beïnvloed.

Stop met het uitbreiden van het experiment wanneer netwerk- en geheugenfouten beide tests beïnvloeden; reproduceer het probleem dan lokaal voordat je verklaart dat een van beide zijden beschadigd is. Bevries op dat moment destructief onderhoud, kopieer de logs en bescherm de laatste goede toestand van de repository; bewaar het bewijs voordat je escaleert naar de verantwoordelijke voor platform, opslag of hardware.

Kan een geslaagde repositorycontrole de dekking van de bron bewijzen?

Nein. Dit bewijst eigenschappen van de repository, niet dat elk bedoeld bronbestand leesbaar was of is opgenomen.

Moet de repository onmiddellijk worden hersteld?

Niet voordat je waar praktisch een veiligheidskopie hebt gemaakt en de foutklasse hebt bevestigd.

Welke bronfouten worden gemakkelijk gemist?

Toestemmingsweigeringen, verdwijnende bestanden, onleesbare sectoren, sparse bestanden en problemen met applicatieconsistentie kunnen in samenvattingen verborgen blijven.

De diagnose is voltooid wanneer dezelfde werklast het bewijs de richting van schade aan de repository of bestemming, of van lees-, toestemmings- of wijzigingsfouten in bronbestanden laat volgen, en de bijbehorende actie het oorspronkelijke symptoom verwijdert zonder een tweede te veroorzaken. Als geen van beide vertakkingen reproduceerbaar blijft, bewaar dan de logs en opgeslagen toestand intact; onzekerheid is een reden om te escaleren, niet om nog meer oplossingen op elkaar te stapelen.