Det säkra tillvägagångssättet är att behandla gatewayscheman, hälsokontroller, förhandsgranskning av kvarhållning, rensning för ompackning, efterkontroll och en isolerad återställning som en sekvens av observerbara kontrollpunkter, inte som ett enda kommando.
I ett Restic-arkiv som används av en eller flera hemservervärdar är den praktiska risken att behöva underhålla ett Restic-arkiv utan att blockera säkerhetskopieringar eller missta frigöring av utrymme för återställningsbarhet. Dokumentera den aktuella identiteten och återställningspunkten, börja med den minst ingripande skiljande kontrollen, tolka godkända och underkända resultat innan du ändrar en annan variabel och stoppa när lagringen blir instabil eller den enda återställningsbara kopian skulle exponeras. Arbetsflödet nedan avslutas först när den ursprungliga arbetsbelastningen lyckas eller bevisen når en eskaleringsgräns.
Öppna ett underhållsfönster för hela arkivet
Pausa scheman för säkerhetskopiering, glömning, kontroll, kopiering och rensning på alla värdar som kan nå arkivet. Bekräfta att ingen aktiv låsägare finns kvar, spara Restic-versionen och arkiv-ID:t och testa autentiseringsuppgifter utan att exponera dem i skaldhistorik eller loggar. Arkivunderhåll är en gemensam tillståndsändring, inte en uppgift per container.
Om en tidigare krasch lämnade kvar ett lås följer du ZimaSpace-arbetsflödet för Restic-arkiv låst efter en krasch innan du låser upp. Ett lås är ett bevis på ägarskap; ta bort det först när den angivna processen, värden, tidsstämplarna och backend-aktiviteten visar att åtgärden har avslutats.
Kontrollera ledigt utrymme i backend, inoder eller objektgränser, skrivbehörigheter samt lokalt cache- eller temporärt utrymme. Stoppa om lagringsvägen är instabil, oföränderlig kvarhållning förhindrar nödvändig radering eller en annan skrivare inte kan pausas.
Kontrollera strukturen och sampla arkivdata
Kör restic snapshots och en vanlig restic check och spara utdata och avslutningsstatus. Schemalägg sedan --read-data eller understödda delmängder av read-data utifrån arkivets storlek och bandbredd. Att endast strukturen godkänns bevisar inte att varje packfil går att läsa.
En diskussion i Restic-communityn skiljer mellan rollerna för rutinmässig check, prune och rebuild-index och förklarar att indexåterskapande inte är normalt förebyggande underhåll. Kör inte rebuild-index och radera inte packfiler för att en kontroll tar lång tid; reservera återställningskommandon för en diagnostiserad inkonsekvens.
Om check rapporterar saknade packfiler, hash-mismatch, läsfel i backend eller inkonsekvens i indexet ska du stoppa innan prune. Skydda arkivet, upprepa endast den felande läsningen via en stabil väg och eskalera till dokumenterad återställning på en kopia.
Förhandsgranska kvarhållningen och kör sedan prune och ompackning
Kör den avsedda restic forget-policyn med --dry-run och granska kvarhållna och borttagna ögonblicksbilder per värd, sökväg och taggar. Verkställ forget först när listan bevarar nödvändiga återställningspunkter. Behåll om möjligt en nyligen verifierad ögonblicksbild utanför en experimentell policyändring.
I Restic är “compact” inte ett separat kommando: prune tar bort data som inte längre refereras och packar om arkivfiler vid behov. En aktuell felsökningsguide beskriver Restic prune-fel, inklusive fel på grund av ledigt utrymme och lås som bör lösas innan ett nytt destruktivt försök.
Kör prune en gång, utan samtidiga säkerhetskopieringar, och spara hela loggen. Om det misslyckas ska du inte köra om blint eller radera objekt som ser temporära ut. Kontrollera lås, ledigt arbetsutrymme, backend-behörigheter och den senast slutförda fasen igen; bevara arkivets tillstånd för diagnostik.
Kontrollera igen och utför en isolerad återställning
Efter en lyckad prune kör du restic check igen och slutför den planerade täckningen för dataavläsning. Jämför antalet ögonblicksbilder, arkivets storlek och fel med baslinjen före underhållet. Att utrymmet inte minskar enligt en uppskattning är inte ett fel om kvarhållna ögonblicksbilder fortfarande refererar till datan.
Återställ en nylig ögonblicksbild och en äldre representativ delmängd till en tom katalog. Verifiera filinnehåll, behörigheter, tidsstämplar, symboliska länkar och en artefakt på programnivå. En monterings- eller liståtgärd ensam är inte ett återställningstest.
Återuppta scheman först när kontrollen efter prune godkänns, återställda data kan användas och en ny liten säkerhetskopiering kan skapas och återställas. Eskalera all ny korruption, upprepade backend-fel eller en ofullständig prune innan flera värdar tillåts skriva igen.
Support och tips
Mer att läsa

Migreringsguide för Borg Backup för att flytta ett arkiv till ny lagring
Flytta ett Borg-arkiv som ett enhetligt objekt: stoppa skrivningar, bevara nycklar och identitet, verifiera återställningar och uppdatera sedan klienterna samtidigt som källan behålls.

Guide för återställning av Time Machine-NAS vid trasig eller övergiven säkerhetskopieringshistorik
Behåll det gamla paketet. Separera NAS-åtkomst, destinationsidentitet, bildskador och övergiven historik innan du väljer reparation eller en ny kedja.

Checklista för granskning av snapshot-bevaring för en hem-NAS
En användbar granskning av lagringsprinciper kopplar varje ögonblicksbildsnivå till ett återställningsbehov, en ansvarig, en kapacitetsbudget och en replikeringsgräns innan historik raderas.

