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 :
Code:
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…