Restic-repositoryonderhoudsworkflow: controleren, opschonen, comprimeren en herstel testen

De veilige aanpak is om gates voor planning, controle, retentievoorvertoning, prune voor herverpakken, hercontrole en een geïsoleerde restore te behandelen als een reeks waarneembare gates, niet als één enkele opdracht.

Bij een Restic-repository die door een of meer homeserverhosts wordt gebruikt, bestaat het praktische risico uit de noodzaak om een Restic-repository te onderhouden zonder back-ups te blokkeren of het terugwinnen van ruimte te verwarren met herstelbaarheid. Leg de huidige identiteit en het herstelpunt vast, begin met de minst ingrijpende onderscheidende controle, interpreteer geslaagde en mislukte resultaten voordat je een andere variabele wijzigt, en stop wanneer de opslag instabiel wordt of wanneer de enige herstelbare kopie zou worden blootgesteld. De onderstaande workflow eindigt pas nadat de oorspronkelijke workload slaagt of het bewijs een escalatiegrens bereikt.

Open een repositorybrede onderhoudsperiode

Pauzeer back-up-, forget-, check-, copy- en prune-schema's op elke host die toegang heeft tot de repository. Controleer of er geen actieve lock-eigenaar meer is, sla de Restic-versie en repository-ID op en test de inloggegevens zonder ze bloot te stellen in shellgeschiedenis of logs. Repositoryonderhoud is één gedeelde statuswijziging, geen taak per container.

Als een eerdere crash een lock heeft achtergelaten, volg dan de ZimaSpace-workflow voor een Restic-repository die na een crash vergrendeld is voordat je de lock verwijdert. Een lock is bewijs van eigenaarschap; verwijder deze pas nadat het genoemde proces, de host, tijdstempels en backendactiviteit aantonen dat de bewerking is beëindigd.

Controleer de beschikbare ruimte op de backend, inode- of objectlimieten, schrijfrechten en lokale cache- of tijdelijke ruimte. Stop als het opslagpad instabiel is, onveranderlijke retentie de vereiste verwijdering blokkeert of een andere schrijver niet kan worden gepauzeerd.

Controleer de structuur en neem een steekproef van repositorygegevens

Voer restic snapshots en een normale restic check uit en sla de uitvoer en afsluitstatus op. Plan vervolgens --read-data of ondersteunde subsets voor het lezen van gegevens, afgestemd op de omvang van de repository en de beschikbare bandbreedte. Succes van alleen de structuurcontrole bewijst niet dat elk pack leesbaar is.

Een discussie in de Restic-community onderscheidt de routinematige rollen van check, prune en rebuild-index en legt uit dat het opnieuw opbouwen van de index geen normaal preventief onderhoud is. Voer rebuild-index niet uit en verwijder geen packbestanden omdat een check langzaam is; gebruik herstelopdrachten alleen bij een vastgestelde inconsistentie.

Als check ontbrekende packs, een hashverschil, een leesfout op de backend of een inconsistentie in de index meldt, stop dan vóór prune. Bescherm de repository, herhaal alleen de mislukte leesbewerking via een stabiel pad en escaleer naar gedocumenteerd herstel op een kopie.

Bekijk retentie vooraf en voer daarna prune en herverpakken uit

Voer het beoogde restic forget-beleid uit met --dry-run en controleer de behouden en verwijderde snapshots per host, pad en tags. Voer forget pas definitief uit wanneer de lijst de vereiste herstelpunten behoudt. Bewaar indien mogelijk een recente geverifieerde snapshot buiten een experimentele beleidswijziging.

In Restic is “compact” geen afzonderlijke opdracht: prune verwijdert niet-gerefereerde gegevens en verpakt repositorybestanden indien nodig opnieuw. Een actuele handleiding voor probleemoplossing beschrijft Restic-prunefouten, waaronder fouten door onvoldoende vrije ruimte en locks, die moeten worden opgelost voordat je opnieuw een destructieve poging doet.

Voer prune één keer uit, zonder gelijktijdige back-ups, en bewaar het volledige logboek. Als de opdracht mislukt, voer deze dan niet blind opnieuw uit en verwijder geen objecten die er tijdelijk uitzien. Controleer opnieuw de locks, beschikbare werkruimte, backendrechten en de laatst voltooide fase; bewaar de repositorystatus voor diagnose.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Voer een hercontrole en een geïsoleerde restore uit

Voer na een geslaagde prune opnieuw restic check uit en voltooi de geplande dekking voor het lezen van gegevens. Vergelijk het aantal snapshots, de repositorygrootte en de fouten met de nulmeting vóór het onderhoud. Als de ruimte niet afneemt volgens een schatting, is dat geen fout wanneer behouden snapshots nog steeds naar de gegevens verwijzen.

Restore een recente snapshot en een oudere representatieve subset naar een lege map. Controleer bestandsinhoud, rechten, tijdstempels, symbolische koppelingen en één artefact op applicatieniveau. Alleen mounten of een lijst opvragen is geen restoretest.

Hervat de schema's pas wanneer de controle na prune slaagt, de gerestorde gegevens bruikbaar zijn en een nieuwe kleine back-up kan worden gemaakt en gerestored. Escaleer nieuwe corruptie, terugkerende backendfouten of een onvolledige prune voordat meerdere hosts weer mogen schrijven.