Come ottimizzare la dimensione dei pacchetti Restic per un repository NAS locale

Per un repository NAS locale, mantieni il valore predefinito di 16 MiB di restic, a meno che le misurazioni non mostrino che l’overhead dei file del repository o il comportamento di seek dell’HDD limitano il throughput. Se il NAS archivia un repository di diversi terabyte su dischi rotanti, pack da 32 MiB o 64 MiB sono valori ragionevoli da sottoporre a benchmark prima di prendere in considerazione dimensioni maggiori.

La dimensione dei pack non corrisponde alla dimensione dei chunk di deduplicazione di restic. Restic suddivide prima i dati dei file in blob definiti dal contenuto e raggruppa poi i blob nei file pack. Modificando la dimensione obiettivo dei pack cambi il modo in cui questi blob vengono raggruppati nel repository; non cambi il polinomio del chunker del repository né gli hash del contenuto.

Inizia con il valore predefinito di 16 MiB

Le attuali indicazioni di restic per l’ottimizzazione stabiliscono che la dimensione obiettivo predefinita dei pack è di 16 MiB. Indicano inoltre che file pack più grandi possono ridurre il numero di file del repository e migliorare le prestazioni del backup per alcuni repository archiviati su HDD locali.

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

Prima di ottimizzare, annota la versione di restic, le dimensioni del repository, il numero di snapshot, il tipo di storage e la durata attuale del backup. Se il repository viene già completato entro la finestra di backup, una dimensione dei pack maggiore potrebbe aggiungere complessità senza offrire vantaggi significativi.

Comprendi cosa cambia realmente con la dimensione dei pack

La progettazione del formato del repository di restic spiega che il contenuto dei file viene suddiviso in blob definiti dal contenuto e che questi blob vengono raggruppati in file pack.

File sorgente
   |
suddivisione in chunk basata sul contenuto
   |
blob deduplicati
   |
raggruppamento dei pack
   |
file di dati del repository

In genere, un obiettivo pack più grande significa un numero inferiore di file del repository, ma di dimensioni maggiori. Questo può aiutare un disco rotante a dedicare meno tempo ai metadati e all’overhead di apertura dei file. Non migliora la deduplicazione di contenuti identici.

Verifica se il NAS è realmente limitato dalla dimensione dei pack

Prima di ottimizzare, osserva il disco del repository durante un normale backup incrementale. Un repository su HDD locale occupato da molti brevi seek e operazioni sui metadati mentre il throughput resta basso è un candidato migliore rispetto a un repository su SSD che sta già scrivendo in sequenza ad alta velocità.

iostat -xz 2

Cerca un utilizzo sostenuto del disco, tempi di attesa elevati e un throughput basso rispetto a una scrittura sequenziale di grandi dimensioni. Controlla anche l'uso della CPU e la velocità di lettura dell'origine. Se il collo di bottiglia è la compressione, l'hashing, l'I/O dell'origine o la rete, aumentare la dimensione dei pacchetti non risolverà il problema.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Confronta 16, 32 e 64 MiB con repository comparabili

Il confronto più pulito utilizza repository temporanei creati per il test. Usa lo stesso dataset di origine, lo stesso volume NAS, la stessa versione di restic e lo stesso numero di connessioni al backend.

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

Misura il tempo trascorso, il throughput del disco del repository, l'uso dello spazio temporaneo e il numero risultante di file di dati. Ripeti le esecuzioni quando possibile, in modo che gli effetti della cache delle pagine non determinino il risultato.

Tieni conto dello spazio temporaneo prima di aumentare la dimensione dei pacchetti

Restic documenta il requisito di spazio temporaneo approssimativamente come:

dimensione del pacchetto × (connessioni al backend + 1)

Con cinque connessioni al backend e un obiettivo di 64 MiB, sono necessari almeno 384 MiB di spazio temporaneo. Attualmente il backend locale usa per impostazione predefinita meno connessioni rispetto alla maggior parte dei backend remoti, ma la stessa regola rimane valida.

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

Pacchetti temporanei più grandi possono anche aumentare l'uso della memoria e far sì che un numero maggiore di scritture temporanee raggiunga lo spazio di archiviazione SSD invece di rimanere nella cache.

Mantieni la stessa impostazione della dimensione dei pacchetti nei comandi che scrivono nel repository

Restic indica che l'impostazione della dimensione dei pacchetti dovrebbe essere specificata per ogni comando che modifica il repository. Usa una variabile d'ambiente per l'intero processo:

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

Modificare la dimensione dei pacchetti non ridefinisce la suddivisione in blocchi per la deduplicazione, ma può lasciare pacchetti di dimensioni diverse. La coerenza rende più facile interpretare la manutenzione futura e i confronti delle prestazioni.

Non aspettarti che i pacchetti esistenti vengano ridimensionati automaticamente

Una nuova impostazione della dimensione dei pacchetti influisce sui dati creati o ricompattati successivamente. I file di pacchetto esistenti non vengono riscritti semplicemente perché RESTIC_PACK_SIZE modifiche.

Se vuoi intenzionalmente che prune ricompatti i pacchetti esistenti più piccoli, le versioni attuali di restic forniscono --repack-smaller-than. Consulta prima le opzioni di ricompattazione di prune.

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

Inizia con una simulazione. Non forzare una ricompattazione completa solo per rendere uniformi tutti i file di pacchetto.

Convalida l'integrità dopo la regolazione

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

Scegli una pianificazione delle verifiche adatta alle dimensioni del repository. La guida alla risoluzione dei problemi del repository di restic considera i controlli di integrità la base per diagnosticare i danni al repository.

Per una strategia di backup più ampia, combina il repository locale con un'altra copia indipendente. La strategia di backup 3-2-1 di ZimaOS spiega perché la ridondanza locale e una destinazione separata risolvono modalità di guasto diverse.

Usa questa regola decisionale

• Mantieni 16 MiB se i backup rientrano già nella finestra prevista o il collo di bottiglia si trova altrove.
• Prova 32 MiB se un repository su HDD di grandi dimensioni trascorre molto tempo nelle operazioni sui metadati e sui file piccoli.
• Prova 64 MiB se 32 MiB offre vantaggi e l'uso dello spazio temporaneo rimane sotto controllo.
• Smetti di aumentare il valore quando i miglioramenti si appiattiscono o aumenta l'I/O temporaneo.

La dimensione ottimale dei pacchetti è il valore più piccolo che riduce in modo misurabile l'overhead del repository senza creare un nuovo collo di bottiglia.

FAQ sulla dimensione dei pacchetti di restic

Una dimensione maggiore dei pacchetti migliora la deduplicazione di restic?

No. La deduplicazione avviene a livello di blob/chunk prima che i blob vengano raggruppati nei file di pacchetto.

La modifica della dimensione dei pacchetti riscriverà i vecchi file di pacchetto?

No. I pacchetti esistenti rimangono invariati finché le normali operazioni di pulizia o ricompattazione non li riscrivono.

Quale dimensione dei pacchetti dovrei provare per prima su un NAS con HDD locale?

Usa 16 MiB come valore di riferimento, quindi confronta 32 MiB e 64 MiB con lo stesso carico di lavoro.