[mdidish]

ok merci.
J'essaye de faire un retour pour Windows dès que j'ai du temps.

[Tazintosh]

Je n'ai pas testé, mais pas sûr que cela soit possible étant donné que la manière de "splitter" (segmenter) diffère.
Par ailleurs, je rencontre des problèmes liés aux splits sur lesquels on a pas encore réussi à mettre le doigt (sur le github de ftpcloudfs).
Ma seule parade pour l'instant a été de régler la taille des segments à :

split-large-files = 5000

au lieu de 100 (MB) comme sur la capture de mon article.

[mdidish]

Ok merci pour la précision.

Avec ta méthode, est-ce que tu peux utiliser une sauvegarde qui a été uploadée via le client de hubiC et désormais la gérer par FTP avec ta méthode, ou est-ce qu'il fait tout reuploader la première fois?

[Tazintosh]

La vitesse en download est excellente aussi, j'ai effectivement déjà atteints les 90, 100Mo/s
Cependant, elle sera limitée, voire très faible, pour les exactes même raisons évoquées pour l'upload (dizaines de milliers de petits fichiers, etc.)

[mdidish]

Encore une question, concernant cette fois ci le download : qu'en est-il avec ta solution ? Le résultat est-il le même qu'en upload ?
Lorsque j'essaye de récupérer une sauvegarde, que ce soit par le logiciel hubiC (donc en récupérant toute la sauvegarde), ou par l'interface web (par exemple pour né récupérer qu'un sous répertoire), j'ai des pic à 10Mo/sec, mais surtout des pauses systématiques pouvant aller jusqu'à 10 minutes entre chaque fichier, ce qui ralentit considérablement le processus (j'ai une connexion fibre 1Gb/sec, sur Google Drive je télécharge parfois à >100Mo/sec)

[Tazintosh]

Je suis convaincu, et nombreux de mes tests ont pu le montrer, que la partie logiciel client est responsable d'énormément de problèmes (vitesse, stabilité, etc.)
D'un autre côté, ça ne semble pas rose côté "serveur" non plus.

Par exemple, que ce soit avec le client officiel, la webapp ou n'importe quelle solution tierce que j'ai testé (y compris la solution que j'utilise), le renommage d'un dossier est si long que l'on ne peut rester serein… Un jour, j'ai réuploadé l'intégralité d'un dossier de 20GB et l'opération a été largement plus rapide que son renommage en ligne !!!

Le même problème se pose pour la vitesse suppression, c'est catastrophique.

Idem dès qu'un dossier contient plus de 10 000 fichiers au même niveau d'arborescence (limitation de listing à 10000), du coup, ça pose d'énormes problèmes pour faire des synchro etc.).

Là je suis contraint d'effacer via mon client FTP un dossier de "segments" (splits) généré par un backup officiel de l'appli lorsque je la testais. Comme elle a un bug et que je ne peux plus effacer mon backup via l'application officielle (qui cela étant n'est pas plus rapide), je dois utiliser des solutions tierces. Ce dossier contient peut-être 250 000 fichiers à sa racine. Demander son effacement relève du délire. Ça fait deux jours que j'y suis…, moins de 8% ont été réalisés d'après mes estimations.

Enfin, comme je le disais dans mon post initial, l'upload de structures extrêmement complexes comme une Bibliothèque Photos.app, etc. qui contient des milliers de sous-dossiers à plusieurs niveaux, vignettes de photos, etc. est, sur la base de mes expériences en tout cas, inenvisageable. Sur ce test, j'ai mis entre 1,5 et 2 semaines d'upload pour une bibliothèque de 112GB, alors que pour des structures de données plus classiques (un dossier avec quelques bons gros fichiers vidéos ou photos raw), je mets en ligne ≈2TB en 24h !!! (uniquement avec ma solution).

[mdidish]

Effectivement pas d'étape insurmontable.
J'essaye dès que j'ai un peu de temps.

Si j'ai bien compris le principe, cela veut dire que les très nombreuses erreurs de mise à jour des sauvegardes (time out, scan qui tourne en boucle, error 500 internat server, 502 bad gateway, ...) seraient dues à un problème logiciel et non de serveur?

[Tazintosh]

