Rsync : option --ignore-existing

Support Debian
#1

Bonjout,

J’utilise rsync pour sauvegarder mon dossier “Musique” sur un pc distant. Le dossier est monté via le fstab (CIFS). Le fait est que, vu le nombre de fichiers très important, rsync est très lent à constituer la liste : “sending incremental file list” = 2h.

Je me suis donc penché sur les options de rsync et j’ai trouvé celle-ci : “–ignore-existing”. Ca a l’air de fonctionner comme avant et le gain de temps est énorme ; le fait est que je saisis mal ce que fait cette option…

Ce que je pense avoir compris : les fichiers existants sur la destination sont ignorés et ne sont pas updatés même s’il y a eu modif (d’un fichier texte par exemple) entre deux sauvegardes ; ce qui, pour des mp3, n’est en rien dérangeant.

Mon anglais étant approximatif, je colle ici l’extrait du man… Si une bonne âme pouvait éclairer ma lanterne sur le rôle de cette option…

[code] --existing, --ignore-non-existing
This tells rsync to skip creating files (including directories) that do not exist yet on the destination. If this option is combined with the --ignore-existing option, no files will be
updated (which can be useful if all you want to do is delete extraneous files).

          This  option is a transfer rule, not an exclude, so it doesn’t affect the data that goes into the file-lists, and thus it doesn’t affect deletions.  It just limits the files that the receiver
          requests to be transferred.

   --ignore-existing
          This tells rsync to skip updating files that already exist on the destination (this does not ignore existing directories, or nothing would get done).  See also --existing.

          This option is a transfer rule, not an exclude, so it doesn’t affect the data that goes into the file-lists, and thus it doesn’t affect deletions.  It just limits the files that the  receiver
          requests to be transferred.

          This  option  can  be  useful  for those doing backups using the --link-dest option when they need to continue a backup run that got interrupted.  Since a --link-dest run is copied into a new
          directory hierarchy (when it is used properly), using --ignore existing will ensure that the already-handled files don’t get tweaked (which avoids a change in permissions on  the  hard-linked
          files).  This does mean that this option is only looking at the existing files in the destination hierarchy itself.[/code]

Merci.

#2

Cette option est la pour gérer un cas particulier, cela ne t’aidera pas concernant le listing trop long de tes répertoires.
Peux tu nous donner ta ligne de commande complète, ça peut aider. Certaines options rsync peuvent provoquer un temps de listing bien plus long que d’autres (–checksum par exemple)

#3

Pourtant ça a l’air efficace… Pas encore testé en profondeur cela dit.

J’y pense, je n’ai pas précisé que le dossier distant est situé sur une carte micro-SD partagée à partir de ma tablette.

Merci

#4

Si tu réalise des tests de performances, méfie toi parceque linux va conserver en cache les informations sur les fichiers entre chacun de tes run. Les tests seront donc faussés.

Utilise un programme du style “nocache” (apt install nocache)

#5

Salut,

Essayes ces options et passes toi du log pour le coup.

Note : [mono]-n[/mono] ([mono]–dry-run[/mono]) on simule.

Quelles sont les options de montage des fichiers [mono]fstab[/mono] ?

PS :

[quote][mono]–log-format=FORMAT[/mono]
Ceci vous permet de spécifier exactement ce que le client rsync affiche sur la sortie standard pour chaque fichier [NDT : to log = journaliser]. Le format de journalisation est une chaîne de caractère contenant des séquences d’échappement d’un caractère préfixées par un caractère pourcent «%». La liste des différents caractères d’échappement possibles est disponible dans la partie sur le format de journalisation de la page de manuel de rsyncd.conf. (Notez que cette option ne modifie pas l’aspect du journal du démon rsync.)
Spécifier cette option forcera rsync à mentionner chaque fichier, répertoire, etc. modifié de manière significative (fichier transféré, lien symbolique/périphérique recréé, ou répertoire modifié). Si une séquence d’échappement des modifications d’attribut (%i) est inclue dans la chaîne de caractères, alors la journalisation des noms mentionnera toute entité qui a été modifiée d’une quelconque façon (tant que le côté récepteur est un rsync version 2.6.4 ou supérieure). Voir l’option --itemize-changes pour une description de l’affichage de «%i».
L’option --verbose implique le format «%n%L», mais vous pouvez utiliser --log-format sans --verbose, ou redéfinir le format de l’affichage par fichier à l’aide de cette option.
Rsync affiche la chaîne de journalisation avant le transfert du fichier à moins qu’une des statistiques de transfert ne soit demandée. Dans ce cas, la journalisation est faite après la fin du transfert. Lorsque la journalisation se fait après et que --progress a été spécifié, rsync affichera aussi le nom du fichier transféré avant l’information d’avancement (qui, bien sûr, sera ensuite suivie de l’affichage de journalisation).
[/quote]

