Så förhindrar du att Restic-rensningsjobb blockerar schemalagda säkerhetskopieringar
Förhindra krockar vid rensning genom att utse en underhållsansvarig per arkiv och ge underhållet ett tidsfönster där ingen säkerhetskopieringsklient kan starta nya jobb.
I ett delat hemserverarkiv börjar felet vanligtvis tidigare än låsfelmeddelandet: flera värdar äger underhållsscheman, en säkerhetskopiering tar längre tid än väntat och rensningen startar utan en grind för hela arkivet. Vänd på tidslinjen. Centralisera rensningen, reservera tillräckligt med tid, serialisera jobb utanför Restic och skicka aviseringar vid överhoppade eller försenade körningar. Om en krock redan har uppstått ska du stoppa nya jobb och använda den minimala återställningsvägen i stället för att försvaga låsningen.
Ge varje arkiv en enda underhållsansvarig
Sök igenom varje klient och arkivtjänst efter Restic-kommandon för underhåll. Dokumentera vem som ansvarar för forget, prune, check, unlock och aviseringar. Inaktivera dubbla scheman för rensning och behåll en enda styrenhet med de arkivuppgifter och den överblick som krävs för att se alla klienter.
Flera säkerhetskopieringar kan samordnas kring ett arkiv, men att ta bort alla lås före rensning undanröjer säkerhetsgränsen och kan skapa den osäkra överlappning som schemat var tänkt att förhindra.
Ägarskapskontrollen är godkänd när endast en värd kan starta underhåll för hela arkivet och varje säkerhetskopieringsklient vet var fel rapporteras. Om en apparat eller säkerhetskopieringsomslutning kan starta dolt underhåll ska du inaktivera dess automatiska alternativ eller inkludera det i samma styrenhet innan du fortsätter.
Reservera ett rensningsfönster som är längre än den längsta normala körningen
Använd aktuella loggar för att hitta den längsta normala säkerhetskopieringen, den längsta nyliga rensningen, klienternas väckningsfördröjningar och kön av nya försök. Placera rensningen efter den senast förväntade slutförandetiden för säkerhetskopieringen och lämna tid för rensningens egen längsta normala varaktighet. Välj inte midnatt enbart för att det ser lugnt ut på en värd.
En lagringspolicy bör också avgränsa ögonblicksbilder efter värd eller tagg så att lagring för flera värdar inte väljer fel ögonblicksbilder medan arkivet har en enda underhållsansvarig.
Om säkerhetskopieringar ofta går över den föreslagna gränsen ska du flytta rensningen i stället för att förkorta säkerhetskopieringsfönstret. Om rensningens varaktighet växer utöver det tillgängliga mellanrummet kan du minska hur ofta fysisk frigöring körs, undersöka backendens genomströmning eller använda ett större fönster. Förebyggandet misslyckas när schemat förutsätter att varje jobb slutförs på sin genomsnittliga tid.
Upprätthåll ömsesidig uteslutning och en synlig policy för nya försök
Använd en extern serialiseringsmetod som alla lokala jobb följer: ordning mellan systemd-enheter, en gemensam låsomslutning eller en kö som styrs av underhållsvärden. Omslutningen ska avvisa eller fördröja det senare jobbet, bevara Restics egen låsning och skriva en tydlig status som övervakningen kan avisera om.
Ett Restic-schema baserat på systemd kan separera återkommande tjänster för säkerhetskopiering och rensning så att ordning, avslutningsstatus och loggar förblir synliga.
Ange ett begränsat intervall för nya försök och en maximal fördröjning. En säkerhetskopiering som blockeras av underhåll ska försöka igen efter fönstret, inte försvinna tills nästa dag; en rensning som blockeras av en sen säkerhetskopiering ska avisera och flyttas till nästa godkända fönster. Gör aldrig automatisk tvingad upplåsning till åtgärd vid nya försök.
Testa förebyggandepolicyn och behåll en minimal återställning
Testa båda ordningsföljderna på ett tillfälligt arkiv eller en exempeldatauppsättning: starta säkerhetskopieringen först och begär sedan rensning, och starta därefter rensningen först och begär säkerhetskopiering. I varje fall ska ett jobb vänta eller avslutas synligt, styrenheten ska försöka igen enligt den konfigurerade policyn och inget lås får tas bort under en aktiv process.
Efter driftsättningen ska du granska loggarna för nästa normala säkerhetskopiering, forget och prune. Om arkivet blir skrivskyddat efter underhåll ska du använda den separata återställningsvägen för avbruten rensning i stället för att lätta på förebyggandegrinden.
Policyn är godkänd när två cykler slutförs utan överlappning, fördröjda jobb försöker igen synligt, aviseringar skickas vid missade fönster och en provåterställning fortfarande är giltig. Om den misslyckas ska du först inaktivera automatiserad rensning och låta vanliga säkerhetskopieringar fortsätta med normal låsning. Eskalera när inget underhållsfönster passar den uppmätta arbetsbelastningen eller backend-systemet inte kan slutföra rensningen på ett tillförlitligt sätt.
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å 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.
Varför stannar en Restic-säkerhetskopiering när en annan värd börjar rensa?
En fokuserad diagnos av låskonflikter vid Restic-pruning, inklusive kontroller av låsägare, säker återställning, omtestning av utlösarläget och stoppvillkor.
