Restic-repository vergrendeld na een crash: oorzaken, controles en oplossingen

Een Restic-repository kan vergrendeld blijven omdat er nog een ander proces actief is, een crash verouderde status heeft achtergelaten, de backend updates vertraagt of onderhoud nog steeds een exclusieve vergrendeling vasthoudt.

Op een thuisserver met meerdere hosts is het gevaarlijk om aan te nemen dat de laatst zichtbare crash de enige vergrendeling heeft veroorzaakt. Er kan elders nog een prune-taak actief zijn, een container kan met hetzelfde schema opnieuw zijn gestart of objectopslag toont de nieuwste status mogelijk niet direct. Begin met het stilzetten van nieuwe schema's en lees de identiteit van de vergrendeling; verwijder een vergrendeling pas nadat de host, het proces, het tijdstip en de repositoryactiviteit allemaal wijzen op een beëindigde bewerking.

Lees de identiteit van de vergrendeling voordat je handelt

Pauzeer nieuwe schema's voor back-ups, forget-, check- en prune-bewerkingen op elke machine die toegang heeft tot de repository. Bekijk de vergrendelingen en noteer de host, proces-ID, gebruiker, aanmaaktijd, vernieuwingstijd en de rol als exclusieve of niet-exclusieve vergrendeling. Controleer daarna het overeenkomende proces en de servicelogboeken op de genoemde host, in plaats van uitsluitend op basis van de ouderdom te gokken.

Verouderde vergrendelingen ontstaan vaak na een onderbroken Restic-proces, maar een onderbroken pijplijn is slechts één mogelijke oorzaak. Een proces dat een niet-netjes afgehandeld signaal ontvangt, kan status achterlaten die lijkt op een externe taak die nog actief is.

Als de PID actief is en de logboeken vooruitgaan, wacht je of stop je de taak via de servicemanager; ontgrendel de repository niet terwijl het proces actief is. Als het proces ontbreekt en de host dezelfde taak niet opnieuw heeft gestart, wordt de vergrendeling een kandidaat voor een verouderde vergrendeling. Als de host onbereikbaar is of de backendweergave inconsistent is, blijft de status niet-geverifieerd en is destructieve actie niet gerechtvaardigd.

Onderscheid de vier kenmerken van vergrendelingen

Een actieve schrijver heeft een overeenkomend proces, actuele logactiviteit en een vergrendeling die wordt vernieuwd. Een niet-netjes afgesloten proces heeft geen actief proces en een vaste vergrendelingstijd nadat de host of container is gestopt. Backendvertraging treedt op wanneer clients het niet eens zijn over de lijst met vergrendelingen of wanneer tijdstempels achterlopen op bekende repositoryactiviteit. Onvoltooid onderhoud herken je aan een exclusieve vergrendeling en een check- of prunelog die nog verandert.

Een brede volgorde voor probleemoplossing met Restic houdt repositoryvergrendelingen, prune-fouten en mogelijke beschadiging als afzonderlijke scenario's bij elkaar, zodat een oplossing voor een verouderde vergrendeling niet wordt toegepast op een opslagprobleem.

Test één kenmerk tegelijk. Bevestig eerst of het proces actief is, vergelijk daarna tijdstempels en logboeken, controleer vervolgens de bereikbaarheid van de backend en de klok en inspecteer ten slotte het onderhoud. Als twee kenmerken mogelijk blijven, behoud je de vergrendeling en onderzoek je het veiligere scenario; ontgrendelen is geen diagnostische test, omdat je daarmee de beveiliging verandert die je probeert te begrijpen.

Verwijder alleen een aantoonbaar verouderde vergrendeling

Controleer vóór het ontgrendelen nogmaals elke client, automatiseringscontroller, containerhost en service aan de repositorykant. Sla de huidige lijst met vergrendelingen en recente logboeken op. Gebruik de normale opdracht voor het verwijderen van verouderde vergrendelingen, niet een optie voor alles verwijderen of zonder vergrendeling werken, omdat het standaardpad bedoeld is om actieve vergrendelingen te behouden.

Een fout door een verouderde vergrendeling uit de praktijk kan een verder goed werkend back-upschema stoppen, maar de ouderdom van één geval bepaalt geen universele veilige drempel voor verwijdering.

Als de standaardopdracht de verouderde registratie verwijdert en er niet onmiddellijk een nieuwe vergrendeling verschijnt, ga je verder met een alleen-lezenlijst van de repository. Als de opdracht weigert omdat de vergrendeling actief is, stop je en zoek je de eigenaar. Als er direct een nieuwe vergrendeling verschijnt, is er nog steeds een planner of opnieuw gestarte container actief; schakel die bron uit voordat je een nieuwe herstelpoging doet.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Test de oorspronkelijke bewerking opnieuw en let op herhaling

Voer dezelfde bewerking uit die mislukte en leg de voortgang en afsluitstatus vast. Observeer hoe de vergrendeling verschijnt, wordt vernieuwd zolang de taak actief is en verdwijnt na een nette afsluiting. Laat daarna één normale geplande cyclus uitvoeren. Hiermee boots je de oorspronkelijke aanleiding na en bewijs je meer dan met alleen een geslaagde repositorylijst.

Als de repository alleen-lezen wordt of onderhoud mislukt nadat de vergrendeling is verwijderd, volg dan het afzonderlijke herstelpad voor een onderbroken prune-bewerking in plaats van herhaaldelijk te ontgrendelen.

Het herstel is geslaagd wanneer twee cycli met de oorspronkelijke belasting zijn voltooid, elke vergrendeling tijdens de actieve fase wordt vernieuwd en bij afsluiten wordt verwijderd en een repositorycontrole of voorbeeldherstel normaal verloopt. Schakel hulp in als vergrendelingen na nette afsluitingen terugkeren, clients het niet eens zijn over de backendstatus of een controle ontbrekende of beschadigde repositoryobjecten meldt. Houd vergrendeling tijdens het volledige onderzoek ingeschakeld.