[quote][mono]–stats[/mono]
Demande à rsync d’afficher un jeu de statistiques verbeux sur le transfert de fichiers, ce qui vous permet de quantifier l’efficacité de l’algorithme rsync pour vos données.
[/quote]

[quote][mono]–delay-updates[/mono]
Cette option indique à rsync de placer les versions temporaires des fichiers mis à jour dans un répertoire séparé jusqu’à la fin du transfert, ces fichiers seront ensuite renommés avec leur véritable nom. L’objectif est de [mono]rendre la mise à jour un petit plus atomique[/mono]. Par défaut, les fichiers sont placés dans le sous-répertoire «.~tmp~» de chaque répertoire de destination, mais vous pouvez le redéfinir avec l’option --partial-dir. (Notez que RSYNC_PARTIAL_DIR n’a aucun effet sur cette valeur, de même, lorsque --partial-dir est implicitement utilisée pour la spécification du «refus d’option», elle n’a pas d’effet sur ce répertoire.) Cette option rentre en conflit avec --inplace.
Cette option utilise plus de mémoire du côté récepteur (un bit par fichier transféré) et aussi requiert un espace disque suffisant chez le récepteur pour pouvoir contenir les copies supplémentaires de tous les fichiers mis à jour. Il faut aussi éviter d’utiliser un chemin absolu pour --partial-dir à moins d’être sûr de ne jamais avoir deux fichiers ayant le même nom (car, si le chemin est absolu, tous le fichiers mis à jour seront placé dans le même répertoire).
Voir aussi le script perl «atomic-rsync» dans le sous-répertoire «support» pour un algorithme de mis à jour encore plus atomique (il utilise --link-dest avec une hiérarchie de fichier parallèle).
[/quote]

#6

Merci pour ton aide…

Tous les fichiers sont précédés de :

>f..tp..... :

D’après le man :

Je crois comprendre que les fichiers sont donc tous transférés à chaque fois car la date et les permissions ont changé. Or que nenni, je n’ai pas touché à ces fichiers entre les deux essais et ceux-ci sont bien présents des deux côtés (serveur et client) !
Les stats le confirment :

Même résultat…

Le fstab :

EDIT :
L’option “–size-only” ne serait-elle pas interressante dans mon cas ?
Un truc du style :

#7

Aha, et les pendules ([mono]synchronisation[/mono]) sont à l’heure ? De part et d’autre ? À creuser, je pense.

[quote=“jul”]EDIT :
L’option “–size-only” ne serait-elle pas interressante dans mon cas ?[/quote]

[quote][mono]–size-only[/mono]

Normalement rsync ignore tous les fichiers qui ont la même taille et une horodate identique.
Avec l’option --size-only, les fichiers seront ignorés s’ils ont la même taille, indépendamment de l’[mono]horodate[/mono].
Ceci est utile lorsque l’on commence à se servir de rsync après avoir utilisé un autre outil de miroitage qui peut ne pas préserver les horodates exactement. [/quote]

#8

Oui des deux côtés. Par contre, le client est sous Windows (j’ai oublié de préciser…) ; le pb ne viendrait-il pas de là ?

S’il s’agit de fichiers audio (des mp3), l’horodatage a peu d’importance non ? Les fichiers ne seront jamais modifiés de toute façon… Me trompes-je ?

#9

