Comment optimiser la taille des paquets Restic pour un dépôt NAS local

Pour un dépôt NAS local, conservez la valeur par défaut de 16 Mio de restic, sauf si des mesures montrent que la surcharge liée aux fichiers du dépôt ou le comportement de recherche du disque dur limitent le débit. Si le NAS stocke un dépôt de plusieurs téraoctets sur des disques rotatifs, des paquets de 32 Mio ou de 64 Mio sont des valeurs raisonnables à tester avant d’envisager une taille supérieure.

La taille des paquets n’est pas la même chose que la taille des blocs de déduplication de restic. Restic divise d’abord les données des fichiers en blobs définis par le contenu, puis regroupe ces blobs dans des fichiers de paquets. Modifier la taille cible des paquets change la manière dont ces blobs sont regroupés dans le dépôt ; cela ne modifie ni le polynôme du découpeur du dépôt ni les hachages du contenu.

Commencer par la valeur par défaut de 16 Mio

Les recommandations actuelles de réglage de restic indiquent que la taille cible par défaut des paquets est de 16 Mio. Elles précisent également que des fichiers de paquets plus volumineux peuvent réduire le nombre de fichiers du dépôt et améliorer les performances des sauvegardes pour certains dépôts stockés sur des disques durs locaux.

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

Avant tout réglage, notez la version de restic, la taille du dépôt, le nombre d’instantanés, le type de stockage et la durée actuelle de la sauvegarde. Si le dépôt est déjà traité dans la fenêtre de sauvegarde, une taille de paquet plus grande peut ajouter de la complexité sans apporter de gain utile.

Comprendre ce que modifie réellement la taille des paquets

La conception du format de dépôt de restic explique que le contenu des fichiers est divisé en blobs définis par le contenu, puis que ces blobs sont regroupés dans des fichiers de paquets.

Fichiers sources
   |
découpage en blocs défini par le contenu
   |
blobs dédupliqués
   |
regroupement des paquets
   |
fichiers de données du dépôt

Une cible de paquet plus grande signifie généralement moins de fichiers de dépôt, mais plus volumineux. Cela peut aider un disque rotatif à consacrer moins de temps aux métadonnées et à la surcharge liée à l’ouverture des fichiers. Cela n’améliore pas la déduplication d’un contenu de fichier identique.

Vérifier si le NAS est réellement limité par la taille des paquets

Avant tout réglage, observez le disque du dépôt pendant une sauvegarde incrémentielle normale. Un dépôt sur disque dur local, très sollicité par de nombreuses recherches courtes et opérations sur les métadonnées alors que le débit reste faible, est un meilleur candidat qu’un dépôt SSD qui écrit déjà séquentiellement à grande vitesse.

iostat -xz 2

Recherchez une utilisation soutenue du disque, des temps d’attente élevés et un faible débit par rapport à une écriture séquentielle de grande taille. Vérifiez également l’utilisation du processeur et la vitesse de lecture de la source. Si la compression, le hachage, les E/S de la source ou le réseau constituent le goulot d’étranglement, augmenter la taille des packs ne résoudra pas le problème.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Comparez 16, 32 et 64 Mio avec des dépôts comparables

La comparaison la plus claire utilise des dépôts jetables créés pour le test. Utilisez le même jeu de données source, le même volume NAS, la même version de Restic et le même nombre de connexions au 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

Mesurez le temps écoulé, le débit du disque du dépôt, l’utilisation de l’espace temporaire et le nombre de fichiers de données obtenu. Répétez les exécutions si possible afin que les effets du cache de pages ne déterminent pas le résultat.

Prévoyez de l’espace temporaire avant d’augmenter la taille des packs

Restic documente l’espace temporaire requis comme suit, approximativement :

taille du pack × (connexions au backend + 1)

Avec cinq connexions au backend et une cible de 64 Mio, cela représente 384 Mio d’espace temporaire minimal. Le backend local utilise actuellement par défaut moins de connexions que la plupart des backends distants, mais la même règle s’applique.

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

Des packs temporaires plus volumineux peuvent également accroître l’utilisation de la mémoire et entraîner l’écriture de davantage de données temporaires sur le SSD au lieu de les laisser dans le cache.

Conservez le même paramètre de taille des packs pour les commandes qui écrivent dans le dépôt

Restic indique que le paramètre de taille des packs doit être spécifié pour chaque commande qui modifie le dépôt. Utilisez une variable d’environnement pour toute la tâche :

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

Modifier la taille des packs ne redéfinit pas le découpage pour la déduplication, mais peut laisser des packs de tailles différentes. La cohérence facilite la maintenance ultérieure et l’interprétation des comparaisons de performances.

Ne vous attendez pas à ce que les packs existants soient redimensionnés automatiquement

Un nouveau réglage de la taille des packs s’applique aux données nouvellement créées ou recombinées. Les fichiers de pack existants ne sont pas réécrits simplement parce que RESTIC_PACK_SIZE changements.

Si vous souhaitez intentionnellement que prune recombine les petits packs existants, la version actuelle de restic fournit --repack-smaller-than. Consultez d’abord les options de recomposition de prune.

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

Commencez par une simulation. Ne forcez pas une recomposition complète uniquement pour uniformiser l’apparence de tous les fichiers de pack.

Valider l’intégrité après le réglage

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

Choisissez une fréquence de vérification adaptée à la taille du dépôt. La documentation de dépannage des dépôts de restic considère les vérifications d’intégrité comme la base du diagnostic des dommages subis par un dépôt.

Pour une stratégie de sauvegarde plus complète, associez le dépôt local à une autre copie indépendante. La stratégie de sauvegarde 3-2-1 de ZimaOS explique pourquoi la redondance locale et une cible distincte répondent à des modes de défaillance différents.

Utilisez cette règle de décision

• Restez à 16 Mio si les sauvegardes respectent déjà la fenêtre prévue ou si le goulot d’étranglement se situe ailleurs.
• Testez 32 Mio si un dépôt volumineux sur disque dur passe beaucoup de temps sur les métadonnées et les opérations impliquant de petits fichiers.
• Testez 64 Mio si 32 Mio apporte une amélioration et que l’utilisation de l’espace temporaire reste acceptable.
• Arrêtez d’augmenter la taille lorsque les gains s’aplanissent ou que les entrées-sorties temporaires augmentent.

La meilleure taille de pack est la plus petite valeur qui réduit de manière mesurable la surcharge du dépôt sans créer de nouveau goulot d’étranglement.

FAQ sur la taille des packs de restic

Une taille de pack plus importante améliore-t-elle la déduplication de restic ?

Non. La déduplication s’effectue au niveau des blobs ou des fragments, avant leur regroupement dans des fichiers de pack.

La modification de la taille des packs réécrit-elle mes anciens fichiers de pack ?

Non. Les packs existants sont conservés jusqu’à ce qu’une opération normale de purge ou de recomposition les réécrive.

Quelle taille de pack dois-je essayer en premier sur un NAS équipé d’un disque dur local ?

Utilisez 16 Mio comme référence, puis évaluez 32 Mio et 64 Mio avec la même charge de travail.