Bonsoir mdidish,
Je n'ai jamais fait le test sous Windows, mais je ne vois aucune raison qui ferait que l'expérience puisse changer (au delà du client FTP utilisé). Mettre en place un serveur https pour la passerelle, c'est faisable de manière identique. Mettre en place ftpcloudfs, c'est faisable non ? Et puis enfin, il reste plus qu'à avoir un client FTP. À mon avis, ça devrait rouler sans problème

[mdidish]

Bonjour
Merci pour ce post et les détails présents sur ton site. As-tu une expérience similaire sous Windows ?

[CM63]

Ok, merci pour ta réponse. Si je comprends bien tu utilises encore Hubic comme solution de stockage, mais en utilisant un autre processus de upload/download que celui proposé par OVH.
Ok, personnellement je ne fais plus confiance à Hubic, ni pour le processus de upload/download, ni pour le stockage (ni pour la synchro, mais ça on est d'accord).
J'utilise fuse mais sur d'autres Clouds que Hubic. Avec fuse , et d'autres composants , je peux "monter" le Cloud sur mon PC. Ce n'est pas de la synchro (les fichiers ne sont pas répliqués) mais ce n'est pas non plus du simple upload/download depuis interface web : c'est quand même un peu plus rapide (je suis en train de tester).

Une telle solution existe d'ailleurs pour hubic : Hubicfuse, mais encore une fois pour moi Hubic c'est out, tous services confondus.

[Tazintosh]

Salut CM63,
Je fais une croix à nouveau sur l'application client —officielle— de hubiC. Pas (encore) sur le produit*
Et par "ma solution" donc, je ne parle pas de l'option de backup offerte par hubiC (qui équivaudrait donc à utiliser leur client). Non non, je parle bien d'une solution tierce, qui vise à utiliser une passerelle pour l'authentification (hubic2swiftgate) et un proxy ftp (ftpcloudfs). Ensembles, ces deux éléments (+ un client FTP) permettent de se connecter à son stockage hubiC et donc sauvegarder des données sans utiliser la moindre application officielle.
C'est plus rapide, plus stable, plus efficace.

[CM63]

Bonjour,

Euh… Faîtes de hubiC une solution de "backup" » dont une image. Clique ! Faut que je les fasse clignoter ??? (À mon avis, tu as lu mon post un peu rapidement ).
Par ailleurs, j'indique clairement que je ne parle pas de "synchro" dans ce post.

Je l'ai lu avec attention. J'avais compris que tu ne conseillais pas d'utiliser la synchro. Mais je n'avais pas compris que tu conseillais d'utiliser la solution de backup de Hubic (je n'ai pas compris pourquoi tu appelais "ma solution" en fait la solution de backup de Hubic.)

Sutout qu'en lisant ceci :

hubiC version officielle, c'est à nouveau fini pour moi. Je testerai dans un an et demi… si je suis encore client… car sincèrement, sans être en mesure de faire TOUS les backups que je souhaite et devant tant de lenteur face à la résolutions des problèmes, l'intérêt se fait nettement moindre. Les problèmes sont-ils vraiment résolus ? C'est la question, car il y a un manque de transparence et de support total.

D'ailleurs, hier soir tard, j'ai lancé la suppression du backup

