Résolu - rsync sauvegarde des fichiers non modifiés

hcm · Le 23/01/2023, à 10:55

Bonjour,

J'ai écrit un script, qui s'appuie sur rsync, pour réduire le temps de transfert de grosses arborescences entre deux ordinateurs via une clef USB.
De ce point de vue, le script me donne satisfaction en réduisant considérablement le temps de transfert (dans un sens ou l'autre entre la clef et d'un des ordinateurs) mais ...
... en examinant le nombre de fichiers (puis leurs noms via l'option --info=NAME1) je m'aperçois que certains fichiers sont systématiquement transférés par rsync alors qu'ils n'ont jamais été modifié, et je me demande bien pourquoi ...

Sur quel(s) critère(s) s'appuie rsync pour effectuer le transfert de la source vers la destination ? Si je lance ce script deux fois de suite, sans modifier de fichiers, j'ai toujours ces quelques fichiers (principalement des fichiers texte) qui sont transférés.

Précisions; le script est lancé avec la commande sudo, et les options utilisées pour la commande rsync sont les suivantes:

--info=NAME1 -a --del --force --ignore-errors --stats --filter "- .thumbnails/" --filter "- .Trash/" --filter "- *.tmp" --filter "- *.iso" --filter "- lost+found/" --filter "- .cache/"  --filter "- .beagle/"

Merci pour vos éclairages

Dernière modification par hcm (Le 23/01/2023, à 17:29)

Vobul · Le 23/01/2023, à 11:54

Quel est le système de fichiers sur la clé ? Quels sont les fichiers systématiquement transférés ? As-tu vérifié la date de modification de ces fichiers ? Ils sont peut-être modifiés par le système.

hcm · Le 23/01/2023, à 12:19

Merci Vobul de t'intéresser à la question

La clef USB est formatée en partition DOS.
Les fichiers transférés sont des fichiers textes (scripts par exemple) qui n'ont pas été modifié depuis très longtemps (j'ai vérifié la date de modification via ls-l). Et en tout cas, jamais entre deux lancements consécutifs du script. Ni par le script, ni par le système.

Pour info, je viens de vérifier. Les fichiers présents sur la clef ont bien la même date que ceux présents sur le DD.

Dernière modification par hcm (Le 23/01/2023, à 15:11)

Vobul · Le 23/01/2023, à 12:49

> La clef USB est formatée en partition DOS.

Tu sembles confondre la table de partition (MBR ou GPT) et le système de fichiers (ext4 ou FAT32 par exemple), qui sont deux choses différentes. J'imagine que ta clé est en FAT32.

Donne aussi l'output de "ls -la" des dossiers source et destination en ne laissant que les fichiers qui sont toujours transférés + un autre qui n'est pas systématiquement transféré.

Peut-être également un souci avec les attributs. J'imagine que les scripts sont "+x", or sur FAT32 t'as pas ça, donc il voit une diff, un truc du genre.

À noter que si tu veux faire un backup, tu ferais mieux de formater ta clé en ext4 !

Dernière modification par Vobul (Le 23/01/2023, à 13:07)

hcm · Le 23/01/2023, à 14:49

Je te confirme que la clef est bien en FAT32.
La formater en ext4 poserait problème car j'ai parfois des transferts de fichiers à faire entre une machine Linux et une machine Windows.

Ce script me sert à transférer différentes arborescences. Notamment une, assez légère (une centaine de fichiers) qui contient tous mes scripts (et là, l'arborescence est recopiée intégralement à chaque fois, comme je viens de m'en apercevoir !), une autre, beaucoup plus volumineuse, qui contient un site internet (et là seulement certains fichiers sont recopiés même non modifiés).

Concernant le contenu d'un des répertoires problématique du site internet, cela donne ceci.
Voilà le contenu d'un répertoire source qui pose problème (le fichier private.xml fait partie des fichiers recopiés systématiquement, pas les deux autres)

user1$ ls -al site/nbproject/private/
total 16
drwxr-xr-x 2 user1 user1 4096 janv. 13 18:10 .
drwxr-xr-x 3 user1 user1 4096 janv. 13 18:10 ..
-rw-r--r-- 1 user1 user1    0 déc.   7 15:23 config.properties
-rw-r--r-- 1 user1 user1  151 déc.   7 15:25 private.properties
-rw-r--r-- 1 user1 user1  736 janv. 23 08:54 private.xml
user1$

