Cher Nal,
Le coup de gueule du vendredi samedi matin : JE HAIS LES SAUVEGARDES SYSTEMES
Ouf, ça va mieux.
Nous sommes en 15, et certains, trop nombreux, se paluchent encore comme s'ils étaient au siècle dernier : « moi ze fais des sauvegardes totales toutes les semaines et incrémentales tout les jours » se la comparent : « moi z'utilise netbackshut(tm) c'est mieux que timeperduator(tm) » … « moi ze suis un vrai, z'utilise dump & restore » … « moi z'est un fs zintellizent » et se la racontent : « zai restôré 70Go en 1mn30 avec mon link fiber »
Quelle peut en être la vraie raison ?
- Ils ne se comprennent pas entre eux et utilisent de mauvais mots ou de mauvaises définitions ?
- Ils se trainent des habitudes d'un système fermé, difficile et long à installer ?
- Ils font partie du grand complot des vendeurs de stockage ?
- Ils sont justes cons ?
Est ce qu'une seule personne à un seul argument valable pour faire des sauvegardes d'un système gnu/linux ? Et toi cher Nal< : as tu déjà rencontré en vrai un argument qui tienne la route ?
Allons y par l'exemple : Soit un système standard (soyons le plus simple possible dans nos exigences pour notre prévisionnel) : 20Go. Parceque le but d'un système c'est pas de faire joli mais de rendre un service (on reviendra sur ce point). 20Go c'est déjà beaucoup, mais ça inclus l'ensemble des possibilités de service, du plus petit ou plus gros : un système qui serve de base pour tout les usages (une sonde réseau qui ne pourrait faire que 400Mo jusqu'au serveur sap qui fait 70Go (hors data bien sûr), je n'aime pas la dentelle, je déteste la haute-couture, une seule base système pour tout le monde la même, et en plus ce n'est pas ici comme ça qu'on gagne de l'espace). Bon, 20Go.
Sur lequel ces gens là, messieurs vont coller 1 sauvegarde complète par semaine, avec une rétention de sauvegarde à 1 mois. Classique, standard, la paluchade est de bonne qualité en réunion. Nous voilà avec 100Go. Ils vont y ajouter une sauvegarde incrémentale par jour, ce qui nous donne une … variabilité. Je t'ai dit, cher Nal<, que pour parler pognon je déteste les variables ?
On va être sympa, on ne vas pas compter les moments de mises à jour système, et lisser le tout à un arrondi à 120Go. Nous sommes donc, en étant gentillou, sur un rapport x6. On mettra un voile pudique sur les tarés qui croient bien d'ajouter un .vmdk de "sauvegarde" "au cas où" en plus de ça, pour des vm, donc sans avoir vraiment définient de politique, du coup. On ne discutera pas RAID matériel ici, par contre, pour savoir si c'est encore d'actualité ou pas, là encore on sera gentil, et on comptera les 20Go de stockage initiaux comme 40Go de productif.
Donc 40Go de productif -> 120Go d'occupation sur le S.I (40? on compte le raid on a dit) Pas pour des données, pour un système. Multiplie ça par ton nombre de serveur (100 ? 1000 ? 10000 ? Plus ?) Met un zest de maintenance matérielle, fait ton calcul d'historique de pannes.
Revenons sur la notion de "rendre un service".
La sauvegarde rends le service de restauration. Pas celui de sauvegarde, qui n'est qu'une dépendance nécessaire à l'objectif. « C'est con, hein, ces objectifs ». Donc "restauration", mais de quoi ? De service ! « Mais qu'il est con ! » Donc en cas de défaillance, pouvoir avoir un service fonctionnel rapidement, sans perte. « ça y est, on a perdu les trois quarts des palucheurs professionnels de réunionites aïgues » Les défaillances peuvent être d'ordre multiples, et là nous jetterons une burka pudique sur un système vérolé avant la dernière rétention de sauvegarde, ou de process de vérifications régulières qui ajoute de l'espace nécessaire : que des choses simples on a dit !
Bon voilà l'objectif demandé aux "moyens généraux" par les usagers. Avoir une restauration du service. Ouffff on y est arrivé.
Nous, icitte, nous utilisons des systèmes qui proposent aussi des serveurs de mises à jour, des outils de déploiement et des logiciels de gestion de version, et plein d'autres trucs très sympa. Ma sauvegarde système tient sur 20Mo. Et ça, c'est un système complexe. 20 MEGA-OCTETS. Le reste est mutualisé à tout les serveurs via un service d'installation automatisé qui déploient les systèmes et les dernières mises à jour éditeur disponibles. Donc toutes mes sauvegardes systèmes tiennent sur :
- 180Go de paquetages synchronisés avec l'éditeur de la distribution utilisée, pour toutes les machines ;
- 20*ko* de spécificités d'installation, par machine ;
- 10*Mo* de données de configurations, par machine
Une restauration de service prends 20 minutes. Une seule procédure pour tout les cas de figure. Un seul reboot. C'est prêt.
Alors, cher Nal< : quel est l'intérêt de faire des sauvegardes àlapapa pour des systèmes gnu/linux ? Ils n'ont vraiment rien de mieux à faire de leur argent que d'acheter du stockage pour les systèmes alors que les données en ont tellement plus besoin ? N'ont ils n'ont pas conscience du pognon jeté par la fenêtre ?
Vous pouvez moinsser :-)
# probleme de version ?
Posté par NeoX . Évalué à 10.
dans ton hypothese tu reinstalles un systeme de base sans les données
du coup tes packages synchronisés avec l'editeur avec toutes les variantes de debian depuis la 5 (soit 3 ans), plus la meme chose pour du centos ou du suse, plus les packages de logiciels speciaux, ca te prend combien ?
[^] # Re: probleme de version ?
Posté par bubar🦥 (Mastodon) . Évalué à 1. Dernière modification le 07 mars 2015 à 09:29.
Donc, on recherche toujours un argument valable qui tienne la route pour la sauvegarde systématique de système gnu/linux.
[^] # Re: probleme de version ?
Posté par NeoX . Évalué à 5. Dernière modification le 07 mars 2015 à 10:17.
pour simplifier je dirais que
dans le cas du dump tu vais
alors que dans ton cas :
je dirais que l'argument de la sauvegarde systematique du systeme c'est le gain de manip par rapport au prix du stockage.
de plus, il se passe quoi, avec ton systeme de backup, si ta machine se voit ajouter une fonctionnalité en cours d'usage ?
ton puppet/chef/cfengine a besoin d'etre modifier pour que la restauration ajoute ces paquets,
ton backup de config a besoin de se voir ajouter les fichiers/dossiers de configuration de ces nouveaux paquets
avec le backup snapshot/dump,
tu ne change rien, tu continues à faire des backups comme d'hab,
ton backup aura alors une version avant le 7 mars (sans mailman et postfix) et une version apres le 7 mars (avec mailman et postfix)
J'ai bon, ou je suis à coté de la plaque ?
[^] # Re: probleme de version ?
Posté par bubar🦥 (Mastodon) . Évalué à 0. Dernière modification le 07 mars 2015 à 10:25.
Dans ce cas où un seul système de sauvegarde s'occupe du système et des données : soit tu restores des parties dont tu n'as pas besoin (par exemple des données non corrompues, au lieu de rétablir le lien vers elles) soit tu as une manip de choix de ce qu'il faut restorer. Donc analyse préalable et manip en plus. Ce qui est dans tout les cas : soit plus long soit demandant des manipulations qui varient à chaque fois. Et comportent une incertitude si manips spécifiques.
C'est la vie d'un administrateur système préférant faire des fonctions plus intéressantes (Mais au final on baisse le nombre d'admins. Plus de clicks-boutons mais moins d'admin, mais ça coute moins cher)
C'est une partie du problème, en effet : il serait stupide et utopique de croire que les services d'un système sont figées dans le temps. Nous ne sommes pas dans un monde idéal. Là encore, la gestion de conf joue son rôle, pour ces systèmes qui évoluent en fonctions.
Complètement dans le sujet. Merci à toi !
C'est le coeur de la question. Surtout que le stockage de sauvegarde coûte bien plus cher que l'archivage de données >_O où la sauvegarde n'est qu'une étape transitoire et fonctionnelle.
[^] # Re: probleme de version ?
Posté par X345 . Évalué à 10.
Non, vraiment, vraiment, en 2015, on ne procède plus comme ça. C'est un tel nid à emmerdes d'intervenir directement sur une machine sans que ce soit documenté. Je sais que c'est chiant de changer, que ça prend du temps, et que dans certains cas les scripts sont vraiment longs à écrire mais faut vraiment arrêter d'intervenir au petit bonheur la chance sur les machines de prod.
Donc, la bonne manière de faire en 2015, pour ajouter une fonctionnalité à une machine, c'est :
Oui, c'est un peu plus long (mais vraiment, une fois que les process sont en place, c'est moins de 25% plus long) que d'intervenir directement sur la machine mais :
[^] # Re: probleme de version ?
Posté par MTux . Évalué à 5.
Non mais sérieusement, tu as déjà fait ce que tu décris ?
Parce que par expérience on a beau tester 10x sur des VMs avec plein de confs différentes, il y a toujours des couilles à la mise en prod…
[^] # Re: probleme de version ?
Posté par X345 . Évalué à 10.
Oui y'a toujours, toujours des couilles à la mise en prod. Toujours. Y'a aussi toujours, toujours des couilles quand on monte en charge. Toujours.
C'est pas parce qu'un test ne permet pas de détecter 100% des bugs qu'il ne faut pas le faire. Si y'a mettons 5 bugs qui vont se déclencher lors de l'ajout de la fonctionnalité, le test dans une VM permettra peut-être d'en détecter 2. Si on a une machine de pré-prod, on arrivera peut-être à en attrapper encore 2 supplémentaires. Ça fait un gros gain en termes de disponibilité.
Parce que clairement, si t'intervient directement sur le serveur de prod à l'arrache, tu vas le rendre indisponible pendant des heures. Sans compter qu'une fois que tu auras résolu les cind bugs, on plus personne ne saura ce que t'as fait. La prochaine fois qu'on installera le même logiciel sur une autre machine, on se retapera les heures d'indisponibilité et le temps de résolution des bugs. Ça n'arrivera pas avec un script de déploiement.
[^] # Re: probleme de version ?
Posté par Anonyme . Évalué à 2.
tu travail chez voyages-sncf.com ?
[^] # Re: probleme de version ?
Posté par FrogX . Évalué à -1.
C'est un peu pour ça que docker réussit en ce moment … test en preprod déploie en prod …. vu que c'est le même système ça marche de la même manière ….
[^] # Re: probleme de version ?
Posté par groumly . Évalué à 2.
D'ou les concepts d'immutabilite des environments: tu ne modifies pas une vm, t'en crees n nouvelles et tu balances les n anciennes.
Aussi, d'ou la necessite de ne pas penser en terme de prod vs pas prod. Les environements sont tous crees de la meme facon, il se trouve juste que l'un d'entre eux recoit du traffic public.
Et non, c'est pas simple a mettre en place, mais c'est pas non plus incroyablement complique.
Ca ne s'applique pas a 100% des services non plus (une db va etre plus complique a traiter de cette facon), mais ca resoud tres bien le probleme pour la majorite de l'environement.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Et aussi les données
Posté par Graveen . Évalué à 5.
Disons que oui, tu as raison dans le cadre du système. L'overhead est démentiel, mais en '15 justement, le coût n'est pas proprotionnel.
Moi ce qui me bloque ce sont les données, qui sont plus importantes que le système. Et dans le cas de systèmes bien relous, je ne suis pas certain que ce soit scriptable simplement (dépendances foireuses, versions bien précises, interactions de services à régler…).
Parce que finalement, ta solution, c'est un script d'installation apt et la sauvegarde de /etc: efficace, utile, mais pas forcément pertinent sur tous les cas (par exemple un paquet moisi qui a changé toute les dépendances).
[^] # Re: Et aussi les données
Posté par groumly . Évalué à 0.
Le probleme c'est pas tant le cout, ca indique une mauvaise approche de la gestion de ses environements, la solution a ce probleme, c'est l'automation, chef, puppet, mesos, ce que tu veux, tant que les humains se contentent de cliquer sur un bouton "ajoutes 2 instances a cette appli". Et tu resouds le probleme de la montee/descente en charge de facon tres efficace au passage. Tu peux creer des environement de dev en 2 clics (et donc utiliser l'espace disque que t'as economise).Tu t'en fout si une vm canne, le systeme se repare tout seul.
Apres reste les donnees, mais il a bien precise qu'il ne parlait pas de ca.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Et aussi les données
Posté par Le Gab . Évalué à -3.
On préférera le terme d'orchestration.
[^] # Re: Et aussi les données
Posté par Dring . Évalué à 7.
En, 2015, c'est toujours la misère pour avoir l'espace disque dont on a besoin pour déployer/faire vivre des applications. Même dans des entreprises qui gèrent des Peta-octets de données.
Ton approche est aussi pernicieuse que celle des développeurs qui réservent un buffer de 2 Go au démarrage de l'appli car en 2015, on n'est plus à ça près. Et après, on se rend compte que la machine n'a plus assez de RAM pour accueillir toutes les applications prévues, et on doit faire une intervention pour ajouter de la mémoire à un serveur qui a 128 Go et qui héberge 10 malheureuses applications web.
Fonctionner à l'économie, c'est le réflexe de tout informaticien bien constitué ; que ce soit économie d'efforts ou de moyens.
# Tout dépend des postes
Posté par Xavier Teyssier (site web personnel) . Évalué à 5.
Mmmm… Ça dépend de ce que tu sauvegardes comme système Linux.
Si ce sont des machines d'utilisateur qui ont un accès root, alors la sauvegarde de / est rapidement nécessaire.
Parce que le jour où le gus a perdu le contenu de /repertoireimprobable, tu pourras râler autant que tu veux sur le fait que c'est inadmissible de foutre des données là-dedans, mais ce qui compte vraiment, c'est de pouvoir le lui restaurer pour minimiser l'impact pour le projet.
Et là, le calcul est vite fait : les quelques Gigas supplémentaires que coûtent ces sauvegardes sont négligeables par rapport à ce serait-ce qu'une journée de dev perdue pour cause de non respect de règles d'utilisation de la machine.
Pour les systèmes en prod les mieux gérés où personne ne se connecte en root, je n'ai tout simplement pas de sauvegarde directe de ces serveurs. Juste des outils capable de les réinstaller à base de fichiers Kickstart et de règles cfengine. Les configurations et données propres au système de cette machine ne sont pas déposés sur cette machine, mais sur des serveurs en amont avec lesquels cette machines se synchronisera.
Quant aux quelques serveurs en amont, on a des sauvegarde de leur données. Et des docs pour les ré-installler manuellement ci-besoin (et une sauvegarde de leur /, mais c'est historique, n'a jamais servi, et n'a pas vocation à servir…).
[^] # Re: Tout dépend des postes
Posté par bubar🦥 (Mastodon) . Évalué à 0.
"/repertoireimprobable" n'est pas sur le contrat de sauvegarde, qu'il assume ses propres conneries.
Vite fait mais mal fait. Car vue globalement on se retrouve avec une augmentation de la volumétrie, donc une augmentation du coût d'achat, du coût d'entretien et du coût d'administration, tout ça pour palier à un non respect des règles d'usages.
Je vais me pencher sur ce bon vieux cfengine, il serait temps.
Pareil
[^] # Re: Tout dépend des postes
Posté par Antoine . Évalué à 4.
C'est un peu surréaliste ces réponses. Une "augmentation de la volumétrie", c'est à peu près inévitable dans toute entreprise qui travaille (et qui ne jette pas ses données au petit bonheur la chance). Tout comme les utilisateurs qui ne respectent pas "les règles" à 100%, et dont le travail est tout de même important à protéger (sans compter qu'il peut y avoir de bonnes raisons pour ne pas respecter "les règles", genre un logiciel tiers qui ne les respecte pas).
À lire tout ça, j'ai l'impression de replonger dans le bon vieux monde des sysadmins bornés d'il y a 15 ans… où il faudrait que les utilisateurs surtout ne fassent rien, pour ne pas leur compliquer la vie.
[^] # Re: Tout dépend des postes
Posté par bubar🦥 (Mastodon) . Évalué à 2. Dernière modification le 07 mars 2015 à 11:52.
Tu as besoin de la précision : augmentation de la volumétrie de sauvegarde, causant une augmentation des coûts d'achat de maintenance et d'administration. Personne ne dit rien d'autre que ça. Certainement pas "que les utilisateurs surtout ne fassent rien", qui n'as rien à voir. Personne aujourd'hui ne veut payer pour des trucs inutiles : consacrer une partie de son stockage pour des sauvegardes système, comme faisait papa avec son système fermé et long à installer, au lieu de le donner aux utilisateurs (ou de l'économiser), et à leurs datas, ça c'est du sysadmin borné d'il y a 15 ans.
[^] # Re: Tout dépend des postes
Posté par X345 . Évalué à 5.
Je suis pas sur que l'augmentation des coûts engendrée par l'augmentation du volume des sauvegardes soit vraiment significative. Regarde, dans 4TB (capacité standard d'un disque 3.5", on fait pas les sauvegardes sur du SAS 10K, enfin je me méfie ;-) ), on peut déjà stocker 200 partitions de 20Go. Un disque de 4TB, ça coute ~200€ HT, donc vraiment négligeable pour une entreprise.
Je pense que le vrai problème derrière les sauvegarde "images", c'est que ça encourage le "vite fait, mal fait". On ne documente plus les procédures d'installation, on ne les automatise pas non plus. C'est comme ça qu'on finit avec une CentOS 5 que personne ne peut mettre à jour ou réinstaller parce qu'on a plus aucune idée de ce qui tourne dessus, et de comment ça a été installé. Comme ça qu'on finit avec un rootkit qui vit pendant des années sur les serveurs de la boite.
Clairement, vaut 1000 fois mieux avoir des scripts Puppet/Chef/Ansible/Salt à jour qu'une tétrachiée d'images dont on sait à peine ce qu'elles contiennent. On peut facilement mettre à jour (on change la distribution dans le script, on teste sur une machine de pré-prod, on fixe les bugs, on déploie la nouvelle version) et si la machine a été compromise, on fixe la faille de sécurité, et on déploie un "système" neuf et propre ou on est sur qu'il n'y a pas de rootkit qui tourne. Pareil lorsqu'il y a un bug, c'est beaucoup plus facile de passer en revue ce qui est installé et les fichiers de configuration si on a un script de déploiement automatique. Non, vraiment, c'est une bonne pratique d'avoir des scripts d'installation automatiques.
Ton message parlant de "contrat de sauvegarde" a été moinssé et pourtant tu es dans le vrai. Le "/repertoireimprobable" n'a pas lieu d'exister. Comment on fait au bout de 5 ans quand tout le monde s'est installé un peu comme il veut sur la machine et créé des arborescences sans rien documenter ?
[^] # Re: Tout dépend des postes
Posté par Psychofox (Mastodon) . Évalué à 7.
ça ne marche que si tu as l'appui de ta direction sur ce point. Ce n'est pas toujours le cas.
C'est d'ailleurs la même chose pour le principe des backups systèmes. Si la direction les veut et n'accepte pas tes arguments, tu les fais quand même. Et au final, ce n'est pas très dommageable parce que :
-la déduplication, ça existe et est maintenant très utilisé : le calcul dans ton post initial est du coup complètement foireux.
-le volume des système doit pas dépasser 2 à 3% du volume des backups. Donc au final, que ce soit sur un plan comptable ou au niveau de l'infrastructure, c'est négligeable.
Dernier point, dans plein de boites où le nombre de serveurs est important >500 je dirais, le travail d'administration système est scindés en plein d'équipes différentes. Ce ne sont pas forcément les mêmes qui gèrent la configuration des serveurs et la politique de backup. Et comme chacun le sait plus la boite est grosse plus c'est le bordel pour que les gens s'entendent et s'accordent sur beaucoup de sujets.
Un dernier point est le problème de gestion des exceptions. Si tu dois avoir une politique de sauvegarde pour les serveurs "standards" bien gérés selon les best practices (pas de changements manuels sur les serveurs, uniquement de la gestion de config, pas de droits admins aux utilisateurs tiers, etc) et une autre pour les serveurs "dégueux", tu as toujours le risque d'en avoir un qui a été mis dans la mauvaise case (parce que oubli, parce que mauvaise information, etc) et que du coup tu te trouves dans la merde un jour. Des fois c'est plus simple et moins dangereux de faire du "bête et méchant" partout que de devoir gérer 1000 exceptions.
Bref je comprends tes arguments, mais ce n'est pas toujours applicable ni du ressors du sysadmin.
# Images vs Recettes
Posté par X345 . Évalué à 10.
Ton journal me fait penser au débat images vs recettes :
La question que tu poses, c'est est-ce qu'en 2015, il y a encore des raisons valables de préférer les images aux recettes ?
Peut-être que dans certains cas, le temps de restauration d'une image est inférieur au temps de réinstallation d'une machine via une recette. Peut-être que dans certains cas, 20 minutes, c'est trop et que restaurer le l'image via le réseau 40Gb/s est plus rapide. Tu noteras que ça fait beaucoup de peut-être.
Sinon je pense que la raison principale pour laquelle les images sont encore utilisées est le poids des habitudes, et le confort du non-changement, comme d'habitude.
[^] # Re: Images vs Recettes
Posté par bubar🦥 (Mastodon) . Évalué à 1. Dernière modification le 07 mars 2015 à 10:33.
Complètement, je pensais rebondir sur tout ce que les admins et les décideurs ont encore à apprendre de l'organisation des logiciels libres pour s'en inspirer, mais pas aussi bien résumé en faisant ce parallèle.
[^] # Re: Images vs Recettes
Posté par rakoo (site web personnel) . Évalué à 6.
Dans ce cas-là, dès que tu mets à jour la recette tu prépares une image que tu peux déployer directement et que tu gardes bien au chaud à côté des recettes. De toute façon si ta procédure de backup est bien faite, tu devras préparer cette image pour la tester; autant la garder après la phase de test (mais, contrairement aux recettes, tu peux te permettre de ne garder que la dernière version).
Je ferais même un autre parallèle avec le logiciel qu'on versionne: vaut-il mieux sauvegarder la recette ou le produit fini ? Ça fait un bail qu'on a la réponse à cette question, et on commence doucement à porter ça vers le monde de l'administration système avec les Ansible/Puppet/Chef d'aujourd'hui et les Nix/Guix/MirageOS de demain.
# Déduplication
Posté par Prosper . Évalué à 9.
Pour les choses inutiles et redondantes que les gens sauvegardent 42000 fois , on a inventé un truc simple , la déduplication.
[^] # Re: Déduplication
Posté par Adrien . Évalué à 5.
Typiquement avec backuppc, on sauvegarde plus de 100 To de données sur seulement 17To de disque. C'est tip top.
[^] # Re: Déduplication
Posté par Chris K. . Évalué à 4. Dernière modification le 07 mars 2015 à 14:18.
Tiens je ne le connaissais pas backuppc ca à l'air sympa je vais regarder ça plus en profondeur :)
Pour ma part j'utilise rsnapshot qui permet de définir facilement des intervalles entre chaque snapshot - c'est du cron tout bête - et de ne pas dupliquer les fichiers tout en ayant des répertoires navigables : les fichiers non modifiés sont hard linkés sur le snapshot précédent. C'est plus adapté aux données qu'au système même si rien n’empêche de l'utiliser pour cela.
[^] # Re: Déduplication
Posté par madhatter (site web personnel) . Évalué à 1.
Je ne connais pas rsnapshot, mais ce que tu décris est très ressemblant à ce que fait backuppc. ;)
There is no spoon...
[^] # Re: Déduplication
Posté par Larry Cow . Évalué à 3.
Pour de la petite/moyenne sauvegarde PMEsque, ça a été ma grande découverte de 2014. Ils ne communiquent pas des masses, c'est sans prétention, mais ça fait super-bien le job.
[^] # Re: Déduplication
Posté par Adrien . Évalué à 2.
Perso nous l'utilisons depuis 2010, dans un contexte d'une centaine de personne, pour 250 machines à sauvegarder.
Ça fait très bien le boulot, c'est fiable et sécurisant, très facilement redondable, mais les sauvegardes sont longues sur les postes client, et la machine de sauvegarde est très sollicitée au niveau des disques.
Perso j'en suis très content les évolutions sont assez faibles, ce qui est parfait pour ce genre d'outils ! Je compte bien le garder encore quelques années.
# Nope
Posté par MTux . Évalué à 10.
Donc ce que tu fais n'est valable que pour sauvegarder des serveurs Linux, et comment tu fais quand c'est un serveur de fichiers de 2 To ? Messagerie ? Base de données ? En sachant que 95% des opérations de restauration sont pour un utilisateur qui a écrasé par erreur des fichiers (il faut donc parfois remonter à un mois pour retrouver la version avant l'écrasement accidentel).
De plus beaucoup de solutions "classiques" ou propriétaires font de la compression/dedup, donc ton analyse est un peu précipitée. Elles intègrent aussi des connecteurs pour les bases de données / serveurs de messagerie.
En débutant la lecture du journal je pensais trouver des astuces intelligentes mais c'est 90% de blabla/dénigrement et 10% de description d'une solution limitée qui sera loin de fonctionner pour tout le monde.
[^] # Re: Nope
Posté par bubar🦥 (Mastodon) . Évalué à 0. Dernière modification le 07 mars 2015 à 20:52.
Oui, tout à fait :-) Un gros troll, ça faisait longtemps, il a eu le temps de bien moisir \o/
Merci d'aborder ce point \o/ Deux commentaires au dessus le font aussi. C'est de l'optimisation, le service minimal de nos jours (et encore, je suis sûr que nous sommes nombreux à voir encore des solutions n'assurant pas ça), et qui se paie par une administration fastidieuse, quant elle ne mobilise pas des personnels complètement, et un service à restauration inférieur en qualité, plus long.
Le tout sans ôter le gaspillage de stockage. En le réduisant, même drastiquement. Donc on a toujours, cette fois sans exagération, du gaspillage d'un côté et un temps plus long à la restauration de service d'un autre. (mon service est pas encore rétabli ? atttta je ré-hydrate les fichiers système…)
Les systèmes gnu/linux peuvent s'affranchir de sauvegarde. Seules leurs configurations, et leurs données sont importantes.
Pourquoi ? Quels freins exactement ?
[^] # Re: Nope
Posté par jolitorax . Évalué à 3.
Avoir un système qui fait de la déduplication n'empêche pas de choisir finement ce que l'on doit sauvegarder.
Les facteurs limitant pour la sauvegarde, c'est le stockage et le réseau. Et non, changer toute l'infra pour avoir des connexions 40Gb/s partout n'est généralement pas envisageable. Quand à penser qu'ajouter un disque de 4 To, c'est trop facile et ça coûte peanuts, ben non plus. Le coût au To est bien plus élevé que ça. Enfin vu le budget que coûte une infrastructure de sauvegarde, on ne la change pas toute les semaines et ses habitudes avec, juste pour faire hype.
Donc quand réseau et stockage sont contraint ce qui est souvent le cas, on fait de la déduplication et la sauvegarde à mailles fines. Et quand on viendra nous dire "hé, les gars, le système de backup n'a quasiment plus de fenêtres de sauvegarde, il tourne 22 heures sur 24" ben on trouvera des solutions pour optimiser, parce que changer le matos (et le logiciel) ce n'est pas vraiment possible.
# Mouai
Posté par Marotte ⛧ . Évalué à 2.
Dans le cas d'une mauvaise manipulation ça va nettement plus vite de restorer un fichier que la VM entière ou que de réinstaller… Je pense notamment aux phases d'intégration et de développement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.