Bonjour à tous,
Hier, le service Dropbox s'est transformé en passoire, en laissant n'importe qui se connecter sans mot de passe.
Ils en font l'aveu sur leur propre blog: http://blog.dropbox.com/?p=821
On me dira peut-être que Dropbox n'est pas libre, et que par conséquent la nouvelle n'a rien à faire ici, mais comme je suppose que le nombre de moules utilisatrices du bidule est non-nul, je préfère relayer l'information.
C'est dommage, je trouvais leur système bien fait (on installe puis on ne s'occupe plus de rien), pratique et sans équivalent qui soit aussi facile à conseiller à des amis non au fait des choses de l'informatique (ou qui utilisent Windows). Ce n'est d'ailleurs pas leur premier problème de sécurité (cf http://www.webactus.net/actu/9988-securite-dropbox/).
Je n'ai jamais confié de fichiers sensibles à Dropbox, mais là c'est sûr, je les quitte...
# Déjà une cause perdue
Posté par DLFP est mort . Évalué à 5.
Ça fait un moment qu'il n'y a plus aucune raison de les prendre au sérieux : ils disaient crypter les données mais en vérité ils avaient une clé privée chez eux leur permettant de décoder les données de n'importe qui. Je suppose que personne n'avait pris la peine d'analyser leur client propriétaire avant ?
Mais tout simplement comment peut-on faire confiance à ce genre de service ?
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Déjà une cause perdue
Posté par fredix . Évalué à 10.
En même temps vu qu'ils proposent une interface web qui permet de naviguer dans ses fichiers, il est facile de deviner qu'ils doivent lire en clair nos fichiers pour le faire.
[^] # Re: Déjà une cause perdue
Posté par allcolor (site web personnel) . Évalué à 2.
Ben pourquoi ?
Ils auraient pû utiliser une clé (RSA ou AES ou ...) xorée avec le user/pass... donc oui, techniquement à un moment la clé se retrouverait en mémoire de leur serveur mais pas accessible directement comme ça (en considérant qu'il ne stocke pas le mot de passe chez eux mais juste un hash).
Mais avec un truc bien fait, ils ne devraient pas lire "en clair"... ou du moins juste décrypter le contenu le temps d'envoyer à travers l'interface web (recrypter ensuite en ssl :D).
Enfin je connaissais pas dropbox, mais je vois bien l'utilité d'un tel service.
[^] # Re: Déjà une cause perdue
Posté par TImaniac (site web personnel) . Évalué à 2.
Ce qui ne change strictement rien au problème : s'ils peuvent à un moment envoyer en clair (à travers un tuyau SSL ou non) ton document, c'est qu'il l'ont décrypté sur leur serveur, aussi temporaire soit l'utilisation d'une clé de cryptage. Donc ils peuvent tout lire.
Mais bon, suffit de comprendre ce principe élémentaire pour appliquer une action élémentaire pour résoudre le problème, de leur propre conseil d'ailleur : tu cryptes avant d'envoyer. Evidemment, c'est tout de suite moins pratique si on a pas un client qui rend cette action transparente, mais bon quand on veut la sécurité il faut parfois faire un sacrifice...
[^] # Re: Déjà une cause perdue
Posté par allcolor (site web personnel) . Évalué à 3.
Je n'ai jamais dit le contraire.
oui si ils sont malhonnête et qu'ils stockent la clé et s'en servent...
Mais dans ce que j'expose au-dessus, ils n'ont la clé qu'a partir du moment où ils ont ton pass (pas stocké chez eux). Ils pourraient bien sûr garder ton pass, ta clé etc... mais on fait le postulat qu'ils sont digne de confiance et oui le mieux est de crypter avant envoi... mais du coup c'est plus possible d'avoir ça de façon transparente à travers le web.. à moins d'une applet java côté client qui te décrypterait à la volée tes fichiers. (mais faudrait lui fournir la clé)
Donc le truc c'est un choix entre plus de sécurité et de la sécurité on va dire suffisante. Le truc que j'ai compris avec dropbox c'est que la sécu n'est même pas suffisante étant donné qu'il n'y avait qu'une seule clé et pas une par client.
Ce qui est au dessus est une protection contre un hack sur le serveur... le méchant piratin n'ayant pas ton mot de passe, ne peut avoir ta clé et donc voir tes fichiers. Mais oui le serveur lui même à un moment ou un autre à bien ton pass et ta clé et peut tout lire... mais un service honnête n'y a pas le droit. Dans la façon de faire de dropbox, si un piratin obtient leur clé, il pourra tout voir de tout le monde, c'est la pire des choses. (et ce même si dropbox est honnête)
Et encore une fois oui, mieux vaut crypter avant mais ça rend l'utilisation moins aisée.
Un service dans le genre avec accès web et cryptage/decryptage auto sur le client ça serait très bien en libre ;)
[^] # Re: Déjà une cause perdue
Posté par ploum (site web personnel, Mastodon) . Évalué à 4.
http://tahoe-lafs.org
http://www.syncany.org/
Le principe de ces projets est de considérer que le fournisseur de service n'est pas digne de confiance.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Déjà une cause perdue
Posté par DLFP est mort . Évalué à 3.
Syncany à l'air pas mal du tout, si on passe sur le fait que c'est du Java :/
Très facile à mettre en œuvre en tout cas, ça fait un remplaçant à Dropbox sans hésitation.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Déjà une cause perdue
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Il n'y a pas un site style Wiki qui permet de noter ou consulter la sécurité des sites-web ?
Genre :
- Est-ce que les mots de passes sont stockés en clair ?
- Quelles sont les limitations sur les mots de passe ou login ?
- Est-ce que les données bancaires sont conservées et si oui lesquelles ?
- Quelle est la procédure en cas de perte de mot de passe et est-elle sécurisée ?
- Est-ce que les pages sensibles sont bien servies en HTTPS ?
- ...
Et on pourrait noter les problèmes rencontrés et les évolutions positives ou négatives des mesures de sécurité.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Déjà une cause perdue
Posté par ᴼ ᴹᴬᴺᴺ . Évalué à 1.
En France au moins : http://www.cnil.fr/nc/la-cnil/actu-cnil/article/article/un-site-marchand-peut-il-conserver-mes-donnees-bancaires/
207829⁶+118453⁶=193896⁶+38790⁶+14308⁶+99043⁶+175539⁶
[^] # Re: Déjà une cause perdue
Posté par Alex . Évalué à 5.
Petite histoire perso, qui me fait douter des pratiques de certaines assos (pourtant à vocation humanitaire)
J'ai donné pendant 2 ans à une asso qui lutte contre le sida, m'étant retrouvé au chômage, j'avais stoppé mes dons.
8 mois plus tard, cette même asso me recontacte et m'annonce que si je veux recommencer à donner, un simple "oui" (donné par téléphone !) suffit et qu'ils ont encore toutes les infos pour reprendre les prélèvements.
Un peu échaudé je revérifie les papiers et ne voit nul part une autorisation pour conserver mes coordonnés bancaires, ceci dit, bonne poire, je ne les envoi pas chier et leur dit que je reprendrai les dons dans quelques mois quand ma situation sera plus assainie.
2 mois plus tard une autre association me téléphone me proposant de donner pour je ne sais plus quoi, et quelle fut ma surprise d'apprendre qu'ils ont déjà tout les papiers pour que je puisse payer, et en effet ils m'ont envoyé des papiers pré remplis avec mes coordonnées bancaires, bref il n'y avait plus qu'à signer !
Alors je ne sais pas si il y a un lien entre les 2 assos, après tout d'autres sociétés ont mon rib (edf, sfr, etc...), mais ça m'a tout de même fortement échaudé.
# Et ?
Posté par BFG . Évalué à 7.
Le problème a duré 4 heures, coté serveur. Si le client et/ou le serveur avait été libre, qu'est ce que ça aurait changé étant donné que les utilisateurs ne peuvent pas corriger les serveurs qui sont hébergés chez Dropbox, puisque l'utilisateur n'a pas de controle sur les serveurs (et non pas le code) ?
Dans ce cas là, le problème est que le service est chez un prestataire et qu'on est donc dépendant de ce qu'il a installé. Grande nouvelle.
[^] # Re: Et ?
Posté par DLFP est mort . Évalué à 9.
Ça fait un rappel utile que c'est pas parce que le site est gros ou connu qu'il n'est pas tenu par des incompétents.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Et ?
Posté par TImaniac (site web personnel) . Évalué à -2.
Aucun humain n'étant infaillible, tous les humains sont donc incompétents.
[^] # Re: Et ?
Posté par ale6 . Évalué à 0.
Mais qui t'es pour dire que les types derrière Dropbox, qui sont tous sortis du MIT, sont incompétents ?
[^] # Re: Et ?
Posté par DLFP est mort . Évalué à 1.
Je ne sais pas si tu es ironique, mais c'est justement l'objet de mon commentaire : ce n'est pas parce qu'il y a un titre pompeux ou une société connue qu'il faut faire une confiance aveugle, ce que je vois malheureusement souvent.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Et ?
Posté par ale6 . Évalué à -2.
Arrête, on parle du MIT là. Je suis parfaitement d'accord pour des gens sortant d'écoles françaises.
Un pote qui est à Centrale Lille a demandé à un de ses profs pourquoi dès qu'il y avait quelque chose d'un peu intéressant scientifiquement il était vu de façon succinte, son prof lui a répondu que de toute façon, on leur enseignait de la merde pour être des managers. C'est loin d'être le premier à me dire quelque chose comme ça, et venant de grandes écoles différentes (surtout les Centrale).
Il y a quelques années je m'étais pas mal renseigné sur le MIT, et c'est pas du tout la même philosophie de formation. Par exemple je trouve que l'approche du cours sur les équadiffs sur Open Course Ware donne plus d'intuition que celle du programme de prépa MPSI/MP. Ensuite je suis peut-être illusionné, mais c'est vraiment ce qui m'a semblé.
[^] # Re: Et ?
Posté par zebra3 . Évalué à 2.
Il n'a pas dit qu'ils étaient incompétents, mais qu'ils pouvaient l'être.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Et ?
Posté par Framasky (site web personnel) . Évalué à 1.
Ça aurait tout changé car si le serveur avait été libre, les geeks/moules auraient installé le serveur chez eux et auraient donc eu le contrôle.
Et le code aurait été sans doute plus revu que dans le cas d'un logiciel privateur et donc peut-être que la faille aurait été découverte et patchée avant qu'elle n'impacte le service.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Et ?
Posté par Littleboy . Évalué à 9.
Un peu comme la faille openssl dans Debian, patchee rapidement avant qu'elle n'impacte des milliers de serveurs?
[^] # Re: Et ?
Posté par mr_spoke . Évalué à 0.
Bravo tu appuis ton argumentaire par un exemple isolé qui date quand même maintenant de trois ans et qui est un peu hors sujet.
[^] # Re: Et ?
Posté par BFG . Évalué à 2.
Vous voulez jouer à ça ? Bien, Dropbox est un exemple isolé.
Comme ça date d'il y a 3 ans, l'exemple devient invalide ?
En quoi ?
[^] # Re: Et ?
Posté par Zenitram (site web personnel) . Évalué à 2.
C'est évident voyons!
L'un est proprio donc sujet à la critique en cas de faille énorme
L'autre est libre donc hors sujet à la critique en cas de faille énorme
Pas touche au libre qu'on te dit!
[^] # Re: Et ?
Posté par pasScott pasForstall . Évalué à -2.
meuh non.
T'as rien compris.
C'est la faute de l'utilisateur qu'avait qu'a patcher le code s'il est victime d'une faille de securite.
Comme tu peux pas faire ca avec le libre, c'est bien la preuve irrefutable que le libre est superieur, non?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Et ?
Posté par Littleboy . Évalué à 3.
Parfaitement, d'ailleurs les bugs de securite qui restent des dizaines d'annees ca peut pas exister dans le libre, grace aux revues de code regulieres et aux suites de tests exhaustives.
N'est ce pas...
[^] # Re: Et ?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
J'aime bien aussi celle-ci :
[http://it.slashdot.org/story/11/06/20/1934231/SSLTLS-Vulnerability-Widely-Unpatched]
[^] # Re: Et ?
Posté par 태 (site web personnel) . Évalué à -5.
S'agit-il d'un sarcasme ?
Si oui, qui a été "impacté" par ladite faille ? Qui a eu une intrusion à cause d'elle ? La faille a été trouvée, jugée dangereuse et corrigée à ma connaissance sans avoir été exploitée. Chez dropbox, on ne découvre les failles qu'après qu'elles aient été exploitées...
Si non, faites comme si je n'avais rien dit.
[^] # Re: Et ?
Posté par RB . Évalué à 6.
Pas exploitée, tu plaisantes ? Ni une ni deux il y avait des bots qui cherchaient des comptes ssh root avec clé vulnérable. Je sais de quoi je parle, un de mes serveurs avait justement un accès root avec un clé défectueuse et des intrus s'étaient infiltrés (à partir de ce compte ils propagaient l'attaque plus loin).
[^] # Re: Et ?
Posté par 태 (site web personnel) . Évalué à 4.
Mea culpa, j'ai écrit "sans" au lieu de "avant".
Ah oui ?
[^] # Re: Et ?
Posté par pasScott pasForstall . Évalué à 1.
D'ailleurs, la faille a ete trouvee par revue de code attentive.
Ou serait ce parce qu'il se trouve que quelqu'un a par hasard eu une collision en generant ses cles, a trouve ca bizarre et a investigue un peu plus loin?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
# KISS
Posté par Vlobulle . Évalué à 6.
Confiez à DropBox la charge de synchroniser vos fichiers. C'est son boulot et il le fait très bien.
Par contre utilisez un programme dédié pour les sécuriser. Les volumes TrueCrypt se marient très bien avec DropBox.
[^] # Re: KISS
Posté par Bastien Leblanc (site web personnel) . Évalué à 2.
Tout à fait!
Il y a aussi encfs (BoxCryptor pour ceux qui sont sous Windows, qui veulent pas s’embêter)
[^] # Re: KISS
Posté par fredix . Évalué à 4.
L'avantage d'encfs sur truecrypt c'est que chaque fichier est chiffré indépendamment et donc Dropbox n'est pas en train de constamment envoyer des modifs contrairement à un volume truecrypt où tout es dans un seul fichier qui est modifié en permanence.
Sinon AeroFS sera à mon avis une meilleure alternative que Dropbox, car il permet de synchroniser uniquement vers tous ses clients et sur option vers leurs serveurs.
[^] # Re: KISS
Posté par nomorsad . Évalué à 1.
apres quelques tests, il me semble que Dropbox n'envoie que les parties modifées du fichier crypté.
Testé sur un fichier truecrypt de 50Mo : la modification d'un ficher à l'intérieur est quasi instantanné en synchro.
[^] # Re: KISS
Posté par BFG . Évalué à 4.
Les API de surveillance du système de fichiers (inotify, etc.) ne permettent pas de savoir quelle partie d'un fichier a changé. Même si Dropbox utilise la librsync, travaille par blocs, etc., il faudra quand même qu'il calcule la somme de contrôle de toutes les parties du volume Truecrypt.
Alors, relire intégralement 50Mo (ou plus) pour la plus petite modification d'un petit fichier encapsulé dans Truecrypt, c'est inefficace.
[^] # Re: KISS
Posté par Vlobulle . Évalué à -4.
On perd sans doute, mais le temps de calcul du hash d'un fichier de quelques go est complètement négligeable avec les machines actuelles.
C'est vrai que c'est un peu emmerdant d'attendre d'avoir fermé le volume TC avant la synchro par contre.
[^] # Re: KISS
Posté par BFG . Évalué à 9.
Rassurez-moi, vous n'êtes pas développeur ? J'espère sincèrement que vous n'écrivez aucun logiciel, et que vous ne participez à aucun choix technique d'un quelconque logiciel, parce qu'avec ce genre de réflexion, je n'ose pas imaginer la qualité des dits logiciels...
[^] # Re: KISS
Posté par Vlobulle . Évalué à -1.
Ma remarque était formulée de manière trop générale, je voulais juste parler du fonctionnement de DropBox. Mes excuses si ça a été mal formulé.
Donc, je reformule : oui on a un coût qui explose en procédant de la sorte, j'en suis conscient, mais sur de gros volumes TC et sur une machine récente, ça passe de manière transparente. Je ne connais pas d'autre solution au problème (qui est, je rappelle, de combiner DB avec son propre chiffrement tout en restant portable). Si vous en avez une (déjà développée, pas théorique), je suis bien évidemment preneur. Et je ne serai pas le seul, beaucoup d'utilisateurs de DB utilisent TC actuellement.
Ou alors ce n'était pas ça la remarque ?
[^] # Re: KISS
Posté par BFG . Évalué à 1.
Et bien avec vos demandes, actuellement, il n'y a pas de solution. (Je ne tiens pas compte de votre proposition d'utiliser Truecrypt car c'est complètement farfelu (la longévité de vos disques doit être d'ailleurs bien diminuée grâce à ça)). Dropbox ne sait pas chiffrer les fichiers avant de les envoyer, et il n'existe pas actuellement de chiffrement de fichiers à la volée portable.
Porter encfs pour les OS qui ne l'ont pas, ou utiliser autre chose que Dropbox serait une solution.
[^] # Re: KISS
Posté par Vlobulle . Évalué à -2.
Peut-être que vous n'avez pas compris que le hash n'est recalculé qu'à la fermeture du volume TC, et non pas en permanence à chaque modification ?
J'ouvre mon volume une ou deux fois par jour, au grand maximum.
Ou alors on va m'expliquer que lire deux gigaoctets et utiliser deux minutes de temps processeur (comme indiqué plus bas) par jour, c'est quelque chose de monstrueux ? Le moindre lancement d'un jeu vidéo demande tout de même beaucoup plus...
Mais encore une fois, je suis bien conscient qu'on pourrait arriver à un résultat équivalent pour un coût bien moindre si les outils adaptés existaient.
[^] # Re: KISS
Posté par BFG . Évalué à 4.
Effectivement je n'avais pas compris, mais du coup ce n'est pas utilisation en synchronisation (ou au moins quasi-) mais en "sauvegarde quotidienne".
De plus, l'utilisation d'un volume Truecrypt qui est totalement opaque au niveau gestion des fichiers empêche de faire des modification concurrentes sur des fichiers différents : par exemple, ajoutez un fichier A sur un poste, et un fichier B sur un autre poste, et après synchronisation, vous auriez pu avoir les 2 fichiers A et B sur les 2 postes.
Du coup, Dropbox ne peut même pas vous servir pour sa fonction bidirectionnelle.
[^] # Re: KISS
Posté par Etienne Bagnoud (site web personnel) . Évalué à 6.
Je viens de tester sur une machine 2 processeurs Xeon 2.66 Ghz, 32Gio. Pour un hash sha1 d'un fichier de 2.3 Gio, ça me donne ça :
real 0m21.886suser 0m9.905s
sys 0m2.288s
Je trouve pas ça "négligeable" ... et la machine n'est pas une petite machine.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# SpiderOak
Posté par reg . Évalué à 1.
Ça ne résout pas tous les problèmes et ce n'est pas adapté au partage de fichier comme l'est DropBox ; cependant pour de la sauvegarde, j'en suis très satisfait: SpiderOak
[^] # Re: SpiderOak
Posté par fcartegnie . Évalué à 3.
Comme un odeur de ZFS là dessous :)
# c'est vraiment nimp !
Posté par CrEv (site web personnel) . Évalué à 9.
Ben oui, depuis quand un journal bookmark contient autant de texte ?
Tout se perd ma p'tite dame, c'était mieux à vent !
# pas mal...
Posté par djibb (site web personnel) . Évalué à 0.
Pas mal pour une GUI de rsync...
[^] # Re: pas mal...
Posté par Vlobulle . Évalué à 4.
On a déjà affirmé ça dans plusieurs journaux sur le sujet, mais j'ai vraiment du mal à voir comment rsync fait de la synchro automatique bidirectionnelle en background.
[^] # Re: pas mal...
Posté par Spack . Évalué à 2.
Je ne sais pas s'ils utilisent rsync cependant, si on couple rsync avec un système de surveillance de fichiers tel
inotify, cela est tout à fait possible.[^] # Re: pas mal...
Posté par BFG . Évalué à 0.
Non, car ce n'est pas bidirectionnel.
[^] # Re: pas mal...
Posté par Alex . Évalué à 2.
Perso j'utilisai unisson + inotifywait pour faire de la synchro, ça marchait très bien
Pour du backup+de la synchro je suppose qu'on peut utiliser git ou svn. Mais finalement la vrai plus value de dropbox et consorts, c'est de proposer de l’espace de stockage dans un datacenter (et la bande passante qui va avec)
[^] # Re: pas mal...
Posté par oao . Évalué à 0.
L'espace de stockage ne vaut pas cher avec des VPS. Que valent lsyncd ou inosync ? (deux démons utilisant inotify + rsync)
[^] # Re: pas mal...
Posté par Zenitram (site web personnel) . Évalué à 2.
Je veux des noms! J'ai quelques Terroctets de données qui n'attendent que de l'espace de stockage pas cher pour avoir encore plus de redondance dans les backups... Alors ton espace de stockage "pas cher", je veux une preuve de ce que tu avances... Car je ne te crois pas. (après, j'imagine que ton offre hors de prix va être considérée comme pas chère, à tous les coups...)
[^] # Re: pas mal...
Posté par Alex . Évalué à 2.
Moi aussi
un vps pas trop cher, y'en a chez 1&1, par contre niveau perf c'est vraiment pourri.
Il m'arrive que mon simple serv mail soit injoignable, ou qu'une simple opération prenne de longues minutes, ou encore que mes uploads soient coupés en plein milieu...
Bref j'irai bien voir si l'herbe est plus verte loin de chez 1&1
[^] # Re: pas mal...
Posté par Psychofox (Mastodon) . Évalué à 1.
Si tu as quelques terraoctets de données chez toi, tu achètes ou te monte un serveur bien rempli de disque , tu l'installe chez une connaissance (famille/copain) qui a une connection haut-débit et voila, tu as ton stockage pas cher en ligne. Et tu n'as qu'à lui fournir une toute petite participation financière si la machine qui héberge lesdits terraoctets consomme beaucoup de jus.
En général c'est difficile à organiser chez quelqu'un qui n'a que faire de backups. Mais chez quelqu'un qui est sensibilisé à la chose, ça peut-être organisé assez facilement d'un commun accord si chacun accepte d'hébèrger chez l'autre ses backups.
[^] # Re: pas mal...
Posté par Zenitram (site web personnel) . Évalué à 2.
bof.
Merci, je me débrouille comme j'ai envie (ta solution a un SLA très très pourri, sans compter un délai de récupération incompatible avec mes besoins. C'est un backup "au pire si les autres ont merdé", mais surement pas un backup principal).
La personne parlait de VPS pas cher, donc j'attends la preuve de ce qu'il avance, c'est tout. Pas que tu me trouve des solutions qui ont des limites énormes et dont tu ne me préviens pas, en faisant croire que c'est une solution ultime.
[^] # Re: pas mal...
Posté par Psychofox (Mastodon) . Évalué à 2.
le backup principal, tu le fais à la maison, la c'est pour la redondance. Tu me demandes du stockage cheap je t'en donne, si tu changes le cahier des charges à chaque réponses...
Enfin bon j'ai l'impression que tu voudrait le beurre et l'argent du beurre.
[^] # Re: pas mal...
Posté par Zenitram (site web personnel) . Évalué à 2.
Non. Tu me donnes une solution pas du tout pérenne, avec un backup tout pourri.
Bon, OK, je continue dans ton sens : j'ai une ligne 56K qui fonctionne 1 heure par jour, tu veux du backup pas cher je t'en file un, tu es content? Parce que la, c'est exactement ce que tu me dis d'avoir.
Si je viens avec une baie 46U chez toi (ben oui, j'espère avoir plus de TB), tu me l'acceptes?
bref, tu proposes du bricolage pour pas cher, pas du backup.
Non, le monsieur dit "L'espace de stockage ne vaut pas cher avec des VPS", je veux une preuve de ce qu'il avance.
Je cherche une solution de backup, une vraie, un truc avec un SLA correct, une débit correct pour récupérer ses données, un tech pour changer le disque en cas de défaillance d'un disque avant qu'un autre disque de la grappe ne tombe en rade, bref une solution de backup. Je suis prêt à payer (je paye actuellement déjà un dédié pour), pas de problème, mais c'est pas donné, donc si je peux diminuer la facture, je prend. Si pour diminuer la facture il faut que je prenne un truc tout pourri, ben non, je garde ma facture chère, et dit qu'il n'y a pas de solution de backup "pas cher avec des VPS" comme on me l'indique.
[^] # Re: pas mal...
Posté par Psychofox (Mastodon) . Évalué à 2.
bref, tu proposes du bricolage pour pas cher, pas du backup.
T'es de très mauvaises fois. D'une part c'est pas forcément moins pérenne que si tes données finissent dans un datacenter. Un serveur privé ou un vps cheap, même s'il est dans un datacenter, de base ça n'inclue aucun backup ni redondance ni assurance de quoi que ce soit.
Ton histoire de baie 46u, c'est de la mauvaise foi car si c'est pour du backup, ça voudrait dire que tu aies déjà l'équivalent à la maison. Donc si tu en es la tu n'es plus à te poser la question de chercher du "pas cher".
ça reste de l'espace de stockage. Il y'a autant de solutions/architectures/politiques de backups que de clients. Ce n'est pas parce qu'une solution ne te convient pas qu'il faut faire l'autruche et dire que ça n'existe pas. Si toutes les solutions qui t'intéressent sont chères, c'est le marché, ça ne veut pas dire que les autres, moins chères, n'existent pas.
[^] # Re: pas mal...
Posté par Zenitram (site web personnel) . Évalué à 1.
Euh... Sans commentaire sur l'étude de risque. Que le niveau d'une maison perdue te suffise admettons, que tu dise qu'un datacenter n'est pas forcément pire, ce serait une faute professionnelle (j'image pas trop les chez soit avec protection incendie et sécurité comme dans un datacenteur)
Gni? Tu backupes que des postes clients toi? D'autres backupent d'autres choses. Je demande un espace de stockage. Même si c'est 100 GB par VPS, du stockage, si j'en ai besoin, j'en commande par 1000. Donc chez toi doit être prévu pour.
Je suis d'accord. j'ai réagis au terme VPS. Après, si on parle par défaut d'un VPS chez soit, pourquoi pas, ça fait juste bizarre alors, parce que par défaut quand même, quand on parle de VPS, il ne me semble pas qu'on accepte un truc avec peu de débit et très peu de garantie sur la pérennité.
Alors peut-être qu'on n'a juste pas le même référentiel, mais personnelement quand je parle de stockage sans précision, je pense plus à un truc pérenne que de l'artisanal à faible taux de garantie sur les données. le faible taux peut suffire OK, admettons.
Toujours est-il que j'attend le stockage pas cher en VPS, j'ai d'autres solutions (à commencer par Amazon ou serveur dédié) moins cher qu'un VPS pour le moemnt. Ou est l’exemple pour confirmer qu'un VPS est pas cher pour le stockage?
[^] # Re: pas mal...
Posté par Psychofox (Mastodon) . Évalué à 3.
Tu noteras que je ne t'ai pas parlé du VPS.
Moi je te dis juste que si tu veux du stockage par To, au prix d'un disque de 2To actuel, oui tu peux avoir quelques To à disposition avec un simple NAS chez un copain.
Après on parle de backup pour particulier. Si tu as tes données à 2 endroits, même si la maison de ton copain brûle, tu les fous ailleurs. Si tu estimes que la pérennité de la chose n'est pas assez grande, pouf, tu fous une autre copie ailleurs.
Maintenant t'as beau avoir des protections incendies et autre, ça ne te prémunies pas d'un serveur dont les composants claques du jour au lendemain, de la panne électrique générale ni que tu tombes sur un idiot qui éteint le mauvais serveur ou fait toute autre connerie.
Et pour ce qui est des débits, que tu backup les machines que tu as à la maison chez un copain ou dans un datacenter, le bottleneck reste ton débit en upload. Le seul intérêt d'avoir un serveur privé à ce niveau la, c'est pour les restorations. Mais après tout particulier peut se permettre de se passer de ses données 1 ou 2 jours le temps de les récupérer.
[^] # Re: pas mal...
Posté par Zenitram (site web personnel) . Évalué à 2.
Je réagissais initialement à l'assertion sur le prix pas cher du VPS.
Tu parles que d'une partie du service de stockage, en oubliant les 3/4 du service : le NAS va tout seul chez le copain? le débit pour récupérer les données? Le tech pour changer le disque rapidement avant que le deuxième disque ne tombe?
Ca met plein de limites au stockage.
Je ne dit pas que ce soit pas une réponse artisanale à un besoin artisanal, ça répond clairement à un besoin (et ce sera clairement sans doute ma solution pour le "3ème site" ou "4ème site" pas cher) si ce besoin est très restreint (SLA, délai de récupération, temps de gestion du bordel...), mais ma réaction était vraiment sur le fait qu'on me parle de stockage pas cher avec un VPS, et seulement ça.
[^] # Re: pas mal...
Posté par Juke (site web personnel) . Évalué à 2.
A combien tes Dropbox, S3 etc. assurent tes données ?
[^] # Re: pas mal...
Posté par Zenitram (site web personnel) . Évalué à 2.
Il est clair que Dropbox et compagnie n'assure que "sans contrepartie" un SLA de 99.9999999%. Mais quand on voit le tollé sur une petite coupure et perte chez Amazon, on voit qu'ils n'ont pas le droit à l'erreur.
Mon hébergeur actuel me garantit la disponibilité jusq'au prix que je lui paye.
Mais maintenant, peux-tu sérieusement garantir plus de 95% sur un site à la maison? Désolé, j'ai bien plus confiance en Amazon qu'en un site dans une maison pommée. Rien que sur le papier ça craint (aucune garantie sur le changement de disque rapide en cas de crash, aucun SLA sur la connexion Internet)
[^] # Re: pas mal...
Posté par DLFP est mort . Évalué à 1.
Sans compter que chez S3, pas de snapshots, par de rsync, mais des requêtes HTTP pour chaque fichier… difficile de trouver plus inefficace comme transfert. Comment je suis sensé gérer les sauvegardes hebdomadaires de mes 1160180 fichiers ?
Mais comme c'est dans le cloud, on ferme les yeux et on écarte les fesses.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: pas mal...
Posté par Zenitram (site web personnel) . Évalué à 3.
Amazon S3 propose les snapshots.
Pour le reste, clair, c'est pas adapté à un backup incrémental "out of the box", il faut passer par un service tiers (genre Dropbox, mais ce ne sont pas les seuls). Pour rsync, il y a rsync.net, suivant les besoins tu peux tomber à 0.24$/GB redondé (perso c'est trop cher de mon point de vue par rapport à un dédié sur 2 sites, bien que je pense que leur offre a uune bien meilleure sécurité, mais ma sécurité s'arrête quand même un peu).
Même rsync.net est moins cher qu'un exemple fournit pour le VPS ;-).
[^] # Re: pas mal...
Posté par oao . Évalué à -1.
T'es bien gentil, mais on n'a pas élevé les cochons ensemble, et ton expérience de trolleur sur Linuxfr ne t'autorise pas à avoir un tel ton. Après tout dépend de ce que tu veux, tu ne peux pas avoir en même temps, pour l'instant, des prix bas, du stockage très important (To) et "rien" à faire. On parle ici de Dropbox, donc pour un volume de stockage de quelques dizaines de Go, et non de ton cas en particulier. Il existe effectivement des alternatives moins chères et plus polyvalentes, en VPS. Petit rappel Dropbox est à 10€/mois pour 50Go et 20€/mois pour 100Go.
Je pensais effectivement à 1&1, qui est à 20€/mois pour 100Go (même prix que Dropbox) et 5€/mois/100Go supplémentaires, jusqu'à 800Go, ce qui peut donc revenir beaucoup moins cher que Dropbox. La QoS est moins importante pour du stockage de donnée que pour d'autres applications. Dans le cloud, Amazon S3, Gandi ou App Engine sont à 10-15€/mois/100Go, mais le transfert de donnée est payant.
Je viens aussi de voir que 1&1 faisait une offre avec stockage illimité pour 20€/mois, en mutualisé. Je cherche l'arnaque, pas sûr qu'ils n'apprécient des To de data. Et a priori pas d'accès SSH au serveur.
Après si ton besoin c'est des To de donnée, on ne parle plus de concurrent de DropBox. Pas de miracle : serveur dédié (50€/mois/To) ou chez un copain, ce qui reste la solution la moins cher et peut être très léger avec un plug computer et des disques de quelques To. Et tout à fait fiable si tu fait de la redondance triple (chez toi + 2 copains, voire en plus chez toi *2). Tu n'auras pas une QoS de folie (c'est le moins qu'on puisse dire) mais on s'en fout, il suffit de compenser par de la redondance.
Si c'est pour toi "hors de prix" redéfinit tes priorités : tes X To de data sont-ils vraiment importants ou n'est-ce pas en grande majorité des données bougeant peu, avec uniquement quelques dizaines de Go modifiés ? Peux tu te déplacer pour changer un disque, ou n'as tu pas le temps de prendre deux heures pour passer chez un copain ? N'enregistre que les modifs faites à tes fichiers et garde les originaux au chaud sur un disque dur laissé dans un coin. Avec un peu d'effort je suis sûr que tu pourras sauvegarder tes données vraiment importantes.
[^] # Re: pas mal...
Posté par DLFP est mort . Évalué à 2.
20€ c'est le prix d'un serveur dédié avec 1 To. Mais bon, c'est pas dans le cloud.
Mais de toute façon si tu as des To à sauvegarder, je ne vois pas comment tu vas faire pour les envoyer sur Internet avec de l'ADSL.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: pas mal...
Posté par Zenitram (site web personnel) . Évalué à 0.
ADSL = 1Mbps = 100 KB/s environ = 1 TB toutes les 3 heures, en 1 mois les 100 GB sont largement remplis.
Il y a la fibre en France qui se déploie 100 Mbps.
Ailleurs, il y a de VDSL (perso, je tape dans le 1 MB/s, dont plus de 2 TB par mois uploadable).
Et surtout, les données ne sont pas forcément chez toi, on peut vouloir du stockage à partir d'un serveur chez un hébergeur avec un lien 1 Gbps à soit.
Bref, plein de façon d'avoir des GB à stocker, ce qui m’intéresse c'est le prix du stockage (disponible par Internet à un débit correct, il me semblait que cela allait de soit, sinon j'ai mon vieux modem 56K disponible avec une maison au fin fond de la Russie pour dire que j'ai la possibilité de stocker pas cher)
[^] # Re: pas mal...
Posté par DLFP est mort . Évalué à 2.
100 ko/s c'est 8.2 Go par jour. 1 To c'est plus de 4 mois en envoyant constamment !
Et pour ma part j'utilise aussi mon upload (4-5 Go par jour), ça fait aussi ça à sacrifier.
Je crois que ta problématique, comme tes calculs, est fantaisiste. Moi j'ai véritablement 4 To à sauvegarder et les backups online ne sont vraiment pas une bonne solution actuellement.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: pas mal...
Posté par Zenitram (site web personnel) . Évalué à 2.
Je me suis trompé sur une ligne --> GB toutes les 3 heures, en effet. Après, c'est la limite chez toi, pas sur le stockage, on peut avoir ça suffisant pour l'upload, et avoir surtout un besoin de download fort en cas de crash disque chez soit, donc dans la majorité des scénarios "persos" c'est suffisant. Ca reste une limite pas dûe au site de stockage.
Tu proposes? J'ai personnellement fait le choix de payer plus cher ma connexion pour avoir 1 MB/s en upload (miam!) + un dédié en RAID 1 sur un site digne de ce nom + il faut que je fasse le miroir de la chose quelque part ailleurs, un seul site de backup c'est limite, ce sera sans doute chez quelqu'un perso en effet car le stockage sera alors en dernier recours si tout va mal donc ça peut aller comme choix. Faudrait que je sois plus sérieux sur mes backups.
Parce que si tu vires "online", ben c'est des emmerdes en terme de site (que chez toi) ou de délai (le temps que ça ailles ailleurs). Donc je vois pas trop comment faire mieux...
Bon, ça c'est que pour la partie chez toi, il reste la partie déjà sur un site à 100 Mbps ou 1 Gbps (à 10€/mois on a un petit serveur avec cette connexion de nos jours...)
[^] # Re: pas mal...
Posté par Zenitram (site web personnel) . Évalué à 2.
Ton assertion comme quoi un VPS n'est pas cher pour du stockage est trop grosse, je ne pouvais pas laisser passer une bêtise aussi énorme... Les VPS ne sont pas du tout fait pour le stockage.
J'aimerai bien les connaitre. Déjà, il me faut 3 VPS différents sur 3 sites différents (ben oui, DropBox c'est Amazon S3, donc redondance 3 sites)
Ouch. Cher. 0.20€/Go non redondé, ça fait 0.60€/Go pour une redondance correcte, contre 0.10€/Go chez Amazon. Pour 50€/mois j'ai 2 TB chez OVH (c'est ce que j'ai actuellement), je pourrai en revendre des tranches de 100 Go pour 20€!
J'ai mes priorités : un espace de stockage, comme tu as dis que c'était pas cher en VPS, je veux des noms. Tu me files un exemple à 0.20€/Go non redondé, euh... C'est cher, c'est tout. Tu as dis textuellement "L'espace de stockage ne vaut pas cher avec des VPS.", et tu démontre par ton message que ben... c'est faux, tu n'arrives pas à donner du stockage pas cher.
Après, ça fait rire que tu parles de stockage de manière générique en pensant à une QoS pourrie, un débit ridicule, un remplacement en cas de panne de disque aléatoire et des coûts de déplacement/installation pas légers du tout.
On doit juste pas avoir la même définition du minimum pour le stockage ni de VPS, effectivement.
[^] # Re: pas mal...
Posté par BFG . Évalué à 4.
lsyncd et inosync ne sont pas bidirectionnels.
Qu'est ce que la bidirectionnalité ? C'est ce qui permet de déterminer de connecter plusieurs postes de travail à un serveur, et de propager les opérations à tous les postes.
Néanmoins, tout le monde n'a pas besoin de la bidirectionnalité (si l'on n'a qu'un seul poste, ou alors si on utilise les différents postes en séquence uniquement, et qu'on lance certaines commandes rsync à certains moments bien précis)
En quoi rsync ne permet pas cela alors qu'on pourrait appeler "rsync local: distant: ; rsync distant: local:" ? Car si un fichier est supprimé, l'opération n'est pas propagée. Et si l'on ajoute "--delete" ? Alors, il ne sera pas possible d'ajouter un nouveau fichier depuis un poste car un autre poste le supprimera, car "--delete" fera croire à rsync que le fichier est superflu.
Comment résoudre le problème ? En gardant un état, pour mieux considérer chaque fichier, et ne laisser à rsync que le transfert individuel de fichiers, et non plus le transfert d'arbres de dossiers/fichiers.
[^] # Re: pas mal...
Posté par Spack . Évalué à 3.
C'est peut-être un peu lourd mais
Si on va plus loin, un service sur chaque client se connecte au serveur pour lui annoncer sa nouvelle adresse IP.
Ce n'est pas forcément simple à faire mais je pense que l'on peut obtenir le même résultat en utilisant rsync + inotify.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.