Forum Linux.général Quelques explications sur rsync.

Posté par  (site web personnel) .
Étiquettes : aucune
0
5
fév.
2007
Bonjour,

J'ai une question concernant le comportement de rsync:

Quand je lance la commande suivante:
./rsync-2.6.9 --stats -a --delete --progress backup@fh::sauvegardes /mnt/externalDisk/sauvegardes

Les resultats obtenus après la première exécution sont compréhensibles: récupération de tous les fichiers dans leur intégralité.

Par contre pour les exécutions suivantes, j'obtiens ça:

receiving file list ...
3 files to consider
Outlook.pst
457131008 100% 5.99MB/s 0:01:12 (xfer#1, to-check=1/3)
read errors mapping "ation Data/Microsoft/Outlook/Outlook.pst" (in sauvegardes): (13) Permission denied

Number of files: 3
Number of files transferred: 1
Total file size: 457131553 bytes
Total transferred file size: 457131008 bytes
Literal data: 4104192 bytes
Matched data: 453026816 bytes
File list size: 105
Total bytes sent: 149831
Total bytes received: 4190042

sent 149831 bytes received 4190042 bytes 45443.70 bytes/sec
total size is 457131553 speedup is 105.33


Ma déduction, c'est que rsync télecharge le fichier complètement pour le comparer avec la version locale et retélécharger les blocs qui ont été modifiés ???

Quelqu'un peut m'expliquer la logique de ce comportement ( ou bien me dire "mais non ballot, t'as rien compris" et me fournir une explication conséquente ), ce serait très sympa !

L'objectif de l'exercice étant la mise en place d'une sauvegarde externe, via une pauvre connexion internet ( donc upload en carton ). Donc l'upload à chaque fois de l'intégralité du pst de mes utilisateurs n'est pas une option.

( Malheureusement ), le remplacement d'Outlook n'est pas une option non plus.

Merci !

  • # .

    Posté par  . Évalué à 2.


    Total file size: 457131553 bytes
    Total transferred file size: 457131008 bytes


    La taille transférée est plus petite que la taille du fichier, donc ton hypothèse ne tient pas.

    Pourquoi utilises-tu --delete ?

  • # "mais non ballot, t'as rien compris"

    Posté par  (site web personnel) . Évalué à 4.

    Mais non, il ne telecharge pas pour comparer les blocs : le principe, c'est qu'il fait des sommes de hashage localement, il lance un processus à distance qui fait les sommes de hashage, et ce ne sont que ces hashs qui son transmis, comparés avant de télécharger les blocs modifiés.
    C'est la raison pour laquelle les données envoyées sont non négligeables

    Total bytes sent: 149831

    (en tout cas, c'est ce que j'ai compris du protocole, c'est certainement plus sioux, genre les blocs ne sont peut-être pas disjoints, le hash est peut-être particulier, et le processus distant a sans doute des capacités particulières)

    • [^] # Re: "mais non ballot, t'as rien compris"

      Posté par  (site web personnel) . Évalué à 1.

      Je penses effectivement pour une explication de ce goût là.

      En fait d'après mes experiences ( l'objectif étant la sauvegarde des pst des mes utilisateurs sur un site distant ), il semblerait que si on le malheur d'essayer un rsync sur un pst, avec outlook en cours de fonctionnement, ça fout le boxon.

      Du coup au prochain rsync, c'est la quasi totalité du pst qui est de nouveau récupérée. Ce qui est inacceptable, étant donné la taille des pst et le débit de la ligne.

      J'ai contourné le problème de la manière suivante:
      sur le poste windows, j'ai un bout de script perl qui vérifie si outlook est en cours de fonctionnement. Dans la négative, il lance le rsync.

      Cette solution est en cours de test.

      Merci pour vos réponses.

      Cordialement

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.