Så optimerar du Restic-paketstorleken för ett lokalt NAS-arkiv

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

How to Optimize Restic Pack Size for a Local NAS Repository

För ett lokalt NAS-arkiv bör du behålla restics standardvärde på 16 MiB, såvida inte mätningar visar att overhead från arkivfiler eller HDD-sökningar begränsar genomströmningen. Om NAS-enheten lagrar ett arkiv på flera terabyte på roterande diskar är 32 MiB eller 64 MiB rimliga värden att benchmarka innan du överväger något större.

Packstorleken är inte samma sak som restics chunkstorlek för deduplicering. Restic delar först upp fildata i innehållsdefinierade blobbar och grupperar sedan blobbarna i packfiler. När målpackstorleken ändras påverkas hur dessa blobbar paketeras i arkivet; arkivets chunker-polynom eller innehållshashar ändras inte.

Börja med standardvärdet 16 MiB

Den aktuella vägledningen för finjustering av restic anger att standardmålet för packstorleken är 16 MiB. Den påpekar också att större packfiler kan minska antalet arkivfiler och förbättra säkerhetskopieringsprestandan för vissa arkiv som lagras på lokala HDD-enheter.

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

Anteckna restic-versionen, arkivets storlek, antalet ögonblicksbilder, lagringstypen och den aktuella säkerhetskopieringstiden innan du finjusterar. Om arkivet redan blir klart inom säkerhetskopieringsfönstret kan en större packstorlek medföra mer komplexitet utan att ge någon märkbar nytta.

Förstå vad packstorleken faktiskt ändrar

Restics design av arkivformatet förklarar att filinnehåll delas upp i innehållsdefinierade blobbar och att dessa blobbar grupperas i packfiler.

Källfiler
   |
innehållsdefinierad chunkindelning
   |
deduplicerade blobbar
   |
packgruppering
   |
datafiler i arkivet

Ett större packmål innebär i allmänhet färre och större arkivfiler. Det kan hjälpa en roterande disk att lägga mindre tid på metadata och overhead för filöppning. Det gör inte att identiskt filinnehåll dedupliceras bättre.

Kontrollera om NAS-enheten faktiskt är begränsad av packstorleken

Innan du finjusterar bör du övervaka lagringsdisken i arkivet under en normal inkrementell säkerhetskopiering. Ett lokalt HDD-arkiv som är upptaget med många korta sökningar och metadataoperationer medan genomströmningen förblir låg är en bättre kandidat än ett SSD-arkiv som redan skriver sekventiellt med hög hastighet.

iostat -xz 2

Leta efter ihållande diskanvändning, förhöjda await-tider och låg genomströmning jämfört med en stor sekventiell skrivning. Kontrollera även CPU-användning och läshastighet från källan. Om komprimering, hashberäkning, käll-I/O eller nätverk är flaskhalsen löser en ökad packstorlek inte problemet.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Jämför 16, 32 och 64 MiB med jämförbara arkiv

Den renaste jämförelsen använder engångsarkiv som skapas för testet. Använd samma källdatauppsättning, NAS-volym, Restic-version och antal backendanslutningar.

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

Mät förfluten tid, genomströmning för arkivets disk, användning av tillfälligt utrymme och antalet resulterande datafiler. Upprepa körningarna när det är möjligt, så att effekter från sidcachen inte avgör resultatet.

Ta hänsyn till tillfälligt utrymme innan du ökar packstorleken

Restic dokumenterar kravet på tillfälligt utrymme ungefär så här:

packstorlek × (backendanslutningar + 1)

Med fem backendanslutningar och ett mål på 64 MiB krävs minst 384 MiB tillfälligt utrymme. Den lokala backendanslutningen använder för närvarande som standard färre anslutningar än de flesta fjärranslutningar, men samma regel gäller fortfarande.

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

Större tillfälliga packfiler kan också öka minnesanvändningen och göra att fler tillfälliga skrivningar når SSD-lagringen i stället för att förbli i cachen.

Använd samma packstorleksinställning för kommandon som skriver till arkivet

Restic anger att packstorleksinställningen bör anges för varje kommando som ändrar arkivet. Använd en miljövariabel för hela jobbet:

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

Att ändra packstorleken omdefinierar inte dedupliceringssegmenteringen, men det kan leda till packfiler av olika storlek. Enhetlighet gör framtida underhåll och prestandajämförelser enklare att tolka.

Förvänta dig inte att befintliga packfiler ändrar storlek automatiskt

En ny inställning för packstorlek påverkar nyskapade eller ompaketerade data. Befintliga packfiler skrivs inte om enbart för att RESTIC_PACK_SIZE ändringar.

Om du avsiktligt vill att prune ska paketera om mindre befintliga packfiler erbjuder aktuella versioner av restic --repack-smaller-than. Läs först alternativen för ompaketering med prune.

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

Börja med en torrkörning. Tvinga inte fram en fullständig ompaketering enbart för att få alla packfiler att se enhetliga ut.

Verifiera integriteten efter justering

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

Välj ett verifieringsschema som passar arkivets storlek. Restics felsökningsvägledning för arkiv behandlar integritetskontroller som grunden för att diagnostisera skador på arkivet.

För en mer omfattande säkerhetskopieringsdesign kan du kombinera det lokala arkivet med en annan oberoende kopia. ZimaOS 3-2-1-strategi för säkerhetskopiering förklarar varför lokal redundans och ett separat mål hanterar olika typer av fel.

Använd denna beslutsregel

Behåll 16 MiB om säkerhetskopieringarna redan ryms inom tidsfönstret eller om flaskhalsen finns någon annanstans.
Testa 32 MiB om ett stort HDD-arkiv tillbringar mycket tid med metadata och åtgärder på små filer.
Testa 64 MiB om 32 MiB ger bättre resultat och användningen av tillfälligt utrymme fortfarande är hanterbar.
Sluta öka när förbättringarna avtar eller den tillfälliga I/O-belastningen ökar.

Den bästa packstorleken är det minsta värde som märkbart minskar overheaden i arkivet utan att skapa en ny flaskhals.