Le même répertoire sur la cible (la clef USB)

user1$ ls -al /media/user1/CLEF-VERTE/Sauvegardes/site/nbproject/private
total 16
drwxr-xr-x 2 user1 user1 4096 janv. 13 18:10 .
drwxr-xr-x 3 user1 user1 4096 janv. 13 18:10 ..
-rw-r--r-- 1 user1 user1    0 déc.   7 15:23 config.properties
-rw-r--r-- 1 user1 user1  151 déc.   7 15:25 private.properties
-rw-r--r-- 1 user1 user1  736 janv. 23 08:54 private.xml
user1$

Dernière modification par hcm (Le 23/01/2023, à 14:50)

hcm · Le 23/01/2023, à 15:59

Par curiosité, j'ai utilisé une autre clef formatée cette fois en ext4.
Et là tout fonctionne parfaitement. Seuls les fichiers réellement modifiés, entre deux appels au script, sont effectivement transférés.

Il semble donc que ce soit bien le système de fichier FAT32 de la première clef qui pose problème. Un moyen d'expliquer et/ou de contourner cela ?

Dernière modification par hcm (Le 23/01/2023, à 16:01)

bruno · Le 23/01/2023, à 16:22

hcm a écrit :

Il semble donc que ce soit bien le système de fichier FAT32 de la première clef qui pose problème. Un moyen d'expliquer et/ou de contourner cela ?

Bonjour,
Ce qui pose problème c'est que le système de fichier source (ext4) gère davantage d'attributs de fichiers que celui de destination (fat32) : entre autres les propriétaires, groupes, droits d'accès, etc. ou les gère différemment : date d'accès, noms, etc.
Et non il n'y a pas moyen de contourner cela. Idéalement quand on utilise rsync il faudrait que les systèmes de fichiers soient identiques.

Tu peux tout de m^me essayer de passer cette option si c'est uniquement un problème de date de fichiers :

--modify-window=1

cf. man rsync (gras ajouté)

man rsync a écrit :

--modify-window=NUM, -@
When comparing two timestamps, rsync treats the timestamps as being equal if they differ by no more than the modify-window value. The default is 0, which matches just integer seconds. If you specify a negative value (and the receiver is at least version 3.1.3) then nanoseconds will also be taken into account. Specifying 1 is useful for copies to/from MS Windows FAT filesystems, because FAT represents times with a 2-second resolution (allowing times to differ from the original by up to 1 second).

Dernière modification par bruno (Le 23/01/2023, à 16:27)

hcm · Le 23/01/2023, à 17:28

Nickel. Cela fonctionne parfaitement.
En ajoutant l'option

--modify-window=1

je peux utiliser la clef formatée en FAT32 et seuls les fichiers modifiés sont copiés.
Bravo à tous les deux, et merci pour votre aide.

Vobul · Le 23/01/2023, à 18:56

Arf, j'avais mis cette option en suggestion puis je l'ai retirée dans mon edit ! Mais j'avais mis 2 au lieu de 1.

geole · Le 24/01/2023, à 10:05

Bonjour
Pourvu qu'il n'y ait besoin, un jour, de transférer des fichiers dont la taille dépasse 4 Go.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 23/01/2023, à 10:55

Résolu - rsync sauvegarde des fichiers non modifiés

#2 Le 23/01/2023, à 11:54

Re : Résolu - rsync sauvegarde des fichiers non modifiés

#3 Le 23/01/2023, à 12:19

Re : Résolu - rsync sauvegarde des fichiers non modifiés

#4 Le 23/01/2023, à 12:49

Re : Résolu - rsync sauvegarde des fichiers non modifiés

#5 Le 23/01/2023, à 14:49

Re : Résolu - rsync sauvegarde des fichiers non modifiés

#6 Le 23/01/2023, à 15:59

Re : Résolu - rsync sauvegarde des fichiers non modifiés

#7 Le 23/01/2023, à 16:22

Re : Résolu - rsync sauvegarde des fichiers non modifiés

#8 Le 23/01/2023, à 17:28

Re : Résolu - rsync sauvegarde des fichiers non modifiés

#9 Le 23/01/2023, à 18:56

Re : Résolu - rsync sauvegarde des fichiers non modifiés

#10 Le 24/01/2023, à 10:05

Re : Résolu - rsync sauvegarde des fichiers non modifiés

Pied de page des forums