Varför stannar en Restic-säkerhetskopiering när en annan värd börjar rensa?
Säkerhetskopieringen stannar vanligtvis eftersom prune behöver exklusiv kontroll över det delade arkivet, vilket innebär att den andra värden inte kan fortsätta med samma arkivtillstånd just då.
I en hemkonfiguration med flera värdar är tidpunkten den bästa första indikatorn: säkerhetskopieringen fortskrider normalt, en annan maskin startar prune och säkerhetskopieringen väntar sedan eller rapporterar ett lås. Bekräfta låsets ägare och den aktiva underhållsloggen innan du gör något. Låt prune slutföras eller stoppa den på ett kontrollerat sätt från den värd som äger processen. Ta aldrig bort låset från den väntande säkerhetskopieringsklienten.
Bekräfta att prune är den exakta utlösaren
Spara loggen från den väntande säkerhetskopieringen och underhållsloggen från värden som kör prune, inklusive tidsstämplar. Lista arkivlås och matcha värd, process och exklusivt tillstånd mot prune-jobbet. Orsaken stöds när säkerhetskopieringens framsteg stoppas efter att prune har tagit arkivet i anspråk och återupptas när låset släpps.
Operatörer som använder ett arkiv från flera värdar rapporterar låsstridigheter under prune eftersom underhållsåtgärden konkurrerar med i övrigt oberoende scheman för säkerhetskopiering.
Om säkerhetskopieringen redan var långsam, om prune-värden aldrig fick något lås eller om båda loggarna stannar vid ett lagringsfel ska du inte tvinga fram denna diagnos. Kontrollera backendens tillgänglighet, latens och själva säkerhetskopieringsprocessen. Förklaringen med prune-lås gäller endast när utlösaren, låsets ägare och tidpunkten för frisläppandet stämmer överens.
Se det exklusiva låset som en säkerhetsgräns
Prune ändrar lagringen i arkivet och behöver därför en konsekvent vy medan processen pågår. Den väntande säkerhetskopieringen har inte nödvändigtvis hängt sig i vanlig processbemärkelse; den kan respektera underhållslåset. Den första frågan är om prune gör framsteg, inte hur säkerhetskopieringen ska få ignorera låset.
En design med delat arkiv behöver en enda underhållsansvarig eftersom underhåll som omfattar hela arkivet påverkar varje klient, även när källdata tillhör olika värdar.
Om prune-loggarna går framåt och I/O mot arkivet fortsätter ska du låta låset ligga kvar och låta jobbet slutföras. Om jobbet verkligen har fastnat ska du stoppa det på ett kontrollerat sätt från värden som äger processen och vänta på en ren avslutning. Att ta bort låset från en annan klient medan prune fortfarande skriver omvandlar en kontrollerad väntan till en osäker överlappning.
Återställ den väntande säkerhetskopieringen utan att kringgå låsningen
Den minst ingripande lösningen är att vänta tills prune har slutförts. Om säkerhetskopieringen har en begränsad policy för nya försök ska du låta den försöka igen när det exklusiva låset har försvunnit. När prune måste stoppas använder du tjänstehanteraren eller processövervakaren på den värd som äger processen, väntar på att den avslutas och bekräftar att låslistan ändras innan du startar om säkerhetskopieringen.
Bevarandet kan avgränsas per värd, men fysisk frigöring av lagringsutrymme är fortfarande arbete på arkivet. En värdavgränsad bevarandepolicy förhindrar att fel ögonblicksbilder väljs, men gör inte samtidig prune säker för orelaterade säkerhetskopieringsklienter.
Försök igen med den väntande säkerhetskopieringen med vanlig låsning. Om den slutförs stämmer åtgärden med den bekräftade orsaken. Om en annan prune startar omedelbart ska du inaktivera det dubbla underhållsschemat. Om säkerhetskopieringen fortfarande stannar utan ett exklusivt lås ska du sluta öka antalet försök och återgå till diagnostik av backend, nätverk, källskanning eller process.
Testa det ursprungliga överlappet igen och definiera gränsen
Använd ett kontrollerat tidsfönster med fullständiga loggar. Starta en vanlig säkerhetskopiering och anropa sedan den planerade underhållsstyrningen. Bekräfta att den inte skapar en osäker överlappning. Upprepa i den avsedda ordningen med prune först och kontrollera att säkerhetskopieringen väntar eller avslutas enligt den konfigurerade policyn och sedan lyckas när låset släpps.
Om en avbruten prune lämnar arkivet i ett annat driftläge ska du följa diagnosen för avbruten prune i stället för att behandla varje senare fel som vanlig låsstridighet.
Återställningen är lyckad när den ursprungliga överlappningen hanteras förutsägbart, säkerhetskopieringen slutförs senare, prune avslutas korrekt och en exempelögonblicksbild fortfarande kan återställas. Eskalera om låset aldrig uppdateras eller släpps, om flera värdar fortsätter att starta underhåll eller om en arkivkontroll rapporterar skador. Dessa resultat går utöver orsaken med en enda aktiv prune.
Rekommenderade produkter
Support och tips
Mer att läsa
Så schemalägger du Restic-jobb för säkerhetskopiering, borttagning och rensning utan låskonflikter
Ett komplett Restic-schema för flera värdar som separerar frekventa säkerhetskopieringar, avgränsad lagringstid, fysisk rensning, kontroller, omförsök och validering av återställningar.
Så förhindrar du att Restic-rensningsjobb blockerar schemalagda säkerhetskopieringar
En förebyggande plan för delade Restic-arkiv som separerar säkerhetskopieringsfönster från rensning och behåller låsning, nya försök och aviseringar intakta.
Så här rensar du ett inaktuellt Restic-lås utan att avbryta en aktiv säkerhetskopiering
Ett så lite ingripande Restic-upplåsningsarbetsflöde som möjligt, som skyddar aktiva säkerhetskopieringar, endast tar bort inaktuellt tillstånd och bekräftar återställningen enligt det normala schemat.
