Journal Les sauvegardes, et les logiciels de sauvegarde

Post√©¬†par¬† . Licence CC¬†By‚ÄĎSA.
√Čtiquettes¬†:
14
7
mar.
2015

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¬† . √Čvalu√©¬†√†¬†10.

    dans ton hypothese tu reinstalles un systeme de base sans les données

    1. ce n'est pas le systeme qui coute cher à sauvegarder/reinstaller, ce sont les données
    2. tes bases de données de 79Go de SAP (la vie de la société), tu les sauvegardes comment ?
    3. il se passe quoi avec ton systeme qui fait des reinstallation/reconfiguration, si ton linux debian 5 sur lequel tourne un logiciel ultra specifique qui ne peut pas etre migré vers debian 6 ou se plante (machine morte/disques morts). Tu as gardé des mirroirs de debian 5 pour reinstaller à l'identique ? ou tu vas tenter une mise à jour vers debian 7

    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¬† . √Čvalu√©¬†√†¬†1. Derni√®re modification le 07/03/15 √† 09:29.

      1. Et parceque ça coute moins cher (qu'un sujet non abordé dans le journal car évident) on continue de faire ? C'est moins cher que les data mais bien plus cher que de s'appuyer sur le serveur de déploiement \o/
      2. Bonne question : tout ce qui n'est pas éditeur système est sauvegardé, les apps dont le déploiement est mal fichu sont dans ce cas.
      3. pareil que sur un parc √†lapapa o√Ļ on d√©pense sans compter en stockage pour de la sauvegarde syst√®me. l√†, on d√©pense en comptant.

      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¬† . √Čvalu√©¬†√†¬†5. Derni√®re modification le 07/03/15 √† 10:17.

        pour simplifier je dirais que

        • dans le cas du dump tu vais

          • 1 manip de backup (la machine)
          • 1 manip pour la restauration
        • alors que dans ton cas :

          • 1 manip pour la reinstallation du syst√®me
          • 1 manip pour la reinstallation de la configuration
          • 1 manip pour la reinstallation des donn√©es

        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¬† . √Čvalu√©¬†√†¬†0. Derni√®re modification le 07/03/15 √† 10:25.

          pour simplifier je dirais que
          dans le cas du dump tu vais
          * 1 manip de backup (la machine)
          * 1 manip pour la restauration

          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.

          de plus, il se passe quoi, avec ton systeme de backup, si ta machine se voit ajouter une fonctionnalité en cours d'usage.

          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)

          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)

          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.

          J'ai bon, ou je suis à coté de la plaque ?

          Complètement dans le sujet. Merci à toi !

          je dirais que l'argument de la sauvegarde systematique du systeme c'est le gain de manip par rapport au prix du stockage.

          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¬† . √Čvalu√©¬†√†¬†10.

          de plus, il se passe quoi, avec ton systeme de backup, si ta machine se voit ajouter une fonctionnalité en cours d'usage ? […]

          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 :

          • √Čcrire les templates de fichier de configuration pour le nouveau logiciel/service
          • Mettre √† jour le script Chef/Puppet/Salt/Ansible de d√©ploiement
          • Tester le script sur une VM (vagrant est votre ami)
          • Commiter les modifications dans le d√©p√īt git/svn/whatever contenant le scripts de d√©ploiement
          • Lancer le d√©ploiement du script sur la machine de prod

          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 :

          • √áa √©vite de casser la machine de prod parce qu'on s'est vautr√© dans la config de tel logiciel
          • Ce qu'on a fait est act√© et document√©
          • On pourra r√©installer tr√®s facilement la machine ou la mettre √† jour
          • On pourra installer une deuxi√®me machine √† l'identique pour faire des tests ou scale-out
          • On √©vite d'accumuler de la dette technique
          • [^] # Re: probleme de version ?

            Post√©¬†par¬† . √Č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¬† . √Č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¬† . √Č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¬† . √Č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¬† . √Č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¬† . √Čvalu√©¬†√†¬†0.

      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.

      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¬† . √Čvalu√©¬†√†¬†-3.

        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,

        On préférera le terme d'orchestration.

    • [^] # Re: Et aussi les donn√©es

      Post√©¬†par¬† . √Čvalu√©¬†√†¬†7.

      L'overhead est d√©mentiel, mais en '15 justement, le co√Ľt n'est pas proprotionnel.

      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¬† (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¬† . √Čvalu√©¬†√†¬†0.

      le jour o√Ļ le gus a perdu le contenu de /repertoireimprobable,

      "/repertoireimprobable" n'est pas sur le contrat de sauvegarde, qu'il assume ses propres conneries.

      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.

      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.

      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.

      Je vais me pencher sur ce bon vieux cfengine, il serait temps.

      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…)

      Pareil

      • [^] # Re: Tout d√©pend des postes

        Post√©¬†par¬† . √Č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¬† . √Čvalu√©¬†√†¬†2. Derni√®re modification le 07/03/15 √† 11:52.

          Une "augmentation de la volumétrie", c'est à peu près inévitable dans toute entreprise qui travaille

          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¬† . √Č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¬† . √Čvalu√©¬†√†¬†7.

        le jour o√Ļ le gus a perdu le contenu de /repertoireimprobable,

        "/repertoireimprobable" n'est pas sur le contrat de sauvegarde, qu'il assume ses propres conneries.

        ç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¬† . √Čvalu√©¬†√†¬†10.

    Ton journal me fait penser au débat images vs recettes :

    • Images : On fait une image compl√®te du syst√®me install√© que l'on restaure en cas de besoin
    • Recettes : On cr√©e des scripts d'installation/configuration capables d'installer un serveur √† l'identique

    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¬† . √Čvalu√©¬†√†¬†1. Derni√®re modification le 07/03/15 √† 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¬† (site web personnel) . √Čvalu√©¬†√†¬†6.

      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.

      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¬† . √Č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¬† . √Č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¬† . √Čvalu√©¬†√†¬†4. Derni√®re modification le 07/03/15 √† 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¬† (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¬† . √Čvalu√©¬†√†¬†3.

          Tiens je ne le connaissais pas backuppc ca à l'air sympa je vais regarder ça plus en profondeur :)

          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¬† . √Č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¬† . √Č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¬† . √Čvalu√©¬†√†¬†0. Derni√®re modification le 07/03/15 √† 20:52.

      ton analyse est un peu précipitée
      c'est 90% de blabla/dénigrement

      Oui, tout à fait :-) Un gros troll, ça faisait longtemps, il a eu le temps de bien moisir \o/

      compression/dedup

      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.

      loin de fonctionner pour tout le monde.

      Pourquoi ? Quels freins exactement ?

      • [^] # Re: Nope

        Post√©¬†par¬† . √Č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¬† . √Č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.