Hoe optimaliseer je de Restic-pakketgrootte voor een lokale NAS-repository

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

How to Optimize Restic Pack Size for a Local NAS Repository

Houd voor een lokale NAS-repository de standaardwaarde van 16 MiB van restic aan, tenzij metingen aantonen dat de overhead van repositorybestanden of het zoekgedrag van de HDD de doorvoer beperkt. Als de NAS een repository van meerdere terabytes op draaiende schijven opslaat, zijn packs van 32 MiB of 64 MiB redelijke waarden om te benchmarken voordat je iets groters overweegt.

De packgrootte is niet hetzelfde als de deduplicatie-chunkgrootte van restic. Restic splitst bestandsgegevens eerst op in inhoudsgebaseerde blobs en groepeert die blobs vervolgens in packbestanden. Als je de doelpackgrootte wijzigt, verandert dat hoe die blobs in de repository worden gebundeld; het verandert niet het polynomial van de chunker of de inhoudshashes van de repository.

Begin met de standaardwaarde van 16 MiB

De huidige richtlijnen voor het tunen van restic geven aan dat de standaarddoelgrootte van een pack 16 MiB is. Er wordt ook vermeld dat grotere packbestanden het aantal repositorybestanden kunnen verminderen en de back-upprestaties kunnen verbeteren voor sommige repositories die op lokale HDD's zijn opgeslagen.

restic version
restic -r /mnt/nas/restic-repo snapshots
restic -r /mnt/nas/restic-repo stats --mode raw-data

Noteer vóór het tunen de restic-versie, de repositorygrootte, het aantal snapshots, het opslagtype en de huidige back-upduur. Als de repository al binnen het back-upvenster klaar is, kan een grotere packgrootte extra complexiteit opleveren zonder nuttige winst.

Begrijp wat de packgrootte daadwerkelijk verandert

In het ontwerp van de repositoryindeling van restic wordt uitgelegd dat bestandsinhoud wordt opgesplitst in inhoudsgebaseerde blobs en dat deze blobs worden gegroepeerd in packbestanden.

Bronbestanden
   |
inhoudsgebaseerde chunking
   |
ontdubbelde blobs
   |
packgroepering
   |
repositorygegevensbestanden

Een groter packdoel betekent doorgaans minder, grotere repositorybestanden. Dat kan ervoor zorgen dat een roterende schijf minder tijd kwijt is aan metadata en het openen van bestanden. Het zorgt er niet voor dat identieke bestandsinhoud beter wordt ontdubbeld.

Controleer of de NAS daadwerkelijk wordt beperkt door de packgrootte

Controleer vóór het tunen de schijf van de repository tijdens een normale incrementele back-up. Een repository op een lokale HDD die druk bezig is met veel korte zoekbewegingen en metadatabewerkingen terwijl de doorvoer laag blijft, is een betere kandidaat dan een repository op een SSD die al sequentieel op hoge snelheid schrijft.

iostat -xz 2

Let op aanhoudend schijfgebruik, verhoogde await-tijden en een lage doorvoer in vergelijking met een grote sequentiële schrijfbewerking. Controleer ook het CPU-gebruik en de leessnelheid van de bron. Als compressie, hashing, bron-I/O of netwerken de bottleneck vormen, lost een grotere pakketgrootte dat niet op.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Vergelijk 16, 32 en 64 MiB met vergelijkbare repositories

De beste vergelijking gebruikt tijdelijke repositories die speciaal voor de test zijn aangemaakt. Gebruik dezelfde brongegevensset, NAS-volume, restic-versie en het aantal backendverbindingen.

restic --pack-size 16 -r /mnt/nas/test-restic-16 init
restic --pack-size 16 -r /mnt/nas/test-restic-16 backup /srv/testdata

restic --pack-size 32 -r /mnt/nas/test-restic-32 init
restic --pack-size 32 -r /mnt/nas/test-restic-32 backup /srv/testdata