On avais (enfin j'avais) quand même l'impression que tu faisais une croix aussi sur les backups Hubic.

Ok, donc ma question est sans objet.

[Tazintosh]

Bonjour, malgré l'intérêt de tes essais, je trouve déontologiquement un peu limite, sur le forum d'un fournisseur, de faire des liens vers des concurrents ou des autopublicités (quel que soit leur intérêt et quelles que soient les insuffisances du fournisseur).

Bonjour jbra.
Pouvez-vous m'indiquer, sur —ce— post, où est-ce que je fais un lien vers des concurrents ? D'autant plus étonnant, d'autant que —si mon article était lu—, il en ressort que je recommande hubiC pour faire ses backups (mais pas ses solutions logicielles officielles). La nuance est de taille.
Par ailleurs, en ce qui concerne l'autopublicité, j'ai un peu du mal à suivre… L'autopublicité de quoi ? De mon travail de photographe ? En passant des heures et semaines de tests sur un outil de backup ? Amusant…
Au pire, si je fais de la publicité, c'est justement celle d'hubiC. Parce que depuis 2014, la moyenne de 1000 visites par mois sur mon article dédié à hubiC n'est pas vraiment générée par ce forum, mais par le référencement naturel et les partages.
L'administration de ce forum (ainsi que Octave lui même ou Vincent Cassé sur Twitter qui avaient relayés mon article), ne m'a jamais interpelé à ce niveau.
Toute lecture de l'article permet de voir que ma solution utilise de fait leur produit hubiC.
Du coup, votre remarque gratuite et facile, mais peu surprenante, m'échappe…
Fort heureusement, encore hier soir à travers un nouvel e-mail reçu via mon site, les gens savent en général apprécier le travail réalisé pour la communauté et le font gentiment savoir.
Cordialement.

[jbra]

Bonjour, malgré l'intérêt de tes essais, je trouve déontologiquement un peu limite, sur le forum d'un fournisseur, de faire des liens vers des concurrents ou des autopublicités (quel que soit leur intérêt et quelles que soient les insuffisances du fournisseur).

[Tazintosh]

Bonjour,
Peux-tu nous décrire la solution adoptée dans ce que tu appelles "ma solution", ainsi que le service utilisé, si ce n'est OVH-Hubic?

Euh… c'est un peu toute la première partie de mon post, il y a trois liens « Faîtes de hubiC une solution de "backup" » dont une image. Clique ! Faut que je les fasse clignoter ??? (À mon avis, tu as lu mon post un peu rapidement ).
Par ailleurs, j'indique clairement que je ne parle pas de "synchro" dans ce post.

[CM63]

Bonjour,

Merci Tazintosh pour ces infos. Peux-tu nous décrire la solution adoptée dans ce que tu appelles "ma solution", ainsi que le service utilisé, si ce n'est OVH-Hubic?

Merci.

Personellement, j'ai renoncé à la synchro, je fais des backups à la main, je les crypte et je les envoie sur Mega et, en 2ième sauvegarde , sur deux comptes Google Drive.
Mais bon j'y passe ma jeunesse (enfin, façon de parler, car elle est loin ).

[Tazintosh]

En conclusion, 1 an et 9 mois après mes premiers tests poussés, je dois à nouveau m'en remettre au fait que le client officiel Mac n'est pas une solution stable et efficace sur laquelle on peut se reposer quant à la réalisation de nos backups et très franchement et sincèrement, j'aurais aimé !
hubiC version officielle, c'est à nouveau fini pour moi. Je testerai dans un an et demi… si je suis encore client… car sincèrement, sans être en mesure de faire TOUS les backups que je souhaite et devant tant de lenteur face à la résolutions des problèmes, l'intérêt se fait nettement moindre. Les problèmes sont-ils vraiment résolus ? C'est la question, car il y a un manque de transparence et de support total.

D'ailleurs, hier soir tard, j'ai lancé la suppression du backup de test (impossible à supprimer cf. ce que je disais juste avant) avec mon client.
Cette opération, quel que soit le client, c'est terriblement lent, ça n'a donc toujours pas fini (c'est comme le déplacement ou le renommage d'un dossier, là on est en plein dans la farce.
J'ai aussi relancé l'upload sur mon client. Il est à 23,69Mo/s, 870GB sont déjà passés… ça ça marche.

[Tazintosh]

Bonjour à tous.

Le 28 avril dernier, deux de mes topics ont été effacés sur ce forum, visiblement lors d'une opération de suppression de spams faite avec peu de soin. Depuis, le support technique a fait preuve d'un silence total vis-à-vis des e-mails de notifications que j'ai envoyé à l'administration du forum et mes topics, ainsi que tous les échanges avec vous qu'ils contenaient n'ont pas non plus été restaurés…
Personnellement, je trouve tout à fait limite qu'une société comme OVH soit incapable de faire preuve de professionnalisme vis-à-vis de ce genre de problème ; d'autant que, plus cocasse encore, nous sommes sur le forum d'hubiC —LA— solution de backup de nos données… Question mauvaise image, c'est un sans faute. Paroxysme de la chose, c'est sur la cache de Google que j'ai pu récupérer une copie de mes posts (malheureusement, pas les échanges les plus récent qu'ils contenaient).

Je crée donc ici un nouveau topic, qui sera une fusion de mes deux précédents.

Tout d'abord, je vous présente le résultat d'une semaine intensive de tests + 2 semaines d'utilisation + 4 jours de rédaction :
Faites de hubiC une solution de “backup” !
Cet article propose une réponse pour transformer hubiC en une solution fiable de sauvegarde en ligne, à travers un tutoriel précis et une description des différences entre « synchronisation » et « backup », leurs atouts, leurs inconvénients, etc.
J'attire votre attention sur le fait que cet article a été publié initialement en septembre 2014. Certaines données ont changées (notamment les tarifications), mais la solution fonctionne toujours et je suis en ce moment même en train de l'utiliser. J'espère pouvoir y apporter une mise à jour, mais le temps me manque.

https://farm6.staticflickr.com/5564/...ddac71d9_c.jpg
Faites de hubiC une solution de “backup” !

Ensuite, j'aimerais vous présenter un bilan de ma tentative de réutilisation du client Mac officiel (j'ai souhaité lui redonner une chance), un an et neuf mois après son abandon lors de mon article.
Voici donc après plusieurs semaines d'utilisation, le nouveau bilan. Notez que je ne vais parler ici que de la partie "backup" du client, la synchronisation étant purement et simplement désactivée chez moi (inutile de dire pourquoi…).

Après avoir installé le client sur mon serveur (aucune trace physique de toute installation précédente), j'ai sélectionné un répertoire de ≈ 2TB pour en lancer le backup.

Débits :
L'observation du débit moyen maximum est de 2Mo/s. Donnée à mettre en comparaison avec les 26Mo/s presque constants de mon débit, observés en utilisant ma solution (je suis sur ligne fibre, notez que 2TB, c'est ≈ 24h). On est donc loin, très loin de ce à quoi je me suis habitué. Je contacte donc Vcasse sur Twitter (toujours aussi gentil et disponible) et lui expose le problème. Il me propose alors d'éditer (j'ai totalement oublié) le fichier de configuration du client pour que ce dernier gère davantage de connexions simultanées (3 par défaut semble t-il). Ainsi modifié pour 20 connexions, je relance le client hubiC. Les transferts reprennent, il y en a bien 20 et le débit flirte difficilement et tout tremblant comme lors d'un premier rendez-vous, avec les 10Mo/s avec, j'insiste, des passages de plusieurs jours (oui oui), à quelque ko/s (je n'exagère pas).
Ça a été notamment le cas lorsque j'ai réalisé le backup de la bibliothèque Photos(.app) d'un ami (≈112GB). Dossier constitué de plusieurs milliers de petits fichiers de très faible taille (structure standard, rien d'anormal) qui sont tout simplement ingérables sur hubiC tant la solution est lente. Notez que ceci est aussi vrai avec ma solution. Du coup, sur ce genre de données, il est totalement illusoire d'espérer faire vos backups, je pèse mes mots, et j'aimerais que l'on me prouve l'inverse dans des délais inférieurs aux semaines et mois alors que je suis en fibre, comme dit précédemment.

Quoiqu'il en soit et pour revenir à la différence de vitesse entre ma solution et le client officiel, vous allez donc dire que je réalise le double de débit avec 2x moins de connections… et bien non !!! Les faits, après plusieurs semaines d'utilisation, ont montrés que la différence de débit s'élève à plus de 9 (avec 20 connexions simultanées réglées sur le client officiel) !!! Sur une ligne identique, le client officiel Mac hubiC (trafiqué pour 20 connexions au lieu de 3) est donc 10x plus lent que son pendant ftpcloudfs (utilisé pour ma solution) !!!

CPU :
Je remarque par ailleurs que mon Mac mini Server, d'habitude fort inaudible, a commencé à souffler plus que de raison. Petit coup d'œil aux processus pour remarquer que le client s'accapare entre 70 et 160% de CPU avec des pointes à 200% du i7 3GHz. Lors de l'utilisation du service avec ma solution, Python se contente en moyenne de 30% avec des pointes rares et ultra épisodiques à plus de 100%…

Stabilité :
Pour que tout soit complet et malgré la vitesse totalement décourageante, j'ai donc laissé tourner mes transferts de test.
Pof, résultat identique à ce que j'avais connu auparavant : le client a quitté… il a quitté sans arrêt au fil des semaines, de manière totalement aléatoire… Comment donc imaginer une seconde faire confiance à un outil de backup (ou de synchronisation), si ce dernier au delà du simple fait de bien faire son travail, n'est même pas capable de rester lancé ?
Comble de la désillusion, le client officiel hubiC a de nombreuses fois indiqué que le backup était complet, à 113Go, puis 200 et des brouettes, puis xxx, bref vous voyez le schéma… (je rappelle que mon dossier de test faisait 2TB, puis est monté à 2,5TB). Oui oui, imaginez la scène : un matin, vous jetez un œil à la progression et il vous dit très sereinement et droit dans ses bottes "j'ai fini, votre backup, il fait 113Go". Et vous, vous vous collez deux claques histoire d'être bien sûr d'être réveillé et d'avoir bien vu la taille de votre dossier sur le Finder : 2TB…
Après deux ou trois semaines (franchement je ne sais plus et on est plus à 6mois prêts avec hubiC officiel), j'ai enfin eu un backup complet, enfin je l'espère. Car —voilà— un problème majeur. Après tant de temps, tant d'erreurs, tant de bugs, comment faire confiance ? D'ailleurs un nouveau problème arrive alors. J'ai réglé mes préférences de backup pour réaliser une mise à jour journalière et voilà que… ben je crois que ça n'a jamais marché… Le client m'annonçait « découverte des changements » et tourna ainsi pendant des jours, sans jamais rien mettre en ligne ni s'arrêter (à ce titre comme pour d'autres problèmes, des utilisateurs ont déjà remonté le problème sur le forum, sans réponse).
La lenteur est telle que le client semble incapable de tenir à jour de gros backups. Je ne sais même pas comment ils gèrent les timeout & co côté serveurs… Et j'en suis venu à me demander : « puisqu'il est incapable de découvrir les changements en moins de 24h et que je demande un check tous les jours, est-ce que ma requête annule la précédente ? Auquel cas, jamais je n'en finirai !!! »

Stabilité (bis), ergonomie et interface utilisateur :
Le client en lui même n'a pas beaucoup évolué non plus (ont parle bien depuis mon test initial de 2014 hein*!!!)
Il est notamment impossible via l'interface de supprimer un backup qui n'a pas encore fini. Et voilà pourquoi c'est embêtant : vous lancez un backup de 100GB (je prends même pas les 2TB de mon test et me mets plus à la place d'un utilisateur Lambda avec une ligne ADSL). Pour lui ce transfert va déjà représenter probablement plusieurs semaines. Voilà, le backup est lancé, mais zut, finalement, c'est pas ce dossier qu'il voulait sauvegarder ! Ben zut, impossible de stopper et d'annuler sur backup ! Il faut attendre qu'il soit terminé (il y a même un message d'alerte pour vous le dire). Vous pouvez mettre en pause de transfert, le reprendre, mais pas le supprimer. Même en relançant le client. Ce dernier va immédiatement reprendre ce qui était en cours, donc votre backup non souhaité, et donc vous empêcher de le supprimer…
Alors grâce à ma solution, je peux voir les dossiers d'un tel backup à la racine du répertoire hubiC (chose qu'il est impossible de faire avec les solutions officielles). Si je les supprime, le backup dans l'interface du client officiel va disparaitre et le problème sera réglé, mais notre utilisateur Lambda, lui, il est bien embêté !
Notez enfin qu'un bug (parmi d'autres), systématiquement reproductible existe dans le client :
Lorsque l'on clique sur le signe "—" (moins) pour supprimer un backup non terminé, le message d'alerte survient (pourquoi ne pas simplement griser le bouton dans le backup est en cours ?). Jusque là, pas de bug. Mais maintenant, je quitte le client, le relance, et backup reprend, et je clique à nouveau sur le signe "—" : BAM, l'application crashe et quitte directement.

Petite touche esthétique, le client va aussi embellir l'aspect de votre console avec des entrées ultra nombreuses telles que :

18/04/2016 12:32:43,782 Finder[4961]: osascript(20123) System Policy: deny scripting-addition-send 'HUBC'/'load'

Limite des 10000 caractères atteinte…