Waarom loopt een Restic-back-up vast wanneer een andere host begint met opschonen?

De back-up loopt meestal vast omdat prune exclusieve controle over de gedeelde repository nodig heeft. Daardoor kan de tweede host op dat moment niet verdergaan met dezelfde repositorystatus.

In een thuisopstelling met meerdere hosts is de timing de beste eerste aanwijzing: de back-up verloopt normaal, een andere machine start prune en daarna wacht de back-up of meldt deze een vergrendeling. Controleer de eigenaar van de vergrendeling en het actieve onderhoudslogboek voordat je iets wijzigt. Laat prune voltooien of stop het proces netjes vanaf de host die eigenaar is; verwijder de vergrendeling nooit vanaf de wachtende back-upclient.

Bevestig dat Prune de exacte oorzaak is

Sla het wachtende back-uplogboek en het onderhoudslogboek van de host waarop prune draait op, inclusief tijdstempels. Geef de repositoryvergrendelingen weer en vergelijk de host, het proces en de exclusieve status met de prune-taak. De oorzaak wordt bevestigd wanneer de voortgang van de back-up stopt nadat prune de repository heeft vergrendeld en hervat nadat die vergrendeling is vrijgegeven.

Beheerders die vanaf meerdere hosts één repository gebruiken, melden vergrendelingsconflicten tijdens het opschonen, omdat deze onderhoudsactie concurreert met verder onafhankelijke back-upschema's.

Als de back-up al traag was, de prune-host nooit een vergrendeling verkreeg of beide logboeken stoppen bij een opslagfout, forceer deze diagnose dan niet. Controleer de beschikbaarheid en latentie van de backend en het back-upproces zelf. De verklaring met de prune-vergrendeling geldt alleen wanneer de trigger, de eigenaar van de vergrendeling en de timing van het vrijgeven overeenkomen.

Beschouw de exclusieve vergrendeling als een veiligheidsgrens

Prune wijzigt de opslag van de repository en heeft daarom tijdens de uitvoering een consistente weergave nodig. De wachtende back-up hangt niet noodzakelijkerwijs vast in de gebruikelijke betekenis van het proces; deze kan de onderhoudsvergrendeling respecteren. De eerste vraag is niet hoe je de back-up de vergrendeling kunt laten negeren, maar of prune voortgang maakt.

Een ontwerp met een gedeelde repository heeft één eigenaar voor onderhoud nodig, omdat repositorybreed onderhoud elke client beïnvloedt, zelfs wanneer de brongegevens van verschillende hosts afkomstig zijn.

Als de prune-logboeken vorderen en de I/O van de repository doorgaat, laat de vergrendeling dan staan en laat de taak voltooien. Als de taak echt vastzit, stop deze dan op een nette manier vanaf de host die eigenaar is en wacht totdat het proces correct is beëindigd. Door de vergrendeling vanaf een andere client te verwijderen terwijl prune nog schrijft, verander je een gecontroleerde wachttijd in een onveilige overlap.

Herstel de wachtende back-up zonder vergrendeling te omzeilen

De minst ingrijpende oplossing is wachten totdat prune is voltooid. Als de back-up een begrensd beleid voor nieuwe pogingen heeft, laat deze dan opnieuw proberen nadat de exclusieve vergrendeling is verdwenen. Wanneer prune moet worden gestopt, gebruik je de servicemanager of procesbeheerder op de host die eigenaar is, wacht je totdat het proces is afgesloten en controleer je of de lijst met vergrendelingen is gewijzigd voordat je de back-up opnieuw start.

Bewaarinstellingen kunnen per host worden afgebakend, maar fysieke vrijgave van opslag blijft werk op repositoryniveau. Een hostgebonden bewaarbeleid voorkomt dat de verkeerde snapshots worden geselecteerd; het maakt gelijktijdig prune uitvoeren niet veilig voor niet-gerelateerde back-upclients.

Probeer de wachtende back-up opnieuw met normale vergrendeling. Als deze voltooit, komt het herstel overeen met de bevestigde oorzaak. Als er onmiddellijk opnieuw een prune-taak start, schakel dan het dubbele onderhoudsschema uit. Als de back-up nog steeds vastloopt zonder exclusieve vergrendeling, verhoog het aantal pogingen dan niet verder en ga terug naar diagnostiek van de backend, het netwerk, het scannen van de bron of het proces.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Test de oorspronkelijke overlap opnieuw en bepaal de grenzen

Gebruik een gecontroleerd tijdvenster met volledige logboeken. Start een normale back-up, roep vervolgens de geplande onderhoudscontroller aan en controleer of deze geen onveilige overlap veroorzaakt. Herhaal dit in de beoogde volgorde met prune eerst en controleer of de back-up wacht of afsluit volgens het geconfigureerde beleid en daarna slaagt zodra de vergrendeling wordt vrijgegeven.

Als een onderbroken prune de repository in een andere operationele toestand achterlaat, volg dan de diagnose voor een onderbroken prune in plaats van elke latere fout als een normaal vergrendelingsconflict te behandelen.

Het herstel is geslaagd wanneer de oorspronkelijke overlap voorspelbaar wordt afgehandeld, de back-up later voltooit, prune netjes afsluit en een voorbeeldsnapshot herstelbaar blijft. Schakel hulp in als de vergrendeling nooit wordt bijgewerkt of vrijgegeven, meerdere hosts onderhoud blijven starten of een repositorycontrole schade meldt. Die resultaten vallen buiten de oorzaak van één actieve prune-taak.