Restic-arkivet är låst efter en krasch: orsaker, kontroller och lösningar
Ett Restic-repository kan förbli låst eftersom en annan process fortfarande körs, en krasch har lämnat kvar gammalt tillstånd, backend-systemet har fördröjt uppdateringar eller underhåll fortfarande håller en exklusiv låsning.
På en hemserver med flera värdar är det farligt att anta att den senast synliga kraschen skapade det enda låset. Ett prune-jobb kan fortfarande köras någon annanstans, en container kan ha startats om med samma schema eller objektlagringen kanske inte visar det senaste tillståndet omedelbart. Börja med att pausa nya schemalagda jobb och läsa låsets identitet. Ta bara bort ett lås när värd, process, tid och repository-aktivitet alla visar att åtgärden har avslutats.
Läs låsets identitet innan du vidtar åtgärder
Pausa nya scheman för säkerhetskopiering, forget, check och prune på alla maskiner som kan nå repositoryt. Lista låsen och spara deras värd, process-ID, användare, skapandetid, uppdateringstid samt roll: exklusiv eller icke-exklusiv. Kontrollera sedan den matchande processen och tjänsteloggarna på den angivna värden i stället för att enbart gissa utifrån ålder.
Föråldrade lås uppstår ofta efter en avbruten Restic-process, men en avbruten pipeline är bara en möjlig orsak. En process som tar emot en osnygg signal kan lämna kvar ett tillstånd som liknar ett fjärrjobb som fortfarande körs.
Om PID:et körs och loggarna uppdateras ska du vänta eller stoppa jobbet via dess tjänstehanterare; lås inte upp under tiden. Om processen saknas och värden inte har startat om samma jobb har låset blivit en kandidat för att vara föråldrat. Om värden inte kan nås eller backend-vyn är inkonsekvent är statusen fortfarande obekräftad, och ingen destruktiv åtgärd är motiverad.
Skilj mellan de fyra låssignaturerna
En aktiv skrivande process har en matchande process, aktuell loggaktivitet och ett lås som uppdateras. En osnygg avslutning innebär att ingen process körs och att låsets tidsstämpel förblir oförändrad efter att värden eller containern stoppades. Fördröjning i backend-systemet visar sig när klienter inte är överens om låslistan eller när tidsstämplarna släpar efter känd repository-aktivitet. Oavslutat underhåll visas genom ett exklusivt lås och en check- eller prune-logg som fortfarande ändras.
En övergripande felsökningsordning för Restic håller repository-lås, prune-fel och möjlig korruption som separata grenar, så att en lösning för föråldrade lås inte tillämpas på ett lagringsfel.
Testa en signatur i taget. Bekräfta först om processen lever, jämför sedan tidsstämplar och loggar, kontrollera därefter backend-åtkomst och klockan och granska slutligen underhållet. Om två signaturer fortfarande är möjliga ska du behålla låset och undersöka den säkrare grenen. Att låsa upp är inte ett diagnostiskt test, eftersom det ändrar det skydd du försöker förstå.
Rensa bara ett bevisat föråldrat lås
Innan du låser upp ska du kontrollera alla klienter, automationskontroller, container-värdar och tjänster på repository-sidan en gång till. Spara den aktuella låslistan och de senaste loggarna. Använd det normala kommandot för att ta bort föråldrade lås, inte ett alternativ för att ta bort alla lås eller köra utan lås, eftersom standardvägen är utformad för att lämna aktiva lås orörda.
Ett verkligt fel orsakat av ett föråldrat lås kan stoppa ett annars etablerat schema för säkerhetskopiering, men åldern på ett enskilt fall definierar inte någon universellt säker gräns för borttagning.
Om standardkommandot tar bort den föråldrade posten och inget lås omedelbart återkommer kan du fortsätta med en skrivskyddad listning av repositoryt. Om kommandot vägrar eftersom låset är aktivt ska du stoppa och hitta ägaren. Om ett nytt lås visas direkt körs fortfarande en schemaläggare eller en omstartad container. Inaktivera den källan innan du försöker med ytterligare en reparation.
Testa den ursprungliga åtgärden igen och håll utkik efter att problemet återkommer
Kör samma åtgärd som misslyckades, och fånga förloppet och avslutningsstatusen. Se låset visas, uppdateras medan jobbet är aktivt och försvinner efter ett rent avslut. Låt sedan en normal schemalagd cykel köras. Detta återskapar den ursprungliga utlösaren och bevisar mer än en lyckad repository-listning.
Om repositoryt blir skrivskyddat eller underhållet misslyckas efter att låset har rensats ska du följa den separata återställningsvägen för avbruten prune i stället för att låsa upp upprepade gånger.
Återställningen är lyckad när två cykler med den ursprungliga belastningen slutförs, varje lås uppdateras medan det är aktivt och tas bort vid avslut, samt en repository-kontroll eller provåterställning fungerar normalt. Eskalera om lås återkommer efter rena avslut, om klienter inte är överens om backend-tillståndet eller om kontrollen rapporterar saknade eller skadade repository-objekt. Håll låsning aktiverad under hela undersökningen.
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.
