Forum Programmation.shell fichier superieur à 2GO ! probleme de script pour backup FTP

Posté par  .
Étiquettes : aucune
0
28
sept.
2006
Salut,

Voila j'ai fait rapidement un script shell pour envoyer par FTP une archive de 8go sur un NAS.



/usr/bin/ftp -i -n -d -v <<FTPCMD

open $FTPSERVER

user $FTPLOGIN $FTPPASSWORD

put tmp_$ARCHIVENAME-$DATE.tar

rename tmp_$ARCHIVENAME-$DATE.tar ARCHIVENAME-$DATE.tar

bye

FTPCMD



mon probleme :

Lorsque je test mon script avec des petit s(+/- 1Go) fichiers pas de probleme. Mais avec mon archive de 8 GO cela ne marche pas.
mon client Ftp se coupe à la fin de l'upload (qu'il reussit à 100%) pour cause de timeout. Alors pour lui impossible de finir corectement son traviail. En effet d'apres les commandes que je lui ai passé il dois encore renommer le fichier sur la machine distant.

J'ai le meme probleme de timeout avec d'autre client comme Lftp ncftpput ..etc

Le serveur FTP et un IIS 6.0. J'ai essayer de regler le timeout au max max sur le serveur IIS mais pareille.

Si ma memoire est bonne FTP ouvre 2 ports sur le poste client. Un pour l'envoie des fichiers un pour les commandes. Ne faudrais t'il pas que le client ftp envoie regulierement des ping/pong sur le port de commande vers le serveur pour que celui ci maintient la connection ?

Comment faire pour automatiser cette tache FTP avec de gros fichiers ?

Merci d'avance pour vos reponses.

  • # systeme de fichier...

    Posté par  . Évalué à 1.

    si ton serveur est IIS, il est probablement sous windows.

    si ton systeme de fichier (sur le serveur) est FAT ou FAT32 il est normal de ne pas depasser la taille de 2Go par fichier car il s'agit d'une limite conceptuel du systeme de fichier.

    si ton systeme de fichier est NTFS, alors le probleme est peut-etre du coté des time out ou ailleurs

  • # NTFS ok

    Posté par  . Évalué à 1.

    Mon system de fichier est bien en NTFS donc pas de probleme sur la taile du fichier. Cela viens forcement du delais mais comment corriger le probleme ?

    • [^] # Re: NTFS ok

      Posté par  . Évalué à 1.

      peut-etre deja en faisant ton archive en tar.gz (rajoute l'option z à ta commande tar)

      ca prendrait moins de place, donc moins de temps

    • [^] # Re: NTFS ok

      Posté par  . Évalué à 1.

      Ce type de problème ne vient pas forcément du serveur FTP. N'importe quel matériel impliqué dans la connexion TCP peut être à l'origine de la coupure de la connexion.

      A la fin du transfert, qu'affiche le client FTP ?

      Il y a-t-il un routeur ou un pare-feu entre le client et le serveur FTP. Dans ce cas, cet équipement peut parfaitement (probablement) être à l'origine du soucis : le transfert des données prenant beaucoup de temps (sur la connexion dédiée aux données), il n'y a rien qui passe sur le canal de commande. Le routeur/FW détecte alors une connexion inactive et ferme la connexion.

      La solution serait peut être, comme tu l'as évoqué, de faire passer des paquets sur le canal de commande, mais là je n'ai pas de solution toute faite et je ne maîtrise pas vraiment ces questions.
      Il faudrait activer une fonctionnalité de "keep alive" sur le canal de commande, mais je ne sais pas trop comment faire (je pense que le client et/ou le serveur doit supporter cette fonctionnalité).
      De plus, le délai de keep alive défini au niveau du noyau linux est de deux heures ce qui est beaucoup trop dans ce cas. Il faut donc réduire ce délai à 10 ou 15 minutes (la valeur se trouve dans le fichier /proc/sys/net/ipv4/tcp_keepalive_time : il suffit donc de faire un :
      echo 900 > /proc/sys/net/ipv4/tcp_keepalive_time
      pour passer le délai à 15 minutes).
      Evidemment, toutes ces remarques sont données avec toutes les réserves d'usage : je ne suis pas un spécialiste de ce type de configuration et je ne sais pas ce que cela peut provoquer comme effet de bord, mais ça peu valoir le coup d'essayer.

      Sinon, tu peux toujours essayer de chercher des solutions dans tes moteurs de recherche préférés (mots clés : FTP, timeout, keepalive, ...).

      Bon courage et dis nous si tu trouves une solution.

      JJD

      • [^] # ICMP le probleme ??

        Posté par  . Évalué à 1.

        Alors j'ai desactivé completement le firewall windows 2003 server et la ca passe.
        Pourtant j'ai bien ouvert les ports FTP necessaire.
        Il me semble avoir vu passé une doc comme quoi le protocole FTP pouvais utiliser ICMP.

        Quelqu'un peut il confirmer l'utilisation d'icmp par FTP ?

        ICMP est bloqué par defaut a l'activiation du firewall sous windows 2003 server.

  • # beuh

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

    ton problème vient probablement du fait que ton client FTP n'est pas compilé avec l'option permettant le support des large files (taille et offsets de fichiers sur 64-bits).

    pour valider cette supposition, exécute ton client FTP à travers ltrace. si tu vois des "fopen" c'est que j'ai raison. si tu vois des "fopen64" c'est que c'est un autre problème.

    si j'ai raison, plains-toi à ton support si tu en as :) ou bien recompile ton client FTP avec -D_FILE_OFFSET_BITS=64.

    exemple d'utilisation de ltrace et de -D_FILE_OFFSET_BITS=64 :

    [gc@meuh /tmp] echo -e '#include <stdio.h>\nint main(){fopen("/dev/null", "r");}' > t.c
    [gc@meuh /tmp] gcc t.c
    [gc@meuh /tmp] ltrace ./a.out 2>&1| grep null
    fopen("/dev/null", "r") = 0x804a008
    [gc@meuh /tmp] gcc -D_FILE_OFFSET_BITS=64 t.c
    [gc@meuh /tmp] ltrace ./a.out 2>&1| grep null
    fopen64("/dev/null", "r") = 0x804a008

    • [^] # Re: beuh

      Posté par  . Évalué à 1.

      non pas de probleme de support pour les large files.
      probleme resolu en desactivant le firewall mais j'aimerais bien pouvoir le remettre maintenant en debloquant les options adequates.

Suivre le flux des commentaires

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