Bonjour à tous,
Voila le problème du jour, y'a rsync qui oublie de synchroniser/copier juste quelques fichiers.
L1. e topo: 2 raspberrys qui font un montage samba sur 2 NAS (1 chacun): 1 Nas source et l'autre destination. La synchronisation se fait sur ~820 000 fichiers qui représentent plus de 700 GB de data. Bein ça se passe super bien sauf pour une centaine qui sont tous dans le même répertoire. Sachant que ce répertoire contient plus de 300 fichiers et que pour les autres ça se passe très bien.
Le problème exacte, c'est que les fichiers sont absents du répertoire destination.
Voici les options pour rsync:rsync -ahz --no-o --no-g --no-p --del --ignore-errors --force --stats --log-file=$FILE_LOG --exclude-from $EXCLUDE_FILE -e "ssh -p $SSSERVER_PORT" monLogin@raspSSServer:$DIR_SRC/ $DIR_DEST
Au niveau des droits des fichiers absents, ils sont en -rwxr-xr-x et ne sont pas vides.
Le répertoire qui les contient a les droits suivants: drwxr-xr-x.
Si quelqu'un a une idée … je suis preneur.
Merci
# La suite
Posté par SuperBebert . Évalué à 1.
Après y avoir passé le week end pour extraire la liste des fichiers, gratté un peu partout et même poster le message originel, il se pourrait que le problème vienne du fait que les NAS soient accessibles par Samba et peut-être qu'il y en aurait un qui ne serait pas case sensitive.
Je vous tiens au courant enfin ceux que ça intéresse.
[^] # Re: La suite
Posté par Axone . Évalué à 1.
Il y a quelques temps déjà, je faisais du rsync sur du samba. Et bien c'était moins rapide et moins efficace (timestamp non identique a travers samba par exemple, donc resynchro).
Du coup, j'ai refais du rsync sur ssh, simple, rapide et efficace. Après, est-ce que le chiffrement ssh sur les raspbery ne va pas être pénalisant…
Fais le test si tu peux.
[^] # Re: La suite
Posté par lolop (site web personnel) . Évalué à 2.
Si c'est tout en local, il peut aussi faire du rsync avec un serveur rsync sur le RPi, ça passera en clair.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: La suite
Posté par Bruno Raoult (site web personnel) . Évalué à 1.
C'est déjà ce qu'il fait (le rsync est sur ssh d'après la ligne de commande). Donc, si j'ai bien compris, le schéma actuel est:
SMB-1 <-- (montage smb) --> RPI-1 <-- (rsync/ssh) --> RPI-2 <-- (montage smb) --> SMB-2
On peut supposer que ni le SMB-1 ni le SMB-2 (source et destination du backup) ne supportent rsync/ssh, sinon il n'y aurait pas les 2 montages. Sans doute des "NAS" simples, avec des serveurs Samba pas vraiment contrôlables (sinon le problème de minuscules/majuscules serait réglé).
De même, je supposerais que RPI-1 et RPI-2 sont distants (pas sur le même réseau local), sinon 1) les deux sambas seraient montés sur un seul RPI, pour éviter une étape, et 2) la compression ne serait pas activée (trop pénalisant pour les Rpi sur un réseau rapide). Par exemple le soucis se poserait entre deux Freebox, si quelqu'un les utilisait comme espace de stockage d'un réseau local, les 2 box étant backupées l'une sur l'autre via des RPI. Ou un truc comme ça :)
[^] # Re: La suite
Posté par Bruno Raoult (site web personnel) . Évalué à 1.
Oui, ça m'intéresse. J'avais eu le soucis (minuscules/majuscules) sur un serveur samba, et j'avais fini par supprimer toutes les "collisions" côté client…
[^] # Re: La suite
Posté par NeoX . Évalué à 2.
ou qu'il y a un caractere special dans un nom de dossier,
j'ai eu des cas similaire avec des dossiers/fichiers avec des accents (en vrai français dans le dossier)
sauf que rsync avait du mal avec les accents, les cedilles (ç par ex)
# A vérifier :
Posté par Christophe B. (site web personnel) . Évalué à 1.
Sinon : faire un cp -r du répertoire et renommer l'ancien cela peut être un cochonnerie sur un disque
[^] # Re: A vérifier :
Posté par Bruno Raoult (site web personnel) . Évalué à 1.
Que veut dire caractère non affichable, pour toi?
[^] # Re: A vérifier :
Posté par Christophe B. (site web personnel) . Évalué à 1.
Regardes le code ascii cela va de 0 à 255
Espace No 32 est le premier caractère affichable
les 31 premiers sont des caractères non affichables comme Line Feed / Return / Tab / Form Feed
mais aussi End Of Text etc … on les appelles aussi caractères de controles.
Quand tu fait CTRL-D sous unix pour fermer un fichier cela correspond à End Of Text, la touche CTRL permets d'accéder à ces caractères de "contrôles" CTRL-A = Le 1er CTRL-B = Le 2 eme etc…
Dans les pièges tu as Backspace (retour arriere) delete si dans ton nom de fichier tu as backspace ou delete tu ne les verras pas
Mais tu peu avoir plein d'autres trucs maintenant vu qu'on est en Unicode :)
[^] # Re: A vérifier :
Posté par Bruno Raoult (site web personnel) . Évalué à 1.
Justement, je pensais spécifiquement à unicode, et UTF en particulier. Ma question était plutôt "quels caractères non affichables" poseraient un soucis particulier? Pour moi, ça n'a rien à voir. Toutefois, certains caractères seront interdits sur CIFS (et peut-être plus, selon le système de fichiers sous jacent côté serveur). Les noms de fichiers trop longs pourront aussi poser un soucis.
Le fait que rsync pose un soucis n'est en rien lié au fait d'avoir des caractères "affichables" ou non. Par exemple, le backspace (H) que tu cites est tout à fait valide sur beaucoup de systèmes de fichiers. Selon le terminal que tu utilises, il pourra être affiché comme un backspace (donc en supprimant le caractère précédent), ou comme un "?", etc…
Exemple, sur une freebox montée par CIFS, avec un terminal "xfce4-terminal":
br@lorien:/mnt/freebox/www$ touch aHz
br@lorien:/mnt/freebox/www$ ls -l
total 0
-rw-rw-r-- 1 br br 0 Apr 5 11:56 a?z
drwxrwxr-x 4 br br 0 Mar 30 11:01 Books
[^] # Re: A vérifier :
Posté par Bruno Raoult (site web personnel) . Évalué à 1.
Je ne peux pas corriger mon post :-(
Il fallait lire ctrl-H et "touch actrl-Hz" (taper "a ctrl-v ctrl-h z" sans les espaces sous bash, le caractère d'échappement ctrl-v peut-être différent selon les shells).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.