restic --pack-size 64 -r /mnt/nas/test-restic-64 init
restic --pack-size 64 -r /mnt/nas/test-restic-64 backup /srv/testdata

Meet de verstreken tijd, de schijndoorvoer van de repository, het gebruik van tijdelijke ruimte en het uiteindelijke aantal gegevensbestanden. Herhaal runs indien mogelijk, zodat effecten van de paginacache het resultaat niet bepalen.

Houd rekening met tijdelijke ruimte voordat je de pakketgrootte verhoogt

Restic documenteert de vereiste tijdelijke ruimte als ongeveer:

pakketgrootte × (backendverbindingen + 1)

Met vijf backendverbindingen en een doelwaarde van 64 MiB is dat 384 MiB aan minimale tijdelijke ruimte. De lokale backend gebruikt momenteel standaard minder verbindingen dan de meeste externe backends, maar dezelfde regel blijft van toepassing.

df -h "${TMPDIR:-/tmp}"
export TMPDIR=/mnt/fast-temp/restic
mkdir -p "$TMPDIR"

Grotere tijdelijke pakketten kunnen ook het geheugengebruik verhogen en ertoe leiden dat meer tijdelijke schrijfbewerkingen de SSD-opslag bereiken in plaats van in de cache te blijven.

Gebruik dezelfde instelling voor de pakketgrootte bij opdrachten die naar de repository schrijven

Restic geeft aan dat de instelling voor de pakketgrootte moet worden opgegeven voor elke opdracht die de repository wijzigt. Gebruik één omgevingsvariabele voor de hele taak:

export RESTIC_REPOSITORY=/mnt/nas/restic-repo
export RESTIC_PACK_SIZE=64
export RESTIC_PASSWORD_FILE=/root/.config/restic/password

restic backup /srv/data
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6
restic prune

Het wijzigen van de pakketgrootte bepaalt het deduplicatie opdelen in chunks niet opnieuw, maar het kan leiden tot pakketten met verschillende groottes. Consistentie maakt toekomstig onderhoud en prestatievergelijkingen eenvoudiger te interpreteren.

Verwacht niet dat bestaande pakketten automatisch van grootte veranderen

Een nieuwe instelling voor de pakketgrootte is van invloed op nieuw aangemaakte of opnieuw verpakte gegevens. Bestaande pakketbestanden worden niet enkel daarom herschreven RESTIC_PACK_SIZE wijzigingen.

Als je prune bewust kleinere bestaande pakketten opnieuw wilt laten verpakken, biedt de huidige versie van restic --repack-smaller-than. Bekijk eerst de opties voor het opnieuw verpakken van prune.

restic prune --dry-run --repack-smaller-than 32M

Begin met een droge run. Forceer geen volledige herverpakking alleen om elk pakketbestand er uniform uit te laten zien.

Integriteit controleren na het afstemmen

restic check
restic check --read-data-subset=5%

Kies een verificatieschema dat past bij de omvang van de repository. De richtlijnen voor probleemoplossing van repositories van restic beschouwen integriteitscontroles als basis voor het vaststellen van schade aan de repository.

Combineer de lokale repository voor een uitgebreider back-upontwerp met een andere onafhankelijke kopie. De 3-2-1-back-upstrategie van ZimaOS legt uit waarom lokale redundantie en een afzonderlijk doel verschillende storingsscenario's oplossen.

Gebruik deze beslisregel

Blijf bij 16 MiB als back-ups al binnen het tijdsvenster vallen of de bottleneck ergens anders ligt.
Test 32 MiB als een grote HDD-repository aanzienlijk veel tijd besteedt aan metagegevens en bewerkingen met kleine bestanden.
Test 64 MiB als 32 MiB helpt en het gebruik van tijdelijke opslagruimte binnen de perken blijft.
Stop met verhogen wanneer de winst afvlakt of de tijdelijke I/O toeneemt.

De beste pakketgrootte is de kleinste waarde die de overhead van de repository meetbaar vermindert zonder een nieuwe bottleneck te veroorzaken.