Så avgör du om ett säkerhetskopieringsfel beror på arkivet eller källfilerna

Eva Wong

IceWhale author

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.

How to Tell Whether a Backup Failure Comes From the Repository or Source Files - Zima Store Online

Testa arkivläsning oberoende från en liten stabil källa och testa sedan misstänkta källsökvägar mot ett nytt engångsarkiv.

Beslutet är viktigt när en säkerhetskopiering avbryts med läs-, checksumme-, behörighets-, pack- eller indexfel. De två konkurrerande tillstånden är skador på arkivet eller destinationen samt läs-, behörighets- eller ändringsfel i källfiler. Börja med en sparad konfiguration och engångsdata, observera en gren i taget och avbryt om testet ökar risken för dataförlust, behörighetsproblem eller otillgänglighet.

Skilj skador på arkiv eller destination från läs-, behörighets- eller ändringsfel i källfiler

Dokumentera miljön innan du ändrar något: program- och firmwareversioner, enhetsidentiteter, monterings- eller nätverkssökväg, ledigt utrymme, behörigheter och det observerbara symptomet. Baslinjen måste innehålla tillräckligt med information för att återskapa en avbruten säkerhetskopiering med läs-, checksumme-, behörighets-, pack- eller indexfel.

Den första kandidaten är skador på arkivet eller destinationen. Den andra är läs-, behörighets- eller ändringsfel i källfiler. Den aktuella felsökningssekvensen för Restic definierar mekanismen eller kommandogränsen som används i testet; den ersätter inte observationer från just denna hemserver.

Skriv ned godkännandekriteriet och stoppkriteriet innan du kör särskiljningstestet. Ett godkänt resultat måste ändra de belägg som förutsägs av den ena grenen, samtidigt som orelaterade tjänster förblir oförändrade; ett underkänt resultat måste återställa systemet till det sparade tillståndet i stället för att utlösa en kedja av spekulativa korrigeringar.

Kör ett kontrollerat särskiljningstest

Använd följande särskiljningstest: kör en arkivkontroll och en teståterställning, säkerhetskopiera sedan en fast uppsättning läsbara testfiler och granska källfelen separat. Håll arbetsbelastning, klient, sökväg, filuppsättning och tidpunkt konstanta så att resultatet kan hänföras till den ändrade variabeln.

Använd ett oberoende Restic-arbetsflöde för att välja det fält som faktiskt kan skilja grenarna åt, och samla in dess tidsstämpel, avslutningsstatus, feltext, enhets- eller ögonblicksbildsidentitet, fördröjning, överförda byte, behörigheter och återställningstillstånd. Ett felfritt kommandoavslut räcker inte när identitet, beständighet eller programtillstånd är det som testas.

Upprepa testet en gång efter en omstart, återanslutning, ominmontering eller kall cache när den händelsen ingår i det ursprungliga tillståndet. Om den första körningen är destruktiv eller miljön inte kan återställas, avbryt och återskapa problemet på en engångskopia i stället.

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

Tolka vilken gren beläggen stöder

GODKÄNT: arkivkontroller eller återställningar misslyckas för flera källor, eller så misslyckas endast specifika källsökvägar medan arkivet förblir friskt. Dokumentera exakt version, identitet och arbetsbelastning som fungerade så att slutsatsen förblir villkorad i stället för att bli ett universellt påstående.

UNDERKÄNT: nätverks- och minnesfel påverkar båda testerna, så återskapa problemet lokalt innan du fastslår att någon sida är skadad. Ett underkänt resultat bevisar inte automatiskt den motsatta grenen när nätverk, minne, behörigheter eller källans konsekvens kan påverka båda; isolera dessa gemensamma beroenden innan du eskalerar.

UNDANTAG ELLER TVETYDIGT RESULTAT: frys destruktivt underhåll, kopiera loggar och skydda det senast fungerande arkivtillståndet. Bevara loggarna och kör inte reparations-, rensnings-, förstörings-, ompartitionerings- eller rekursiva ägarskapskommandon förrän en återställningsbar kopia finns.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Tillämpa den matchade åtgärden och återskapa det ursprungliga felet

Tillämpa den åtgärd som motsvarar den observerade grenen och upprepa sedan det ursprungliga tillståndet i stället för en förenklad ersättning. Beslutet gäller endast när arkivkontroller eller återställningar misslyckas för flera källor, eller endast specifika källsökvägar misslyckas medan arkivet förblir friskt under två cykler eller genom den relevanta omstarten, viloläget, avbrottet eller belastningsövergången.

Använd Restic-packstorleken för att kontrollera det närmast beroende arbetsflödet, men lämna den ursprungliga utlösaren oförändrad. Orelaterade datauppsättningar, delningar, containrar, användare och återställningspunkter måste behålla sin tidigare åtkomst och tidsåtgång.

Stoppgränsen är tydlig: om nätverks- och minnesfel påverkar båda testerna, återskapa problemet lokalt innan du fastslår att någon sida är skadad, återgå till den senast verifierade konfigurationen, behåll beläggen och eskalera till ett djupare plattforms- eller hårdvarutest endast när grenen kan upprepas.

När målresultatet kvarstår jämför du det med verifieringsfrekvensen så att korrigeringen inte flyttar risken till en närliggande tjänst. Ett lyckat måltest med ett nytt säkerhetskopierings-, identitets-, timeout- eller tillgänglighetsfel är fortfarande en misslyckad ändring.

Vanliga frågor

Vid isolering av säkerhetskopieringsfel gäller de återstående frågorna vanligtvis om en lyckad arkivkontroll kan bevisa källtäckning, om arkivet bör repareras omedelbart och vilka källfel som är lätta att missa. Svaren nedan håller dessa specialfall åtskilda från huvudbeslutet.

Godkännandegränsen ändras inte: arkivkontroller eller återställningar misslyckas för flera källor, eller endast specifika källsökvägar misslyckas medan arkivet förblir friskt. Om ett uppföljande villkor ändrar filsystemet, identiteten, nätverkssökvägen eller programversionen, upprepar du endast det särskiljningstest som påverkas av ändringen.

Sluta bredda experimentet när nätverks- och minnesfel påverkar båda testerna, och återskapa då problemet lokalt innan du fastslår att någon sida är skadad. Frys därefter destruktivt underhåll, kopiera loggar och skydda det senast fungerande arkivtillståndet; bevara beläggen innan du eskalerar till plattforms-, lagrings- eller hårdvaruansvarig.

Kan en lyckad arkivkontroll bevisa källtäckning?

Nej. Den bevisar arkivegenskaper, inte att alla avsedda källfiler var läsbara eller inkluderades.

Bör arkivet repareras omedelbart?

Inte innan du, när det är praktiskt möjligt, har skapat en säkerhetskopia och bekräftat felklassen.

Vilka källfel är lätta att missa?

Åtkomstnekanden, filer som försvinner, oläsbara sektorer, glesa filer och problem med programkonsistens kan döljas i sammanfattningar.

Diagnosen är färdig när samma arbetsbelastning får beläggen att följa antingen skador på arkiv eller destination eller läs-, behörighets- eller ändringsfel i källfiler, och den matchade åtgärden tar bort det ursprungliga symptomet utan att skapa ett nytt. Om ingen av grenarna förblir reproducerbar ska du behålla loggarna och det sparade tillståndet intakta; osäkerhet är ett skäl att eskalera, inte att stapla fler korrigeringar.