7 votes

Chunking de gros transferts rsync ?

Nous utilisons rsync pour mettre à jour un miroir de notre serveur de fichiers principal vers un serveur de sauvegarde colocalisé hors site. L'un des problèmes que nous rencontrons actuellement est que notre serveur de fichiers contient plus de 1 To de fichiers de petite taille (de l'ordre de 10 à 100 Ko), et lorsque nous transférons autant de données, la connexion est souvent interrompue plusieurs heures après le transfert. Rsync n'a pas de fonction de reprise/répétition qui se reconnecte simplement au serveur pour reprendre là où il s'est arrêté - il faut passer par le processus de comparaison de fichiers, qui finit par être très long avec la quantité de fichiers que nous avons.

La solution recommandée pour contourner ce problème est de diviser votre gros transfert rsync en une série de transferts plus petits. J'ai trouvé que la meilleure façon de le faire est d'utiliser la première lettre du nom des répertoires de premier niveau, ce qui ne nous donne pas une distribution parfaitement égale, mais c'est suffisant.

J'aimerais savoir si ma méthode est saine ou s'il existe un moyen plus simple d'atteindre cet objectif.

Pour ce faire, j'itère à travers A-Z, a-z, 0-9 pour choisir un caractère unique. $prefix . Au départ, je pensais simplement exécuter

rsync -av --delete --delete-excluded --exclude "*.mp3" "src/$prefix*" dest/

(--exclude "*.mp3" est juste un exemple, car nous avons une liste d'exclusion plus longue pour supprimer des choses comme les fichiers temporaires)

Le problème est que tous les répertoires de premier niveau dans dest/ qui ne sont plus présents dans src ne seront pas pris en compte par --delete. Pour contourner ce problème, j'essaie plutôt ce qui suit :

rsync \
--filter 'S /$prefix*' \
--filter 'R /$prefix*' \
--filter 'H /*' \
--filter 'P /*' \
-av --delete --delete-excluded --exclude "*.mp3" src/ dest/

J'utilise le show y hide sur include y exclude car sinon, le paramètre --delete-excluded supprimera tout ce qui ne correspond pas à $prefix.

Est-ce le moyen le plus efficace de diviser le rsync en petits morceaux ? Existe-t-il un outil plus efficace, ou un drapeau que j'ai manqué, qui pourrait rendre cela plus simple ?

4voto

Ben Forsdyke Points 159

La solution que j'ai trouvée à ce problème est une approche différente, en deux passages, où j'échange un peu d'espace disque. Je fais rsync --only-write-batch sur le serveur, puis rsync le fichier batch lui-même vers la destination, en bouclant jusqu'à ce que le rsync réussisse. Une fois que le lot est complètement terminé, rsync --read-batch sur la destination recrée toutes les modifications.

Il y a quelques avantages involontaires à cela pour moi aussi :

  • parce que je suis plus préoccupé par le fait que la sauvegarde "existe" que par le fait qu'elle soit "utilisable", je ne fais pas vraiment le lot de lecture du côté récepteur tous les jours -- la plupart du temps, le lot est relativement petit.

  • J'ai fait des essais avec --checksum-seed=1 ... J'ai peut-être mal lu la documentation mais je pense que cela rend les fichiers batch plus synchronisables (c'est-à-dire que si je ne fais pas le --read-batch un jour donné, le batch du lendemain se synchronise plus rapidement car le batch de la veille est une bonne base).

  • si le lot est trop volumineux pour être envoyé "à temps" par Internet, je peux le transférer sur un disque externe. Par "à temps", je veux dire que si je ne peux pas envoyer le lot et le lire avant que la sauvegarde du jour suivant ne commence.

  • Bien que je ne le fasse pas personnellement, je pourrais avoir deux sauvegardes hors site dans des endroits distincts et envoyer le lot à chacune d'elles.

3voto

James Points 7442

Je ne réponds pas exactement à votre question, mais une autre option que j'utilise assez souvent est de procéder en deux temps : d'abord établir une liste de fichiers, puis diviser la liste des fichiers à transférer et introduire la liste de fichiers dans rsync/cpio/cp, etc.

rsync --itemize-changes <rest of options> imprimera une liste de fichiers à transférer avec un tas de métadonnées utiles, à partir de cette sortie, il est assez facile d'extraire les noms de fichiers et de faire la copie proprement dite avec l'une ou l'autre des méthodes suivantes rsync --files-from ou un autre outil.

Cela pourrait être utile dans votre situation - reprendre à partir d'un transfert interrompu serait beaucoup plus rapide.

1voto

hgf Points 156

Je vous suggère d'examiner le problème de connexion, au lieu d'essayer de le résoudre en créant un autre "problème".

Ce n'est pas un comportement courant. Utilisez-vous rsync via SSH ou rsyncd ?

Pour autant que je sache, la plupart des connexions "fermées" se produisent lorsqu'il n'y a pas de données transférées entre les points d'extrémité.

0 votes

Il fonctionne via ssh car nous n'avons pas de point d'extrémité VPN au coloc. Nous avons expérimenté l'utilisation de stunnel, mais c'est une autre couche qui a introduit une autre couche de bugs de réinitialisation de la connexion. En ce qui concerne l'interruption de la connexion, ce n'est pas un problème qui se produit immédiatement - nous rencontrons généralement des interruptions de ce type au bout de 24 à 48 heures. Il est difficile de diagnostiquer une telle perte de connexion, d'autant plus qu'il n'y a probablement pas grand-chose à faire pour y remédier. Je pense qu'il est plus pragmatique de prévoir l'inévitable défaillance du réseau avec une solution comme celle-ci qui réduit de manière significative les frais généraux liés à la reconnexion.

0 votes

Avez-vous essayé le paramètre KeepAlive dans sshd.conf ? Une autre idée est d'essayer fuse-sshfs avec "-o reconnect" dans les options "mount". Et l'utiliser pour rsync comme point de montage local.

0 votes

Soyez prudent lorsque vous utilisez rsync avec local-to-local car il peut finir par copier des fichiers entiers.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X