[quote=“jul”][mono]la date et les permissions ont changé[/mono]

Effectivement, lances une quête : [mono]ACL[/mono].

#10

Je ne connais pas ça, dsl…

#11

je pense que --size-only est l’option a priviligier dans votre cas

#12

Je ne connais pas ça, dsl…[/quote]

[20:16:07]:~$ apropos acl acl (5) - Access Control Lists acl_add_perm (3) - add a permission to an ACL permission set acl_calc_mask (3) - calculate the file group class mask acl_check (3) - check an ACL for validity acl_clear_perms (3) - clear all permissions from an ACL permission set acl_cmp (3) - compare two ACLs acl_copy_entry (3) - copy an ACL entry acl_copy_ext (3) - copy an ACL from internal to external representation acl_copy_int (3) - copy an ACL from external to internal representation acl_create_entry (3) - create a new ACL entry acl_delete_def_file (3) - delete a default ACL by filename acl_delete_entry (3) - delete an ACL entry acl_delete_perm (3) - delete a permission from an ACL permission set acl_dup (3) - duplicate an ACL acl_entries (3) - return the number of entries in an ACL acl_equiv_mode (3) - check for an equivalent ACL acl_error (3) - convert an ACL error code to a text message acl_extended_fd (3) - test for information in the ACL by file descriptor acl_extended_file (3) - test for information in ACLs by file name acl_extended_file_nofollow (3) - test for information in ACLs by file name acl_free (3) - release memory allocated to an ACL data object acl_from_mode (3) - create an ACL from file permission bits acl_from_text (3) - create an ACL from text acl_get_entry (3) - get an ACL entry acl_get_fd (3) - get an ACL by file descriptor acl_get_file (3) - get an ACL by filename acl_get_perm (3) - test for a permission in an ACL permission set acl_get_permset (3) - retrieve the permission set from an ACL entry acl_get_qualifier (3) - retrieve the qualifier from an ACL entry acl_get_tag_type (3) - get the tag type of an ACL entry acl_init (3) - initialize ACL working storage acl_set_fd (3) - set an ACL by file descriptor acl_set_file (3) - set an ACL by filename acl_set_permset (3) - set the permission set in an ACL entry acl_set_qualifier (3) - set the qualifier of an ACL entry acl_set_tag_type (3) - set the tag type of an ACL entry acl_size (3) - get the size of the external representation of an ACL acl_to_any_text (3) - convert an ACL to text acl_to_text (3) - convert an ACL to text acl_valid (3) - validate an ACL [...] [20:16:13]:~$

#13

ok bon il ne me reste plus qu’à potasser ça.
Merci.

#14

Ici même ?
https://www.google.fr/search?q=acl+ntfs&ie=utf-8&oe=utf-8&gws_rd=cr&ei=UHqqVsu0B4G2aYuFpOAC#q=acl+ntfs+linux+site:debian-fr.org

#15

Salut,

Comme la souligné [mono]Fran.b[/mono] dans un sujet similaire, ailleurs …

Dans ta situation, cette option ne serait être superflue.

[quote][mono]-u[/mono], [mono]–update[/mono]

Ceci force rsync à ignorer tous les fichiers pour lesquels le fichier de destination existe déjà et avec une date postérieure à celle du fichier de source. (Si un fichier destination existant a une date égale à celle du fichier source, il ne sera mis à jour que si les tailles diffèrent.)

Dans l’implémentation courante de --update, une différence de format du fichier entre le récepteur et l’émetteur est toujours considérée comme suffisamment importante pour le mettre à jour, quelque soient les dates des fichiers.
Autrement dit, si la source est un répertoire ou un lien symbolique tandis que la destination possède un fichier, alors un transfert sera lancé, peu importe les dates.

Ce comportement est susceptible d’être modifié dans le futur (si vous avez un point de vue, vous pouvez en faire part, en anglais, à la liste de diffusion). [/quote]

#16

J’ai fais des tests avec les deux options, les deux répondent visiblement à mon besoin ; d’ailleurs, je ne vois pas de différences de comportement entre les deux.
Quelqu’un peut m’expliquer leur différence ?

Merci.