Journal De l'importance (des tests réguliers) des sauvegardes

Posté par (page perso) . Licence CC by-sa
Tags : aucun
23
1
fév.
2017

Journal bookmark sur le merdier en cours chez GitLab…

https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub#h.dgc3wwb1l1t6

Pour résumer : visiblement un admin sys a "nettoyé" un disque sur un serveur de prod au lieu du serveur de test qu'il croyait manipuler. Et les 5 mécanismes de sauvegarde mis en place étaient foireux…

  • # Illustration

    Posté par . Évalué à 10.

    La sauvegarde est une forme de redondance, et on a souvent tendance à penser que la redondance est la solution à à peu près tous les problèmes ("dans un avion, les calculateurs sont redondants, voire ils sont triplés ou quintuplés"). Mais les pièges sont nombreux.

    Un exemple qu'on m'avait donné qui illustre pas mal je trouve :
    Imaginons un gars (ça marche pas avec une fille) (mais siiiiii, je rigole) il a un boulot super important, il veut pas être emmerdé par sa voiture. Il a peur qu'un matin ça démarre pas (il a déjà perdu un premier job à cause d'une batterie défaillante), et pour des raisons qui lui sont propre, il ne pourrait pas aller au travail. Donc il se dit "ah bin je vais acheter une 2e bagnole, et ce serait bien le diable que les 2 tombent en panne le même jour !".

    Le temps passe, et un beau matin d'hiver, arrive ce qui devait arriver : la batterie est nase, la voiture ne démarre pas. Le gars est limite heureux parce que sa 2e bagnole lui avait coûté assez cher, il peut enfin prouver que son idée était la bonne.
    Bon, les clés… merde, je les ai mises où ? Donc déjà il perd 10mn à trouver les clés. Il sait que le plein est fait (pas bête), mais il actionne le démarreur… et ça démarre pas non plus.
    Dans cet exemple trivial les raisons sont évidentes :
    1) C'est l'hiver aussi pour sa 2e voiture (le froid est une plaie pour les batteries au plomb)
    2) De plus il s'en sert jamais, elle s'est déchargée, il avait finalement encore plus de chances que cette 2e voiture ne démarre pas

    Son idée était-elle bête ? Pas forcément, en ayant 2 voitures tu diminues effectivement grandement les chances de n'avoir aucun véhicule de disponible… à condition que les causes de défaillances soient différentes, et bien analysées en amont.

    Si déjà en ayant ses 2 voitures, il utilisait une pour les jours pairs, et l'autre pour les jours impairs, il aurait déjà éliminé le point 2) ainsi que les 10mn perdues à trouver les clés. Ensuite un chargeur de batterie c'est 50€ (tellement moins cher qu'une 3e voiture !!!), un petit coup de chargeur mensuellement sur la voiture qu'il ne prend pas ce jour-là, et c'était réglé. On peut aussi dire qu'il s'impose des révisions annuelles, mais décalées entre les 2 voitures à 6 mois d'intervalle pour éviter d'avoir 2 batteries vieilles en même temps.

    L'exemple est trivial évidemment, mais je trouve qu'il illustre pas mal le problème, et surtout dans une situation que tout le monde comprend.

    Sinon je teste pas non plus mes sauvegardes, je vous rassure :)

    • [^] # Re: Illustration

      Posté par . Évalué à 10.

      Sinon je teste pas non plus mes sauvegardes, je vous rassure :)

      Je suis rassuré :)

      Plus sérieusement, la redondance est effectivement capable de faire pire que mieux (si j'ose dire). Un exemple que j'ai vu récemment : du Proxmox en haute disponibilité. Soit trois serveurs physiques qui contiennent (mettons) 30 machines virtuelles équivalentes, réparties à parts égales (10 par serveur, pour ceux qui ont fait des maths au lycée). Tous ont la haute dispo activée, c'est à dire que si n'importe lequel des trois serveurs se vautre, les 30 machines continueront à tourner sur les deux restants. Et ça, c'est chouette.

      Là où c'est moins chouette, c'est quand tu n'as pas pensé (ou oublié, ou que ça n'a pas marché, ou que ça a arrêté de marcher sans prévenir) à monitorer l'état de ton cluster. Quand une VM tombe, tu le sais (les utilisateurs étant le meilleur système de monitoring jamais inventé), mais quand un nœud tombe pas forcément, du coup.

      Et là, donc (suspense!) un nœud tombe. La HA prend le relais, et on se retrouve avec deux nœuds de 15 machines (sans calculatrice, promis) qui ne sont plus en haute dispo. Le cluster est dégradé. Et si on reperd un nœud, ce ne sont pas 10 VMs qu'on perd, mais 15.

      Moralité n°1, ne pas faire d'alerting, c'est mal.

      Moralité n°2, sauf à vraiment avoir besoin que les services ne coupent pas (du tout), on est souvent mieux à s'éviter la HA : c'est plus simple à gérer, la récupération est certes manuelle mais dès l'apparition du problème, et on réduit d'autant la taille de l'impact.

      • [^] # Re: Illustration

        Posté par . Évalué à -4.

        Soit trois serveurs physiques qui contiennent (mettons) 30 machines virtuelles équivalentes, réparties à parts égales (10 par serveur, pour ceux qui ont fait des maths au lycée).

        Euh … Quel est l'intérêt d'ajouter une couche de virtualisation dans ce cas ? Pourquoi ne pas avoir 3 serveurs physiques ?

      • [^] # Re: Illustration

        Posté par (page perso) . Évalué à 4.

        Concernant le monitoring, je trouve que Xymon est très bien.
        La version Debian est bizarrement packagée, comme d'habitude, mais ça marche.

    • [^] # Re: Illustration

      Posté par . Évalué à 10.

      Il était une fois une carte électronique redondée, qui prend un choc électrique, dû à une alimentation défaillante, qui donc grille le spare par la même occasion.

      Il était une fois une carte électronique redondé, avec le spare éteint (froid donc) cote à cote de la première carte. Un condensateur explose, détruisant des pistes du spare froid.

      "La première sécurité est la liberté"

    • [^] # Re: Illustration

      Posté par (page perso) . Évalué à 5.

      "dans un avion, les calculateurs sont redondants, voire ils sont triplés ou quintuplés")

      En l’occurrence dans un avion la redondance doit se faire avec des équipes / entreprises différentes et bien sûre la question des risques liés aux technologies employés de chaque côté est analysé pour pas que ce soit fait pour rien. ;-)

      Cela ne résout pas tous les soucis, mais un bon paquet quand même.

      • [^] # Re: Illustration

        Posté par . Évalué à 3.

        C'est souvent le cas, mais ce n'est pas non plus systématique. J'ai vu passer des exemples où on a bien le même logiciel embarqué 2x (avec 2 comportements différents). Les analyses ont montré que c'était suffisant, c'est tout.

    • [^] # Re: Illustration

      Posté par . Évalué à 10.

      Tant qu'à illustrer illustrons :-D

      commitstrip

      kentoc'h mervel eget bezan saotred

      • [^] # Re: Illustration

        Posté par . Évalué à 10.

        Et puis une autre (j'suis chaud) qui fonctionne à merveille avec la précédente :

        commitstrip

        Et puis l'article sur developez.com qui parle de cet accident sur github

        kentoc'h mervel eget bezan saotred

      • [^] # Re: Illustration

        Posté par (page perso) . Évalué à 4.

        Sauf que les parachutistes ont une vérification annuelle (ou bi-annuelle dans d'autres pays) de leur parachute de secours ;) Et c'est justement le point de la discussion, il faut tester ses sauvegardes.

        • [^] # Re: Illustration

          Posté par . Évalué à 10. Dernière modification le 02/02/17 à 15:50.

          Souvenez vous :

          il y a 2 catégories d'admin système :

          Ceux qui ont fait une connerie avec root
          et
          Ceux qui vont faire une connerie avec root

          pour ma part c'est fait :)

          • [^] # Re: Illustration

            Posté par (page perso) . Évalué à 3.

            J'ai déjà formaté une partition avec toutes mes données non sauvegardées !!!

            • [^] # Re: Illustration

              Posté par (page perso) . Évalué à 2.

              Je ne fais des conneries que sur mes ordinateurs personnels, mais le top avait été d'effacer le MBR, et donc la table de partitions de la machine… (Je me suis trompé en rappelant des commandes d'historique alors que je voulais en faire une sauvegarde.) Cela m'a fourni l'occasion de tester TESTDISK qui a reconstruit la table sans broncher.

              • [^] # Re: Illustration

                Posté par . Évalué à 3.

                Il y a aussi l'outil gpart qui sert exclusivement à ça.
                Il est aussi sur system rescue CD, c'est là que je l'avais découvert … le jour où moi aussi j'en ai eu besoin.

            • [^] # Re: Illustration

              Posté par . Évalué à 2.

              J'ai déjà formaté une partition avec toutes mes données non sauvegardées !!!

              Moi j'ai carrément redescendue une image vierge sur un serveur de production (croyant la redescendre sur un serveur de test, un peu ce qui est arrivé à Gitlab). Je m'en suis pas rendu compte moi-même mais avant que l'image ai fini de descendre le téléphone a commencé à sonner… Quand j'ai compris j'ai du changer de couleur. Mais heureusement il était environ 11h et la sauvegarde journalière avait lieu à 6h et était parfaitement valide. 5 h de perdues quand même.

              Ceci dit quand c'est pas moi qui ai fait l'erreur c'est des moments que j'aime bien. Il faut être super inventif, rapide, et résister à la pression (tous les téléphones sonnent sans interruption, les collègues affluent). La direction qui oublie d'habitude un peu que la technique c'est ce qui rempli nos assiettes reçoit à ce moment-là un petit rappel.

              Enfin j'aime bien mais c'est probablement parce que jusqu'à présent ces "petits" problèmes se sont toujours résolu sans drame au final.

          • [^] # Re: Illustration

            Posté par (page perso) . Évalué à 9. Dernière modification le 03/02/17 à 13:39.

            J'ai déjà déplacé une libc pour libérer de la place sur un système de fichiers (et étrangement c'est compliqué de faire un lien symbolique ensuite…).
            J'ai déjà oublié un WHERE dans une requête SQL d'UPDATE.

            • [^] # Re: Illustration

              Posté par . Évalué à 10.

              J'ai déjà oublié un WHERE dans une requête SQL d'UPDATE.

              J'ai déjà utilisé un AWHERE dans une requête Vandamme de STATUS

              Pardon je ne sais pas ce qui m'a pris d'écrire une chose pareille

              kentoc'h mervel eget bezan saotred

              • [^] # Re: Illustration

                Posté par . Évalué à 2.

                Pardon je ne sais pas ce qui m'a pris d'écrire une chose pareille

                NE te retiens surtout pas, c'est trop drôle.

            • [^] # Re: Illustration

              Posté par (page perso) . Évalué à 4.

              J'ai déjà oublié un WHERE dans une requête SQL d'UPDATE.

              Oh ça c'est pas grave puisque tu avais ouvert une transaction, n'est-ce pas ? :-)

            • [^] # Re: Illustration

              Posté par . Évalué à 2. Dernière modification le 04/02/17 à 09:34.

              Il y a bien des années quand je bossais dans le bancaire j'ai déconnecté environ 2000 guichets automatique de billets (toute une caisse ou presque) en oubliant une paire de parenthèses dans une requête qui devait purger les machines ayant été déconnecté dans la semaine.
              Le plus beau : une semaine plus tard le même script (non édité entre temps) a été relancé par mégarde par une autre personne du service.
              Seul point positif, la seconde remise en route a été bien plus rapide, car bien entendu la première fois on s'est rendu compte que la méthode de sauvegarde posait certains problèmes lors de la restauration. Un logiciel gérant les COMMIT et la coloration syntaxique a aussi enfin été installé sur nos postes.

          • [^] # Re: Illustration

            Posté par . Évalué à 7.

            Ceux qui ont fait une connerie avec root

            J'ai jamais fait de connerie en root, pas besoin quand on est "bon" :

            Un jour pour tester des trucs j'ai crée un user quelconque, étant donné les circonstances j'ai fait pointer son /home sur celui de mon user classique.
            2 ans plus tard en faisant du ménage je me suis dis que ce user n'était plus utile et donc je l'ai supprimé et dans la foulée son /home.
            Et pouf !! les 900Go de datas.

            kentoc'h mervel eget bezan saotred

            • [^] # Re: Illustration

              Posté par (page perso) . Évalué à 5.

              Dans le genre d'histoire de type, sans être root (enfin, un peu quand même). J'ai installé mon premier linux (une gentoo) sur un disque IDE esclave, windows 2000 était sur le disque IDE maître. Au bout de 2 ans, j'ai décidé que gentoo méritait d’être sur le disque maître, j'ai donc inversé les branchement IDE, changé les entrée de montage dans /etc/fstab et c'était bon.

              Je boot ensuite windows en me demandant comment il survivrait au changement de configuration des disques. Après quelques seconde de grattage de disque, windows termine en erreur. Je redémarre sous linux, ba y avait plus de linux…. Je n'ai pas la moindre idée de ce qu'il a fait, mais il a trouvé le moyen d'écrire (sans doute du swap) sur le disque maître qui était avant à lui et qui était maintenant réservé pour gentoo.

          • [^] # Re: Illustration

            Posté par . Évalué à 5.

            Le truc simple : iptables -F, avec une policy par défaut à DROP, en ssh bien sûr, du coup le clavier se blo

        • [^] # Re: Illustration

          Posté par . Évalué à 2.

          Sauf que des cas où lors de la vérification annuelle on trouve qu'en fait le secours n'aurait pas marché, c'est déjà arrivé.

          • [^] # Re: Illustration

            Posté par (page perso) . Évalué à 1.

            Saleté de containers collants ;)

            • [^] # Re: Illustration

              Posté par . Évalué à 1.

              Le pire dont j'ai entendu parler, c'est le secours non connecté aux élévateurs. Le sac avait été commandé aux US et apparemment plié rapidement mais sans montage pour l'envoi (incroyable).

              Et le type a hésité a libérer au moins une fois alors qu'il avait ça dans le dos.

    • [^] # Re: Illustration

      Posté par (page perso) . Évalué à 3. Dernière modification le 02/02/17 à 15:58.

      L'exemple est trivial évidemment, mais je trouve qu'il illustre pas mal le problème, et surtout dans une situation que tout le monde comprend.

      Ou plus simplement, si tu ranges tes backups dans ton armoire ou la cave et que les bureaux de l'entreprise brûlent [1], et bien, chocolat! Mais dans l'affaire de GitLab un survol rapide suggère que le backup utilisé n'a pas de procédure de restoration associée, d'où la lenteur!

      [1] Par exemple, si un avion de ligne tombe dessus.

    • [^] # Re: Illustration

      Posté par . Évalué à 4.

      ton exemple illustre un système de secours/PCA/PRA non testé.

      La sauvegarde n'est pas un système de secours.

      La sauvegarde n'évite pas le sinistre.

      La sauvegarde permet la restauration de donnée altérées.

      Elle restaure l'état des données à un instant T.

      Cela n'interdit pas de tester les sauvegardes comme on testerait un système de secours/PCA/PRA.

      La sauvegarde est un métier. Bien souvent c'est négligé ou banalisé car on croit que c'est une sous tâche du métier d'admin.
      Dans les grosses structures, il y a des gens dédiés à la sauvegarde, c'est pas anodin.

  • # Transparence

    Posté par . Évalué à 10.

    La grande transparence de Gitlab est à saluer.

    Je trouve même qu'ils en font trop.On peut les voir en direct réfléchir au problème : https://www.youtube.com/c/Gitlab/live

    C'est de la "DevOps" téléréalité. Je ne sais pas si j'apprécierais en tant qu'employé. Intimité, droit à l'image, droit à être mauvais un jour sans … Tout cela, et bien d'autre encore, mérite réflexion.

    • [^] # Re: Transparence

      Posté par (page perso) . Évalué à 4.

      La téléréalité, c'est différent. Tu paie (presque rien) des cas sociaux et tu leur demande en échange de jouer volontairement les gros débiles (ce qu'ils font sans peine).

  • # couleur

    Posté par (page perso) . Évalué à 10.

    Il est évidemment toujours facile de donner des conseils vu le loin, mais une technique que j'affectionnais était d'avoir la couleur de fond du terminal qui change en fonction des connexions. Noir en dev, orange en préprod, rouge en prod. En général ça limite pas mal la casse.

    Aujourd'hui c'est pas si simple, par exemple quand on bosse avec du fleet par exemple (systemd distribué en gros) tout ce qui change en fonction de l'environnement est justement une variable d'environnement. Ça devient super simple de se dire "je suis en preprod mais je teste vite fait la variable de prod" ou même de se tromper de variable. Et je n'ai pas encore trouvé de solution adaptée, si qqn à des idées je suis preneur ;-)

    • [^] # Re: couleur

      Posté par . Évalué à 7. Dernière modification le 02/02/17 à 08:20.

      Dans le monde avionique on a pas mal d'analyses suite à incident (pas forcément un crash, mais au moins une belle sueur froide pour l'équipage) qui a fini en modification ergonomique. Tes couleurs de terminal c'est pas grand chose, et je veux bien croire à son efficacité !

    • [^] # Re: couleur

      Posté par (page perso) . Évalué à 8.

      Contrairement à ce que dit le journal, ce n'est pas sur un serveur de test que l'opération aurait du été faite, mais sur l'autre serveur de prod.

      En gros, si j'ai bien compris, il y avait deux serveur de prods, en redondance.
      L'un des serveur était corrompu, et le gars à voulu supprimé la base do donnée corrompue pour y recopier celle de l'autre serveur. Le problème est que l'opération a été faite sur le mauvais serveur et que donc les base de données des deux serveurs ce sont retrouvées inutilisables.

      Donc c'est pas la même chose que la différence entre test et prod, mais la différence entre deux serveur de prod.
      Oui, avoir des couleurs différente pour chaque serveur peut aider. Mais quand on à l'habitude de travailler avec plein de serveur de différente couleur tout le temps, c'est pas beaucoup plus utile que le nom du serveur dans le prompt j'imagine.

      • [^] # Re: couleur

        Posté par . Évalué à 7.

        La confustion c'est qu'au départ le mec faisait une maintenance et qu'il voulait importer des données de prods dans un environnement de préprod (staging) qu'il était en train de monter. La raison pour laquelle il a créé un snapshot qui les a sauvé.

        Entre temps ils ont eu des problèmes de spam qui faisait que les bases étaient trop chargées pour réaliser la copie. Une fois ce problème réglé et il a vu une alerte en raison d'une réplication qui ne se faisait plus entre les deux noeuds de prod. Le bonhomme était déjà bien fatigué d'une longue journée apparemment, mais comme il a vu l'alerte il n'est pas rentré chez lui et a voulu régler le problème de réplication. À ce moment là il a complètement abandonnée l'idée de travailler sur la préprod.

        Comme la réplication ne se faisait plus sur le deuxième noeud il s'est dit qu'il allait supprimer toutes les données pour que la réplication reparte de zéro. Sauf qu'il s'est trompé de noeud. Se tromper de noeud c'est un truc qui peut arriver à tout le monde avec la fatigue ou l'inattention. Le truc c'est que dans ces cas là quand on travaille sur de la prod la solution que je favorise.

        Bref au final heureusement qu'il avait ce snapshot fait 6 heures avant pour sa maintenance sinon pfuuuuit gitlab.

        • [^] # Re: couleur

          Posté par . Évalué à 6.

          Le truc c'est que dans ces cas là quand on travaille sur de la prod la solution que je favorise.

          Du coup, on reste un peu sur notre faim : tu favorises quoi? ;)

          • [^] # Re: couleur

            Posté par . Évalué à 8.

            un clavier qui ne se blo
            ```

            
            
            
            Plus sérieusement je favorise carrément de renommer l'ancien répertoire ou démonter le logical volume pour en créer un nouveau plutôt que de supprimer quoique ce soit. On supprime par après ce qui n'est plus monté/accédé.
            
      • [^] # Re: couleur

        Posté par . Évalué à 4.

        J'ai connu un techos, une fois, qu'on avait envoyé en urgence changer le disque défectueux du RAID5 d'un client. L'a pas changé le bon disque. L'a pas réalisé tout de suite. On a tous pas mal pleurés, ensuite :)

        • [^] # Re: couleur

          Posté par . Évalué à 3.

          Déjà le RAID 5 en prod j'ai jamais aimé … enfin du temps des machine physiques

          Sinon se tromper de disque même des technos de maintenance IBM me l'ont fait une fois.
          à sa décharge sur la gamme des power 550 les leds sont placés bizarrement.
          Quand tu remplace un disque en miroir tu fait clignoter la led du disques, mais si tu connais
          pas trop cette gamme tu as tendance à prendre le mauvais disque (du dessus ou du dessous je sais plus).
          et voila comment on plante 100 utilisateurs …

    • [^] # Re: couleur

      Posté par . Évalué à 2. Dernière modification le 02/02/17 à 09:03.

      Peut être que cela dépend pas mal de la personne. Autre exemple pour compléter le tiens : auparavant, et pendant longtemps, j'ai utilisé des terminaux séparés et organisés sur mon écran, et pour moi c'était très intuitif. Depuis peu je dois utiliser mobaxterm et ses onglets sont sources d'erreurs, c'est bien moins intuitif utiliser des onglets, et demande plus de concentration / de vérification pour savoir où je suis, que des espaces à séparations visibles.
      Autre exemple : certains s'astreignent à n'être connecté qu'à une seule machine à la fois (ce qui pour moi est abérant)

      En fait, faut peut être laisser le choix de l'outillage aux intervenants, car chacun aura une perception différente de ce qui lui convient pour être efficace. Non ?

    • [^] # Re: couleur

      Posté par . Évalué à 2.

      une technique que j'affectionnais était d'avoir la couleur de fond du terminal qui change en fonction des connexions

      Ce n'est pas bête du tout, en effet. Une autre technique (complémentaire) que j'ai pu voir consistait à loguer toute intervention utilisateur sur les machines sensibles (man script). Très efficace, mais ça peut rapidement bouffer de la place pas prévue quand un mec te laisse tourner un "top" dans un coin ;)

      • [^] # Re: couleur

        Posté par . Évalué à 5.

        Vous allez finir par utiliser ghash en image de fond des terminaux pour savoir sur quel machine vous êtes connecté :)

        https://github.com/nicolasboulay/ghash

        "La première sécurité est la liberté"

        • [^] # Re: couleur

          Posté par . Évalué à 1.

          Et tu mets ça comment en place sous, disons, urxvt compilé avec 256 couleurs, et zsh avec oh-my-zsh ?

          • [^] # Re: couleur

            Posté par . Évalué à 3.

            Aucun idée :) il faut un terminal qui prend une image en fond de façon scripté, et lancer la génération d'image avec le nom ou l'ip de la machine cible.

            "La première sécurité est la liberté"

    • [^] # Re: couleur

      Posté par (page perso) . Évalué à 4.

      Il est évidemment toujours facile de donner des conseils vu le loin, mais une technique que j'affectionnais était d'avoir la couleur de fond du terminal qui change en fonction des connexions. Noir en dev, orange en préprod, rouge en prod. En général ça limite pas mal la casse.

      J'utilise aussi cette technique, aussi basique qu'utile. Ensuite j'implémente le “serveur constant” et donc du coup je ne fais presque jamais un rm et si jamais, je commence par écrire un ls mes-fichiers-à-effacer puis je remplace le ls par rm quand je suis sûr. Et dans les scripts il faut toujours utiliser le modificateur :? quand on utilise rm sur une variable.

      • [^] # Re: couleur

        Posté par (page perso) . Évalué à 4.

        Un rm -i, c'est pas mal aussi (quitte à le virer après quelques fichier dans le cas d'un -r. Ça évite les surprises (par exemple, il te dit bien que tu vas supprimer un lien symbolique).

        « 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

  • # De la nécessité d'inclure les sauvegardes dans un processus plus grand

    Posté par (page perso) . Évalué à 7.

    Mes deux cents…

    J'ai eu le cas en tant que Freelance dans une grande société Française qui vend pas mal de choses dans le domaine du Sport un incident de production.
    une mise à jour qui foire une BDD (c'était une MAJ Oracle alors j'ai encore des doutes sur le faite que c'était peut etre une erreur humaine).

    toujours est-il que la BDD de prod est HS… on remonte une sauvegarde qui est… HS !
    et les précédente aussi (un script qui "oublie" certains fichiers..).

    Bref on revient en arrière grâce à la copie de prod utilisée pour monter la préproduction (2 mois de perdu…).

    Une simple question qui à fait saigner les admins… "pour mettre à jour les BDD de préproduction ou de staging vous utilisez pas les bakups de production, justement pour les tester ?"

    Ben non car "c'est trop long !"

    Du coup j'ai rendu cela obligatoire… et du coup le processus de sauvegarde est testé au moins une fois par mois (soit la staging soit la préproduction)

    Mes deux cents "fin"

    • [^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand

      Posté par . Évalué à 5.

      c'était une MAJ Oracle alors j'ai encore des doutes sur le faite que c'était peut etre une erreur humaine

      Chez Oracle, c'est des humains aussi, hein ;)

    • [^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand

      Posté par (page perso) . Évalué à 9.

      Allez, une autre, puisque c’est la journée des anecdotes !

      C’était il y a quelques années, pendant un pont du 15 août, où il n’y avait pratiquement plus personne, et dans une PME, suite une à une erreur humaine, ils avaient voulu restaurer la base de la comptabilité de la veille, et avaient tout perdu.

      Je n’y connais rien en compta, et pas grand chose en Windows NT (leur système de compta), mais j’ai accepté d’y aller voir au moins pour mieux comprendre le problème.

      C’était la comptable qui faisait les sauvegardes quotidiennes, en cliquant sur un icône de son bureau qui lançait l’opération, très rigoureusement : elle avait des tiroirs avec ses cassettes, une par jour, plus un roulement d’une par semaine, plus une par mois, ainsi qu’une annuelle, depuis plusieurs années.
      Les sauvegardes étaient toutes bonnes, et leur restauration se passait bien, mais à chaque fois, on ne retrouvait plus aucune donnée sur l’année en cours.

      Et j’ai fini par découvrir pourquoi : sa procédure de sauvegarde travaillait en fait sur une vielle base de tests qui datait de la mise en place de son appli, et qui n’avait plus jamais été utilisée depuis…

    • [^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand

      Posté par . Évalué à 2.

      et les précédente aussi (un script qui "oublie" certains fichiers..).

      C'est trop gros, ou alors changer de DBA…

      • [^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand

        Posté par (page perso) . Évalué à 3.

        En fait pas si gros que ça…

        On a fait un script de sauvegarde "à la main" avec des DBA qualifiés de l'époque…
        Et puis on a mis à jour les moteurs de BDD Oracle 8 puis 9 jusqu'à 11
        et on a pas mis à jour le script de sauvegarde…

        Qui ciblait les fichiers plutôt que le répertoire de DATA
        Qui utilisait des "tar cvjf" au lieu des procédures d'ORACLE

        Procédure qui "fonctionnaient mal" sur la version 7 mais parfaitement adapté depuis la 9…

        Arf l'historique pas mis à jour car "touche pas malheureux, car simplement ça marche !!"

        • [^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand

          Posté par . Évalué à 4.

          Désolé si

          Sous Oracle avec rman tu dois sauvegarder :

          La base / les archive logs / les controls files / le spfile ou le initSID.ora

          si tu n'as pas cela … pas de crash recovery possible

          Mais de plus … cela ne fait qu'une sauvegarde PHYSIQUE de la base

          comment tu fais pour ne restaurer qu'une table … tu ne fais pas revenir x utilisateurs à la dernière sauvegarde …

          alors de manière régulière tu fais un export de la base avec datapump

          Bien sur tout cela est à moduler en fonction du volume, du nombre d'utilisateurs, de la criticité de la base etc …

          faites très attention avec les sauvegardes les mecs, il y a longtemps ont m'a expliqué (quand j'étais encore padawan) que devant un juge l'homme de l'art (celui qui sais) aura toujours par rapport au client (celui qui ne sait pas).
          Et même si ce que te demande le client est aberrant techniquement, tu ne dois pas le faire, un client véreux peu porter plainte et gagner même si il a été prévenu des risques encourues.

          • [^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand

            Posté par . Évalué à 5.

            devant un juge l'homme de l'art (celui qui sais) aura toujours par rapport au client (celui qui ne sait pas).

            Aura toujours QUOI ?

          • [^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand

            Posté par (page perso) . Évalué à 2.

            comment tu fais pour ne restaurer qu'une table … tu ne fais pas revenir x utilisateurs à la dernière sauvegarde …

            alors de manière régulière tu fais un export de la base avec datapump

            Ils ont tout de même fait des progrès et depuis quelques versions on a des snaphots (Cf. la Fast Recovery Area FRA). Évidemment, ça ne doit pas remplacer une sauvegarde, car si la base est perdue y a pu, mais par ex. pour restaurer une table c’est bien.

            • [^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand

              Posté par . Évalué à 2. Dernière modification le 06/02/17 à 11:40.

              pour restaurer une table c’est bien.

              D'après ce que j'avais compris … Cela ne remplace pas l'export régulier dans les cas ou il y a beaucoup de volume, et quand une partie d'une grosse table est flinguée, on ne veut pas TOUT restaurer c'est trop long

              Mais bon, j'admets qu'il s'agit des fonctionnalités un peu obscure pour moi d'Oracle … comme le log mining … qui arrive à utiliser ça ?

              Sachant qu'une procédure de restauration/recovery DOIT être simple … car en situation de stress c'est pas évident de réfléchir

              • [^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand

                Posté par (page perso) . Évalué à 2.

                D'après ce que j'avais compris … Cela ne remplace pas l'export régulier dans les cas ou il y a beaucoup de volume, et quand une partie d'une grosse table est flinguée, on ne veut pas TOUT restaurer c'est trop long

                Justement, ça permet de faire des restauration partielles de tables. Exemple avec leur fameuse table EMP :

                INSERT INTO EMP
                (SELECT *
                FROM EMP AS OF TIMESTAMP
                TO_TIMESTAMP('2005-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')
                WHERE name = 'JOHN');

                Sachant qu'une procédure de restauration/recovery DOIT être simple … car en situation de stress c'est pas évident de réfléchir

                Il y a toujours un compromis à trouver entre la restauration simple et bourrine qui revient sur la connerie faite par un utilisateur en écrasant le travail réalisé par ailleurs, et le travail dans la dentelle.

                Et c’est sûr que l’urgence est mauvaise conseillère : l’idéal est de pouvoir remonter les données suspectes à leur dernier état sain connu dans des tables de travail, puis de faire les remplacements avec délicatesse…

                • [^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand

                  Posté par . Évalué à 2.

                  cela me rappelle les cours d'admin Oracle …

                  mais dans la vie réelle avec des dizaines ou centaines de go de base de données est ce exploitable …

                  c'est vrai que si on est dans la période de "garantie" de la fast recovery area c'est bien
                  mais bon certaines conneries ne se voit que … trop tard
                  et la l'export toutes les six heures (ou 4h ou quotidien … ) c'est bien

                  • [^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand

                    Posté par . Évalué à 1.

                    C'est exploitable, pour une restauration on préférera effectuer un flashback de la table pour dès histoires de contraintes d'intégrités (pour être sur que la requête ci dessus fonctionne on ne peut de toute façon pas se reposer sur l'undo donc il faut le flashback d'activé)

                    Avant même le flashback on pouvait restaurer une table, la manipulation était lourde (en 12c elle est simplifiée), les exports/imports n'étaient pas fiables, datapump est devenu consistent mais n'apporte strictement rien pour une sauvegarde.

                    • [^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand

                      Posté par . Évalué à 2.

                      Avant même le flashback on pouvait restaurer une table, la manipulation était lourde (en 12c elle est simplifiée), les exports/imports n'étaient pas fiables, datapump est devenu consistent mais n'apporte strictement rien pour une sauvegarde.

                      C'est vrai j'oublie que notre ERP utilise de manière très basique la base de données, en gros il n'y a que des tables, des séquences plus quelques vues et roles. Les contraintes d'intégrité sont gérées à part.

                      Je croyais que l'export était consistent depuis la v8 (d'ailleurs il y avait une option pour cela)

                      Quels problèmes as tu rencontré avec les exports / imports ? le renommage des TBS ? le volume des données ? ou autre ?
                      cela m’intéressent beaucoup

                      Par contre pour nous c'est un élément de la sauvegarde, car dans certains cas tordus nos devs préfèrent que l'on remonte une table d'un export (même de la veille) pour qu'ils puissent refaire la (ou les) table(s) endommagée(s)

                      C'est même certainement la restauration la plus courante chez nous …

                      • [^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand

                        Posté par . Évalué à 1.

                        Je croyais que l'export était consistent depuis la v8 (d'ailleurs il y avait une option pour cela)

                        Je ne l'ai jamais vu utilisé et ne l'ai jamais utilisé moi même (n'utilisant qu'au minimum exp/imp), mais sur une grosse base ou une base fortement sollicitée : l'export est trop impactant et l'import quasi impossible.
                        imp/exp ne fonctionnait pas sur une base spatiale (sans d'affreuses bidouilles) et peut être avec d'autre bases ayant des options particulières.

                        Quels problèmes as tu rencontré avec les exports / imports ? le renommage des TBS ? le volume des données ? ou autre ?
                        cela m’intéressent beaucoup

                        Les exports/imports sont extrêmement lents, les tables sont réalimentés, les indexes recréés (ou pas), les contraintes validées (ou pas) et j'en oublie…
                        Tout ça fait que l'import peut durée des jours et tu risques ensuite de passer des jours à rendre la base 100% opérationnelles (création d'index, activation contraintes & co).
                        Vers 2004 sur un AIX4/Oracle 9i (certes l'OS était obsolète) reconstruire un index en // de 60 ou 70Gb prenait 48h (et il y en avait bcp). La restauration full de la base via rman ~7h.

                        Sur les grosses bases imp/exp pas possible. Datapump est beaucoup plus performant, mais lors de la restauration tu n'auras pas physiquement la même base (donc des requêtes plus performantes ou d'autre moins performantes en gros c'est une loterie)

                        Par contre pour nous c'est un élément de la sauvegarde, car dans certains cas tordus nos devs préfèrent que l'on >remonte une table d'un export (même de la veille) pour qu'ils puissent refaire la (ou les) table(s) endommagée(s)

                        J'ai déjà vu ça et je n'aime pas trop cette solution, depuis là 11g tu peux garantir la rétention du flashback, restaurer une tables via la requête ci-dessus me semble mieux et l'espace supplémentaire sera certainement inférieur à l'espace des exports (la compression datapump est payante).
                        De plus tu n'es capable de 'restaurer' qu'à la date de ton export (pas de recovery), comment valider les dumps (corruption & co), combien de dumps garder, … ?
                        Je connais peu d'applications qui peuvent se permette de perdre 1 ou plusieurs journées en particulier un ERP.

                        Datapump peut servir à bcp de choses (extraction d'un subset de la base, transfert de données, migrations …) mais ce n'est pas un outil de restauration.

                        • [^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand

                          Posté par . Évalué à 2.

                          Merci pour tes réponses précises et pertinentes.

                          Je comprends mieux ton point de vue et le confirme sur plusieurs points
                          Et je m'aperçoit que les bases que l'on gère sont beaucoup beaucoup plus simple, ne serait ce que par les contraintes gérées différemment.
                          De plus en 2004 nos plus grosses bases ( sous AIX oracle 8 et 9) dépassaient rarement les 15-20 go de données
                          ( a part une de 50-60 go mais le matos avait été bien choisi )

                          Maintenant les plus grosses frises les 100 Go (de données uniquement sans coté le reste ) mais le matos est choisi en conséquence.

                          Nous utilisions l'import export exp (maintenant on est passé à datapump) dans les fenêtres de sauvegardes prévus à cet effet, et nous n'avions que très peu de base TRES SOLLICITE 24h/24h

                          Pour les bases critiques, ou la journée d'arrêt coûte TRES TRES cher, on a mis en place les principes suivants :
                          - STANDBY Database ( avec une différence max de 5 minutes )
                          - sauvegarde RMAN
                          - export datapump

                          importer la base dure environ 1h30
                          restauration from scratch depuis rman 45 minutes
                          mais le plus sécurisant pour le client c'est la STANDBY en plus dans ce cas c'est réellement 2 salles blanches avec 2 SAN etc …

                          Mais à cause de toi le flashback vient de passer sur la pile des technologies à étudier et à maîtriser …

        • [^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand

          Posté par . Évalué à 1.

          Vu les versions je n'ai plus aucun mal à te croire, depuis la 10g RMAN est, ama, vraiment fiable une fois correctement configuré.

  • # Autre exemple de redondance qui foire

    Posté par . Évalué à 2.

    Imaginons un bâtiment en train d'être construit. Ce bâtiment il y a une salle machine avec une climatisation. Pour contrôler que la clim est bien opérationnelle, deux techniciens doivent indépendamment la vérifier.

    Quelques temps plus tard, la clim est mise en route et tombe en panne. Paf, tous les serveurs grillés. Le problème ? Ben le technicien i (i=1, 2) s'est dit que comme le technicien 3-i bosserait bien, il pouvait faire son boulot un peu moins consciencieusement.

    • [^] # Re: Autre exemple de redondance qui foire

      Posté par . Évalué à 3.

      Imaginons un bâtiment construit … tout neuf
      Des portes de hauteur 3m (ou qq chose comme ça)
      et des tuyaux qui passent devant les portes à 2,80m

      1er jour … les fenwicks tournent … mais personne n'avait pensé à tester les fenwicks chargés avec
      des caisses plus hautes … enfin plus que 2,80m … tuyau éclaté … inondations … toussa

      je crois que les conneries industrielles sont pas mal non plus …

    • [^] # Re: Autre exemple de redondance qui foire

      Posté par . Évalué à 5.

      Imaginons une société de transport ferroviaire. Imaginons qu'elle ait besoin d'agents d'astreinte le week-end. Imaginons que, prévoyante, elle décide de mettre deux agents sur la même astreinte, pour pallier les éventuels empêchements.

      Quelques années plus tard, il y a 4 agents sur cette astreinte, et c'est toujours "le premier qui décroche a perdu" quand l'astreinte se déclenche…

      • [^] # Re: Autre exemple de redondance qui foire

        Posté par . Évalué à 7.

        Imaginons cette même société qui met en place un serveur web, qui a une très faible activité la plus part du temps, et donc est migré sur une petit machine… et tombe au premier pic d'usage : c'était un site d'information sur les trains qui roulent pendant les grèves.

        "La première sécurité est la liberté"

  • # Vécu

    Posté par . Évalué à 9.

    "Depuis que le technicien est passé c'est formidable ma sauvegarde qui durait 1h est maintenant instantanée."

  • # Redondance de personne

    Posté par . Évalué à 4.

    Etre plusieurs à s'occuper d'un serveur, d'un programme, c'est s'assurer qu'en cas de pépin il vaut mieux être plusieurs. Mais être plusieurs c'est aussi multiplier le risque d'erreur humaine…

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.