Forum Linux.général Client FTP, sauvegarde Dédibox, violation de protocoles ?!

Posté par  (site web personnel, Mastodon) .
Étiquettes : aucune
0
26
sept.
2012

Bonjour,

J'ai une dedibox pour laquelle j'ai activé la sauvegarde de 10Go proposée par Online. Le seul moyen d'y accéder est en FTP ; je ne suis pas fan mais admettons.

Je lance alors une opération de sauvegarde de la manière suivante :
ncftpput -R -u <username> -p <password> -R dedibackup-vit.online.net . <dossier_intitule_date_et_heure_du_jour>

Sachant que le dossier en question contient les fichiers à sauvegarder à une date donnée.
Sachant aussi que l'espace en question - les 10Go, ne sont actuellemetn pas du tout utilisés.

Je récupère systématiquement l'erreur suivante :
...3525d08d6e5fb8d27136e95/o/p/open_window--wide.jpg: 355.80 kB 62.19 MB/s
Protocol violation by server: blank line on control.
Remote host has closed the connection.

Une idée ? Aurais-je un fichier "corrompu" ? Est-ce un problème que vous avez déjà rencontré ? Contourné ? Comment ?

Merci d'avance de vos retours.

  • # ftpfs + rsync

    Posté par  . Évalué à 3.

    je crois que j'avais tricher quand je voulais utiliser le systeme de backup,

    1°) j'avais monté l'espace de stockage en ftpfs
    2°) je faisais du rsync entre le dossier normal et le dossier ftpfs

    avantage ? apres le premier backup rsync n'envoie que ce qui a changé

    • [^] # Re: ftpfs + rsync

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Hm… j'ai essayé avec curlftpfs, ça semble excessivement lent avec un montage via

      curlftpfs ftp://<user>:<password>@dedibackup-vit.online.net/ /tmp/backups

      La lenteur excessive serait-elle liées à une reconnexion systématique ?

      • [^] # Re: ftpfs + rsync

        Posté par  . Évalué à 2.

        il me semble que quand j'avais posé la question du debit du backup ftp
        le support technique du fournisseur m'avait dit que le backup se faisait sur un lien à 10Mbps

        bon, là ca ne semble pas le cas puisque dans tes essais precedents tu avais 69MB/s

        et pour curlftpfs, je ne sais pas comment il fonctionne,
        faudrait que je retrouve le ftpfs que j'avais utilisé.

      • [^] # Re: ftpfs + rsync

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

        Attention !

        Lorsque tu montes un ftp en local, le dossier est vu comme un dossier local. Et voila ce que fait rsync lorsqu'il traite deux dossiers locaux, extrait du man:

        -W, --whole-file
        Avec cette option, l'algorithme rsync incrémental n'est pas utilisé ; au lieu de cela, le fichier entier est envoyé tel quel. Le transfert peut être plus rapide grâce à cette option lorsque la bande passante entre les machines source et cible est plus grande que la bande passante vers le disque (en particulier lorsque le «disque» est en fait un système de fichiers sur réseau NFS). Cette option est utilisée par défaut lorsque la source et la cible sont sur la même machine.

        Du coup, tu peux utiliser --no-whole-file, mais rsync va telecharger le fichier a distance, le comparer avec le local et n'envoyer que les differences. Pas glop.

        • [^] # Re: ftpfs + rsync

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Bon finalement, voilà ce que j'ai fait :
          - j'archive tout en tar.gz (le gz est discutable ; mais c'est fait et ça marche;)
          - je pousse l'archive en one-shot via ncftpput et ça marche nickel
          - je supprime les vieilles archives en chercahnt les vieux fichiers sur un montage curlftpfs

          Ca a l'air de marcher ; faudra probablement que je creuse un peu plus à un moment.

          Merci pour votre aide et vos remarques

  • # Limite du nombre de fichiers

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

    Tu as déjà des fichiers dans ton ftp dedibackup ? Car il y a une limite à 1000 fichiers logiquement : c'est pour faire du backup, ils veulent donc que tu y places tes fichiers dans des archives.

Suivre le flux des commentaires

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