Bonsoir nal,
Je viens d’apprendre que le mainteneur d'Obnam, le logiciel de backup (et de restore), a décidé d'abandonner son logiciel. Comme raisons, il cite le fait que ça ne l'amuse plus et que le code n'est pas maintenable comme il l'aurait dû. Il pense notamment que tout devrait être réécrit mais qu'il n'en a pas le courage.
Il annonce quand même qu'il corrigerait tous les gros bugs ou failles de sécurités qui apparaîtraient d'ici la fin de l'année mais encourage tous les utilisateurs à migrer vers une autre solution (sans en citer). Notamment, les paquets ne seront pas présent dans la prochaine version de Debian.
# Retiring Obnam
Posté par Benoît Laurent (site web personnel) . Évalué à 3.
Posté aussi sur son blog : Retiring Obnam
Je l'utilise encore, mais je teste aussi de temps en temps BorgBackup
Dans le même genre il y a restic que je n'ai pas testé.
[^] # Re: Retiring Obnam
Posté par Christophe B. (site web personnel) . Évalué à 3.
J'aime bien Borg Backup, simple et apparemment efficace
2 reproches :
- le format de sauvegarde quelqu'un a regardé si c'est utilisable SANS borg ?
- existe t il une interface graphique pour les allergiques à la ligne de commande ? au moins pour la restauration
[^] # Re: Retiring Obnam
Posté par Anonyme . Évalué à 3.
J’utilise borg sur mes serveurs pour sauvegarder les données (le disque des VM est déjà sauvegardé d’une autre manière) et ça marche plutôt bien.
Je l’utilise avec un wrapper fait maison, mais il en existe d’autre qui sont plutôt bien fait comme borgmattic.
Après, c’est comme tout les systèmes de backups, la fonction principale c’est la restauration et il faut s’assurer qu’elle fonctionne correctement.
# Pas trop étonné
Posté par SaintGermain . Évalué à 7.
Obnam m'avait semblé bien intéressant lorsque je m'étais motivé à faire un comparatif entre les différents logiciels libres de sauvegarde offrant la déduplication.
Cependant j'ai essayé de participer et le mainteneur d'Obnam m'avait semblé vraiment « spécial ». Voir par exemple cet échange que j'ai eu avec lui à l'époque quand il a demandé de l'aide.
Un logiciel peu populaire développé par une seule personne au caractère un peu spécial ? Cela ne me semblait pas la recette idéale pour espérer une bonne pérennité (surtout quand dans le domaine de la sauvegarde, on cherche plus quelque chose de stable, robuste et pérenne, plutôt que quelque chose de révolutionnaire d'un point de vue technique).
Du coup je suis parti sur BURP et je ne regrette pas du tout mon choix. BURP est aussi majoritairement développé par une seule personne, mais cette personne est très ouverte et surtout est très dédiée à son logiciel (les bogues sont très rapidement corrigés, des releases régulières et mensuelles depuis de nombreuses années).
Je regarde régulièrement mais je n'ai toujours pas trouvé mieux (performant, multi plate-forme, VSS sous Windows, déduplication, stratégie de sauvegarde/expiration). Cependant je conçois que ce n'est pas une solution pour tout le monde, vu qu'il dépend surtout d'une seule personne (analyse de risque à faire…).
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . Évalué à 8.
Ben j'ai l'impression que ta participation était à côté de la plaque plus que lui était spécial. Il demandait si des gens étaient motivés à maintenir et hoster un issue tracker, tu lui envoies une palanquées d'outils dont tu as juste entendu parler et lui demande s'il peut fournir le serveur. Il demande si quelqu'un a envie d'écrire des bouts de manuels à partir d'use cases parce qu'il manque de temps et tu lui demandes de faire une recherche sur des manuels qui lui plaisent. Bref j'ai l'impression qu'il s'est dit que tu partais dans tous les sens sans avoir pris le temps de lire son message initial et que tu allais lui faire perdre plus de temps que d'en gagner.
Après le mainteneur en question est finlandais et pour avoir une vague connaissance de la culture finlandaise leur façon de s'exprimer, souvent très directe et avec le minimum d'argumentation possible, peut souvent paraître un peu rude aux personnes qui n'en ont pas l'habitude.
[^] # Re: Pas trop étonné
Posté par SaintGermain . Évalué à 5.
Ben si tu veux on peut répondre l'échange en quotant :
Il demande des opinions, eh bien j'en donne.
Il ne veut pas administrer le serveur. Je lui propose de m'en occuper. Il n'est nulle part indiqué que je dois aussi payer et fournir le serveur.
Il indique que le manuel en l'état n'est pas correct. Je lui propose de l'améliorer mais je en sais pas ce qu'il considère comme correct. Donc je lui demande un exemple de manuel qui lui semble correct afin de ne pas perdre du temps à écrire quelque chose à côté de la plaque.
Note : à noter que suite à sa réponse, d'autres personnes m'ont envoyé un email en privé pour me dire que mes questions étaient légitimes et qu'ils pensaient que le mec était juste dans une mauvaise période.
Bref quand tu offres ton aide et que l'on t'envoie bouler pour avoir posé des questions (maladroites ou pas, à vous de décider…), ben tu ne reviens plus.
Après c'est son droit le plus strict de se comporter ainsi (même si pas très poli) mais après je ne suis vraiment pas étonné de voir son logiciel mourir avec lui comme seul contributeur.
[^] # Re: Pas trop étonné
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Salut,
Je vais donner un avis non sur "qui a tort ou raison", mais sur la contribution à un projet libre en général. Note que je n'ai absolument pas lu la discussion dont tu as fait le lien, hormis ces micro-bouts que tu cites ici (et qui sont tellement petits et hors contexte qu'il m'est impossible de me faire une idée, et d'ailleurs ça m'intéresse pas). Je veux être bien clair que mon commentaire n'est absolument pas pour te dire que tu as tort. En fait, si j'ai une opinion: je pense que personne a tort, mais qu'il faut simplement voir un peu plus loin qu'un échange email de quelques minutes pour le comprendre.
Il a probablement mal formulé ou alors ne se rendait pas compte lui-même qu'il ne demandait pas une opinion. Il ne demandait pas de propositions non plus. Non mon intuition est qu'il demandait une action concrête. En gros, probablement rêvait-il de quelqu'un qui arrive avec un logiciel de gestion de bugs installé, prêt à l'emploi, et d'une promesse de maintenance. Le fait est qu'il n'a a priori pas le temps (ni l'envie sûrement) d'administrer tout plein de choses. Se limiter au développement de code lui suffit. Par contre il est conscient que ces autres choses sont utiles voire nécessaires quand on atteint un certain nombre d'utilisateurs. Et il aimerait donc d'autres types de contributeurs, ceux qui font de l'administration de serveur.
Bien sûr, on peut avoir peur de faire du travail pour rien. Et si jamais tu te pointes avec une instance de Bugzilla (ou autre) et que tu as pris 2h de ton temps pour tout installer et qu'il refuse (car il trouve Bugzilla mauvais par exemple)? Ce n'est absolument pas impossible. Eh bien, tu sais quoi? C'est pas grave! Ça nous arrive tout le temps en tant que développeurs de logiciels libres. Si tu savais le nombre de patchs que j'ai écrits et qui n'ont pas fini dans le logiciel auquel je contribuais! Je sais pas non plus moi-même combien, mais je suis sûr que la réponse est "beaucoup". Et tout patch prends du temps, des heures souvent, même pour un patch mineur (surtout pour un logiciel auquel on contribue pour la première fois). C'est le jeu du logiciel libre et je n'en veux à personne (même quand je ne suis pas d'accord avec les raisons du refus).
Cela peut paraître contraignant, mais comment faire confiance autrement? Des gars qui nous "conseillent", qui disent "comment faut" faire les choses, qui sont pas contents, qui nous disent que sans "telle fonctionnalité", notre programme c'est de la merde… t'en as des tonnes. Ceux qui font. T'en as beaucoup moins. Et c'est eux qu'on écoute et à qui on donne notre confiance: entre un gars qui nous dit "utilisez le logiciel X", et le gars qui arrive avec un serveur installé et tenu à jour avec le logiciel Y, le choix est vite fait (même si on préfèrerait personnellement X d'ailleurs).
C'est un peu pareil ici. Il n'a pas de manuel qu'il considère correct, comment te donner un exemple, sauf à faire lui-même le travail que justement il dit ne pas vouloir/pouvoir/avoir le temps de faire? Quelqu'un qui arrive avec des exemples concrets de bonnes pages de manuel, il aurait sûrement dit "génial". Ça ne l'aurait pas empêché de faire éventuellement quelques petites corrections ici ou là, puis le contributeur pareil après coup. C'est comme cela qu'on fait un bon manuel libre: incrémentalement à partir d'une base saine et solide.
Je vais donner un exemple concret: sur GIMP, pendant des années, on a eu un vieux site du web de l'an 2000. On le savait qu'il était vieux et hors du temps. Il eut été inutile de nous le dire ou de nous donner des "opinions" parce qu'aucun des développeurs core n'avait l'envie de faire un site web, de toutes façons. On n'allait pas non plus donner des "exemples" de bon site web, car c'eut été limiter les contributeurs intéressants; et puis c'est pas notre boulot. On veut pas avoir à montrer des sites aléatoires et dire "ah bah ça c'est joli". C'est absolument pas constructif pour notre site à nous.
Un jour, un gars est arrivé et a proposé un site bien scripté, avec de l'automatisation, joli et moderne, et surtout on savait qu'il resterait pour le maintenir. Ça a pas fait un pli, quelques mois plus tard, c'est devenu le nouveau site officiel. Ça ne nous empêche pas de donner un avis contradictoire quand on n'aime pas quelque chose, mais notre avis par défaut (notamment si on n'a pas d'avis), c'est "va y, c'est toi qui vois; t'es le boss du site". En gros on attend des contributeurs qu'ils se prennent en main et qu'ils soient indépendants (ils sont en charge de leur partie).
Cela peut te paraître abusé, mais les développeurs payent aussi beaucoup, en temps déjà, en matériel, en serveurs (loués ou non) aussi. Une fois qu'un projet commence à avoir une notoriété, il n'est absolument pas inhabituel que les serveurs ou autre matériels complémentaires soient fournis gracieusement, que ce soit par des particuliers ou des entreprises, etc. C'est une autre forme de contribution. En outre quand on ne veut pas avoir à administrer, on ne veut souvent pas même avoir à penser à tout ce qu'il y a autour du serveur: renouveler la location éventuelle, les noms de domaine, mettre à jour régulièrement les données DNS; sans compter que dire de ne pas vouloir administrer, ça veut rarement dire "juste le logiciel bugtracker". Dans un serveur, faut gérer l'OS, les mises-à-jour, la sécurité, lire des logs, etc. Ça me paraîtrait un peu sous-entendu qu'il ne proposait pas de s'occuper de tout cela et que quelqu'un d'autre s'occuperait juste du bugtracker sur ce serveur. Non il voulait probablement quelqu'un qui souhaite s'occuper d'absolument tout le serveur.
En gros, il cherchait probablement des gens qui souhaitent intégrer pleinement l'équipe et savent se prendre en charge, pas des petites mains qui attendent les ordres. Enfin je dis ça… encore une fois tout ce que je dis plus haut, c'est pas forcément une explication de ton exemple précis (dont je sais rien), mais est une extrapolation du fait que c'est souvent ce qu'on cherche dans le logiciel libre: des gens indépendants qui agissent vite et bien et prennent des responsabilités. Un logiciel (libre ou non), c'est une équipe. Perso, je considère Pat David (le gars qui nous a fait le nouveau site, qui agit beaucoup au niveau "communauté", qui fait des tutos, etc.) comme aussi important que les développeurs core de GIMP. Il agit juste sur un autre niveau. Des opinions et des idées, on en entend 30 par jour. Que dis-je! On en a soi-même 10 à la minute (parfois des bonnes même! :P). Si les logiciels avançaient grâce aux idées, alors les êtres humains seraient tellement avancés en informatique que les films futuristes paraîtraient passéistes. Non les logiciels/projets avancent avec les actions.
C'est vraiment une chose fondamentale. S'il y a bien une chose que le logiciel libre peut enseigner, c'est de se responsabiliser et d'agir. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pas trop étonné
Posté par SaintGermain . Évalué à 2.
Salut,
Toujours intéressant d'avoir ton point de vue, merci (et merci pour le travail sur Gimp).
Tout d'abord, dire que "A ou B a tort ou a raison" dans mon échange avec Lars (le créateur d'Obnam) n'est pas pertinent car il n'y a pas d'affirmation à vérifier.
Nous avons échangé une paire d'emails, nous n'étions pas sur la même longueur d'onde, on est reparti chacun de notre côté, aucun des deux n'a perdu quoi que ce soit.
Ce qu'il y a d'agréable et rafraîchissant avec le logiciel libre, c'est que en tant qu'auteur, tu es libre de développer ce que tu veux et de gérer le projet comme tu le veux. Et en tant que contributeur, je suis libre de participer ou pas.
Donc si l'auteur a envie de m'envoyer balader, il est libre de le faire pour n'importe quelle raison. De mon côté, je serais peut-être un peux vexé que l'on refuse mon aide, mais j'ai juste à aller voir ailleurs et c'est tout.
Pour tenter d'expliquer le comportement de Lars, tu expliques l'état d'esprit d'un auteur et ce qu'il attend d'un contributeur. Mais en tant que contributeur sur mon temps libre, cela ne m'intéresse personnellement pas tant que ça de me faire envoyer balader et de tenter d'anticiper les desiderata d'une personne tout en marchant sur des oeufs pour ne pas poser des questions qui fâchent (je vis cela assez au boulot, cela me suffit). Donc je ne contribue que lorsque le projet ET l'auteur me plaisent, et je n'ai pas du tout envie, mais alors pas du tout, de chercher à comprendre l'état d'esprit de l'auteur et de lui chercher des circonstances atténuantes pour justifier son comportement, c'est mon droit.
Après il faut voir l'objectif que poursuit un auteur. Si c'est développer juste pour le fun, qu'il se fasse plaisir comme bon lui semble.
Si ses objectifs sur ce point particulier (ce fil de discussion dans lequel je suis intervenu) :
On peut juste constater les résultats :
Donc je suis triste pour Obnam et pour Lars (ce logiciel était vraiment très intéressant, et en plus il était libre !) mais le résultat ne me surprend pas plus que cela.
[^] # Re: Pas trop étonné
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 15 août 2017 à 12:05.
C'est sans doute la le soucis de compréhension entre les "bénévoles" et les gestionnaires de projet, qui vient de incompréhension que "vouloir aider" n'est pas suffisant pour aider : il faut que ce qu'un bénévole apporte soit plus rentable que si il n'est pas la. Et non, il n'y a pas que le "coût gratuit" du bénévole qui est un coût, le coût comprend plein d'autre choses comme la gestion des désidératas d'un bénévole en échange (ou comment un bénévole n'est pas si bénévole, il ne vient que si xxx) et du fait qu'il dise "je suis bénévole alors ne me dit pas ce que je dois faire ou je me casse".
Et tant que ce n'est pas compris, le "je te propose mon aide moi le gentil mais tu m'envoies balader toi méchant" continueront (et n'aideront pas le projet, car le projet n'a pas besoin de ça, au contraire il faut qu'il évite ces propositions sans passer pour méchant, c'est du taf en plus).
Justement, peut-être que le problème est que ce n'est pas si concret que ça, et pas une aide tant que ça, en pratique (rapport coût que tu demandes en "à côté" genre qu'on soit comme tu le souhaites avec toi).
Bref, le plus gros problème ici est sans doute de considérer que de vouloir être bénévole est une grande aide, ce qui n'est en fait pas suffisant (utile mais pas suffisant).
Note : je suis de l'autre côté, et déjà souffert avec des bénévoles qui m'ont apporté plus de problèmes qu'autre chose à hurler que je refuse leur patch qu'ils ont fait avec amour mais que j'ai refusé car cassé un truc dont ils se foutaient "pas un argument, et puis patche mon patche j'ai déjà bossé moi alors tu devrais me remercier au lieu de refuser le patch" (ben en fait patcher ton patch me coûte plus cher que ce que ton patch rapport, donc bye car tu n'aides pas en fait), donc je ne suis pas forcément objectif.
[^] # Re: Pas trop étonné
Posté par SaintGermain . Évalué à 2.
Je ne vois pas d'opposition entre les deux affirmations de mon côté. Encore une fois tu es tout à fait libre d'envoyer valser le bénévole s'il n'est pas rentable, et lui n'est pas du tout obligé de vouloir travailler avec toi (qu'il soit rentable ou non).
Je répète qu'il n'y a pas de gentil ou méchant, ou de qui a tort ou qui a raison.
C'est juste qu'il y a des caractères qui ne m'encouragent pas à contribuer, mais c'est mon opinion personnelle et je le partage ! ;-)
Soyons justement concret 2 minutes. L'auteur a besoin d'avoir un nouveau système de ticket, il appelle à l'aide à ce sujet, certaines personnes répondent (maladroitement ou pas, concrètement ou pas) et au final il ne se passe rien pendant 4 ans et il finit par implémenter son propre système de ticket.
Alors quelle est la théorie la plus probable ? Que c'est un Linus en puissance, avec des besoins tellement particuliers qu'il doive révolutionner la gestion des ticket avec un Git-like ?
Non ce n'est pas le problème ici.
Le problème c'est qu'il n'a pas réussi à avoir l'aide qu'il souhaite pour son système de ticket et il n'y a pas de mainteneur (à ce jour) pour reprendre son projet (pourtant très intéressant de mon point de vue). Du coup je donne mon point de vue sur la cause possible (ce n'est que mon avis).
[^] # Re: Pas trop étonné
Posté par freem . Évalué à 2.
Je suis intrigue: si le projet est super interessant et que le probleme est juste le futur-ex-mainteneur, pourquoi personne n'a fork, ou reprend maintenant que le probleme sera regle?
Je veux bien croire que personne parmis les utilisateurs n'a le temps de maintenir en solo, mais si plusieurs veulent contribuer, etre solo n'est pas une obligation?
Enfin, je dis ca je dis rien, je sais d'experience que reprendre un projet est loin d'etre simple, meme completement mort.
[^] # Re: Pas trop étonné
Posté par SaintGermain . Évalué à 2.
Reprendre un projet sur le point d'être abandonné alors que l'on était pas un des co-mainteneurs, cela me semble presque impossible.
Rien que motiver des co-mainteneurs à venir, cela nécessite que les astres soient bien alignés : il faut que la personne soit compétente techniquement, que le projet l'intéresse, qu'il ait suffisamment de temps, que les caractères soient compatibles, que tout le monde soit d'accord sur la stratégie à adopter, et j'en oublie certainement.
Sinon oui je trouve le projet très intéressant : je ne connais pas tant de logiciels libres de sauvegarde incluant la déduplication (avant envoi des données) et le chiffrement (compatible avec la déduplication).
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . Évalué à 2.
Il y'a deux écoles mais personnellement je préfère que mon logiciel de backup soit "bête et méchant" à ce niveau là et déléguer la fonctionnalité de deduplication à la couche FS.
[^] # Re: Pas trop étonné
Posté par claudex . Évalué à 3.
Ça veut dire que tu envois des données en trop. C'est comme le chiffrement, tu peux aussi le déléguer au FS (ou en dessous) mais ça veut dire que la machine hébergeant les données y a accès. Je comprends que ce soit des fonctionnalités « nécessaires » dans certains cas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . Évalué à 3.
Comme je le dis il y'a deux écoles. En gros plus ton infra est robuste (réseau et stockage rapide, serveurs puissant et bien dotés en ram), plus tu auras tendance à déléguer ça à la couche FS. Si par contre tu backup via du wifi, des lignes lentes et un stockage pas très rapide sur un nas lowcost tu préferas probablement faire la dedup en amont (typiquement le backup à la maison).
[^] # Re: Pas trop étonné
Posté par claudex . Évalué à 3.
Justement, je préfère que le soft de backup puisse faire les deux pour s'adapter en fonction du contexte.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas trop étonné
Posté par SaintGermain . Évalué à 1.
Si je ne me trompe pas, si le chiffrement est bien fait, il n'est pas vraiment possible de dédupliquer après.
Donc ton approche ne me semble valable que sur un réseau interne (indépendamment du fait qu'il soit rapide, puissant, ram, etc.).
[^] # Re: Pas trop étonné
Posté par claudex . Évalué à 4.
Non, c'est valable tant que tu backup sur une machine de confiance, même en passant par des liens dont tu n'as pas confiance, parce que la communication peut être chiffrée sans que les données sur la destination le soit.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas trop étonné
Posté par SaintGermain . Évalué à 2. Dernière modification le 16 août 2017 à 09:55.
Ah oui tu as raison.
Mais du coup si la machine où se trouve le backup est vraiment sécurisée, quels cas d'utilisation il reste pour justifier le chiffrement des backups ?
[^] # Re: Pas trop étonné
Posté par claudex . Évalué à 2.
Le cas où la machine n’est pas sécurisée justement. Tu t’arranges avec quelqu’un que tu connais qui te fournit de l’espace disque par exemple. Ou tu backup sur Amazon S3.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas trop étonné
Posté par SaintGermain . Évalué à 2.
Si la machine n'est pas en interne et pas sécurisée et que le chiffrement est effectué sur cette machine, cela me semble moyen quand même.
Surtout que pour la déduplication après envoi des données, il faut que la machine soit en ZFS (online) ou Btrfs (offline). La déduplication online avec ZFS demande un matériel vraiment puissant (avec beaucoup de RAM ECC je suppose) et avec Btrfs il faut y aller avec des pinces (voir récents journaux à ce sujet).
L'approche chiffrement et déduplication avant envoi me semble bien mieux sur tous les points, sauf… sur celui de la robustesse/fiabilité car les logiciels ne sont pas encore très mûrs ! ;-)
[^] # Re: Pas trop étonné
Posté par claudex . Évalué à 4.
Je pense que j'ai mal compris ton message. J'ai cru que tu demandais le cas d'utilisation de chiffrement avant envoi et pas du chiffrement sur la machine. Le chiffrement sur la machine, il y a la question du vol. Typiquement, mon backup chez moi est chiffré au niveau block device pour éviter qu'un voleur ait accès au contenu (cela ne lutte pas contre quelqu'un qui dumperait la ram, mais je considère que le risque est faible chez moi, surtout qu'il y a d'autres attaques plus faciles à mettre en place).
Il me semble que la recommandation, c'est 1Go de RAM par To de stockage. Mais, je ne suis pas sûr que ce soit très différent d'un autre soft qui fait de la dédup.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas trop étonné
Posté par SaintGermain . Évalué à 2.
Effectivement mon message initial parlait de déduplication ET chiffrement. PsychoFox avançait qu'il préférait dédupliquer après envoi, et moi je disais que ce n'était pas compatible avec le chiffrement.
Ton message me semblait proposer un chiffrement après envoi (et en envoyant les données via un canal chiffré, SSL par exemple) et effectivement cela fonctionne dans ce cas.
Bon la machine peut être compromise si on y accès alors qu'elle tourne, mais c'est un risque que l'on peut juger négligeable.
Cependant je trouve l'approche déduplication+chiffrement avant envoi bien plus intéressante sur beaucoup de points (mais c'est relativement nouveau, donc je comprends la réticence).
D'après ici, c'est plutôt 5 Go de RAM par To.
D'expérience avec BURP ou Btrfs (déduplication offline au niveau du fichier), la consommation en RAM est vraiment ridicule (en gros je suppose qu'il faut pouvoir stocker un checksum de chaque fichier en RAM). Mais ce n'est pas de la déduplication au niveau du bloc.
[^] # Re: Pas trop étonné
Posté par claudex . Évalué à 3.
Ça donne envie:
C’est vrai que j’avais oublié (et je considère ça comme la dédup du pauvre, même si je l’utilise avec urbackup). Obnam le fait par bloc aussi il me semble.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 16 août 2017 à 12:35.
Sous ZFS le coût en terme de mémoire est de 320Bytes par block. Il faut connaître le nombre de block utilisé par les données, tout en sachant que sous ZFS la taille de block est dynamique :
http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size-zfs-dedup-1354231.html
http://constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe
Bref il faut tester avec des jeux de données réalistes et connaitre où on veut placer le curseur entre performances (toutes les tables de dedup en mémoire) ou coût et utilisation mémoire réduite (cache sur disques rapides ssd).
Et le tout dépend des fluctuations entre prix de la ram et prix du stockage.
Cela-dit la dedup n'est pas possible que via zfs et btrfs. Il existe aussi d'autres solutions que je n'ai pas testé comme opendedup, lessfs ou permabit VDO.
[^] # Re: Pas trop étonné
Posté par SaintGermain . Évalué à 3.
Je retiens comme ordre de grandeur ce qui est donné en conclusion dans ton 2ième lien :
Mais est-ce que ces solutions peuvent être considérée comme robustes/fiables ? Déjà que Btrfs, il faut y aller avec des pincettes… Quand je vois tout ce qu'il faut pour faire confiance à un FS : performance OK dans tous les cas de figure, outils de récupération fonctionnels, comportement en cas de corruption, upgrade sans problème lors de la mis à jour du noyau, etc.
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . Évalué à 3.
Pour le cas de ZFS il faut savoir que toute ce qui est dedup/chiffrement/compression se fait au niveau block et pas au niveau fichier sous ZFS donc il est tout à fait possible d'activer à la fois le chiffrement et la deduplication en même temps.
[^] # Re: Pas trop étonné
Posté par SaintGermain . Évalué à 1.
Oui mais tu ne peux pas chiffrer avant envoi (car sinon pas de déduplication après envoi, si je ne m'abuse), ce qui n'est pas optimal d'un point de vue sécurité.
Le chiffrement avant envoi permet de stocker ton backup à un endroit dans lequel tu n'as pas confiance.
Mais bon je t'accorde que les logiciels de backup offrant déduplication+chiffrement (avant envoi) ne sont pas encore très mûrs.
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . Évalué à 2.
On est d'accord que si tu dédup et chiffres dans le FS après envoi c'est dans un cas où justement tu maitrises et gère le stockage final.
Cela-dit dans un cas où tu as plus d'une poignée machines à sauvegarder en général tu as un système de backup tampon à court terme en local, donc il n'est pas inimaginable si on reprend l'exemple de zfs de dédupliquer et chiffrer sur un serveur local qui après envoie ses snapshots dans le cloud.
De toute façon la réalité c'est que la dedup n'est as forcément une solution très pertinente en terme de coût.
[^] # Re: Pas trop étonné
Posté par SaintGermain . Évalué à 1.
Concrètement tu fais comment ? Est-ce qu'il faut que le Cloud soit aussi en ZFS ?
Avec Btrfs je sais que tu peux facilement perdre la déduplication si tu envoies les données ailleurs (en gros tu ne gardes la déduplication que si le FS cible est aussi Btrfs et que tu envoies des snapshots via btrfs send, ce qui est assez contraignant).
Le fait de se reposer sur le logiciel de backup pour faire la déduplication, permet d'être indépendant du FS.
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . Évalué à 2.
Non tu peux envoyer des snapshots sous forme de fichiers. Vu que le contenu est dédupliqué les snapshots incrémentaux ne devraient pas être gros donc même si les fichiers qui finissent sur le stockage distant ne sont eux-même pas dédupliqués le bénéfice existe encore.
Le point noir de ce genre de truc dépendant des fonctionnalités comme zfs c'est qu'une fois que les données sont parties sous forme de snapshots tu ne peux pas y accéder directement. Tu dois restaurer les snaps sur un pool zfs pour avoir accès aux fichiers finaux. Ça va si tu n'as pas besoin que tes utilisateurs puissent directement demander l'accès à tel ou tel fichier individuellement.
[^] # Re: Pas trop étonné
Posté par SaintGermain . Évalué à 1.
Cela me semble très fragile comme méthode (ne serait-ce que pour tester que les backups sont corrects, il faut tout rapatrier non ?).
Et tu chiffres le fichier qui représente le snapshot juste avant l'envoi, ou bien le snapshot est déjà chiffré (je ne sais pas comment ZFS gère le chiffrement).
Tu as un exemple quelque part de quelqu'un qui effectue cela en pratique ? Cela m'intéresse…
Merci
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . Évalué à 2.
J'ai utilisé ce genre de méthode sur des machines solaris (mais sans la partie chiffrement) dans divers cas :
-dumps de bases de données
-sauvegarde de données alfresco
Faut savoir que des grosses instances alfresco, ça peut vite représenter des millions de fichiers avec beaucoup qui font moins de 1k. Avec un accès au fichier "standard" un backup est beaucoup trop long (faut oublier de faire un ls aussi). Du coup les sauvegardes à base de snapshot et d'envoi de snapshot sont très pertinentes dans ce cas. Le corrolaire c'est que tu ne peux pas restaurer un fichier individuellement mais c'est de toute façon pas un cas qui s'applique étant donné que la gestion de version fait partie du logiciel, la sauvegarde n'a de sens que pour se prévenir d'une panne/corruption de données.
L'intérêt c'est essentiellement l'instantanéité d'un backup par snapshot associé à la capacité de les envoyer à distance et ce même sous forme incrémentale.
Quelques autres exemples de cas d'usages, scripts ou outils se basant dessus :
http://royal.pingdom.com/2013/06/04/zfs-backup/
https://www.grendelman.net/wp/fast-frequent-incremental-zfs-backups-with-zrep/
http://mij.oltrelinux.com/devel/zfsbackup/
http://www.rsync.net/products/zfsintro.html
http://www.daveeddy.com/2015/12/05/automatic-zfs-snapshots-and-backups/
http://www.znapzend.org/
[^] # Re: Pas trop étonné
Posté par SaintGermain . Évalué à 3.
J'ai parcouru tes liens et si je ne me trompe pas, seul le 3e lien (zfsbackup) n'exige pas que la machine où on envoie les backups soit aussi avec un filesystem ZFS. Les autres utilisent "ZFS send" et nécessite que le FS qui reçoit soit aussi en ZFS.
Pour zfsbackup, il fait un gros gzip du snapshot et envoie le tout (!).
Et cela semble conforme à ce que tu dis, il n'est pas possible de restaurer un fichier individuellement, il semble que l'on doit rapatrier tous les snapshots (le complet + les incrémentaux).
Je vois bien l'intérêt des snapshots (j'utilise cela aussi avec Btrfs) mais j'avoue que je suis très très dubitatif sur le fait d'envoyer les snapshots sur une machine qui n'est pas elle-aussi en ZFS. Cela ne me semble utilisable que dans des cas très particuliers (par exemple le cas que tu décris) car les contraintes et inconvénients sont quand même sacrément limitants.
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . Évalué à 3.
Oui parce que c'est plus commode et que cela permet en même temps de valider l'intégrité des données. Mais ce n'est pas obligatoire en tant que tel si le seul but est de pouvoir faire du disaster recovery par exemple.
Faut voir ça comme une méthode d'externalisation des données à moindre coût, un peu comme quand on dupliquait des bandes magnétiques et qu'on les envoyait sur un autre site, un coffre fort de banque ou autre. C'est aussi valable pour de l'archivage. Quand t'envoies tes données sur Amazon Glacier par exemple, tu ne t'attends pas à pouvoir les restaurer à la minute non plus.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.