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 gUI (Mastodon) . É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 :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Illustration
Posté par Larry Cow . Évalué à 10.
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 totof2000 . Évalué à -4.
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 GG (site web personnel) . É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.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Illustration
Posté par Nicolas Boulay (site web personnel) . É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 Renault (site web personnel) . Évalué à 5.
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 gUI (Mastodon) . É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.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Illustration
Posté par reynum (site web personnel) . Évalué à 10.
Tant qu'à illustrer illustrons :-D
kentoc'h mervel eget bezan saotred
[^] # Re: Illustration
Posté par reynum (site web personnel) . Évalué à 10.
Et puis une autre (j'suis chaud) qui fonctionne à merveille avec la précédente :
Et puis l'article sur developez.com qui parle de cet accident sur github
kentoc'h mervel eget bezan saotred
[^] # Re: Illustration
Posté par Guillaum (site web personnel) . É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 Christophe B. (site web personnel) . Évalué à 10. Dernière modification le 02 février 2017 à 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 NumOpen . Évalué à 3.
J'ai déjà formaté une partition avec toutes mes données non sauvegardées !!!
[^] # Re: Illustration
Posté par Michaël (site web personnel) . É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 wismerhill . É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 guppy . Évalué à 2.
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 Benoît Sibaud (site web personnel) . Évalué à 9. Dernière modification le 03 février 2017 à 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 reynum (site web personnel) . Évalué à 10.
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 totof2000 . Évalué à 2.
NE te retiens surtout pas, c'est trop drôle.
[^] # Re: Illustration
Posté par Sufflope (site web personnel) . Évalué à 4.
Oh ça c'est pas grave puisque tu avais ouvert une transaction, n'est-ce pas ? :-)
[^] # Re: Illustration
Posté par Chris K. . Évalué à 2. Dernière modification le 04 février 2017 à 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 reynum (site web personnel) . Évalué à 7.
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 Guillaum (site web personnel) . É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/fstabet 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 Octabrain . É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 Wawet76 (site web personnel) . É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 Guillaum (site web personnel) . Évalué à 1.
Saleté de containers collants ;)
[^] # Re: Illustration
Posté par Wawet76 (site web personnel) . É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 Michaël (site web personnel) . Évalué à 3. Dernière modification le 02 février 2017 à 15:58.
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 Dabowl_75 . É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 Ririsoft . É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 NumOpen . É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 CrEv (site web personnel) . É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 gUI (Mastodon) . Évalué à 7. Dernière modification le 02 février 2017 à 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é !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: couleur
Posté par Gof (site web personnel) . É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 Psychofox (Mastodon) . É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 Larry Cow . Évalué à 6.
Du coup, on reste un peu sur notre faim : tu favorises quoi? ;)
[^] # Re: couleur
Posté par Psychofox (Mastodon) . Évalué à 8.
un clavier qui ne se blo
```
[^] # Re: couleur
Posté par Larry Cow . É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 Christophe B. (site web personnel) . É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 bubar🦥 (site web personnel) . Évalué à 2. Dernière modification le 02 février 2017 à 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 Larry Cow . Évalué à 2.
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 Nicolas Boulay (site web personnel) . É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 Parleur . É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 Nicolas Boulay (site web personnel) . É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 Michaël (site web personnel) . Évalué à 4.
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
rmet si jamais, je commence par écrire unls mes-fichiers-à-effacerpuis je remplace lelsparrmquand je suis sûr. Et dans les scripts il faut toujours utiliser le modificateur:?quand on utilisermsur une variable.[^] # Re: couleur
Posté par claudex . É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 Memiks (site web personnel) . É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 Larry Cow . Évalué à 5.
Chez Oracle, c'est des humains aussi, hein ;)
[^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand
Posté par reynum (site web personnel) . Évalué à 3. Dernière modification le 02 février 2017 à 15:54.
Avec ce qu'ils font subir à toutes les entreprises qui utilisent JAVA !!
Franchement j'ai du mal à y croire.
C'est un peu comme dire que chez Monsanto c'est des humains tout en regardant les photos de tous les enfants de moins de 10ans souffrant d'une leucémie à cause du glyphosate.
:-D
kentoc'h mervel eget bezan saotred
[^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand
Posté par Antoine . Évalué à 2.
Hum… Elle a été prouvée où, la responsabilité du glyphosate dans les leucémies d'enfants de moins de 10 ans ?
[^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand
Posté par reynum (site web personnel) . Évalué à 3.
http://relaisleucemie06.canalblog.com/archives/2016/12/09/34666575.html
http://www.docbuzz.fr/2013/06/17/123-pesticides-fausses-couches-leucemies-malformations-congenitales-maladie-de-parkinson-toute-la-france-rurale-est-exposee/
http://pesticides-etudes.blogspot.fr/2009/09/exposition-maternelle-aux-pesticides-et.html?m=0
http://preproduction.univers-nature.com/actualite/alimentation-sante-eau/maternites-sous-pesticides%C2%A0-gare-aux-risques-de-leucemie-infantile-56223.html
En ce qui concerne les enfants de moins de 10 ans en particulier c'était un "clin d’œil" aux écoles à proximité des plantation de soja (Roundup ready) en Amérique du sud. Ces même enfants qui profitent de cet herbicide quand les avions le pulvérise sur les champs.
Et puis c'est tellement plus mignon quand c'est des enfants qui crèvent dans la douleur à cause de la stupidité de leurs aînés.
-_-
kentoc'h mervel eget bezan saotred
[^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand
Posté par Antoine . Évalué à 6.
Aucun des liens que tu donnes ne mentionne (et ne parlons même pas de le prouver) que le glyphosate en particulier aurait été reconnu responsable de leucémies chez des enfants de moins de 10 ans.
Ce qui n'est pas très mignon, c'est de présenter de simples allégations comme des faits avérés (tout en faisant de la démagogie de très mauvais goût en brandissant des photos d'enfants morts). La pente obscurantiste et anti-scientifique d'une partie de l'idéologie écologiste est inquiétante, surtout quand cette idéologie se trouve propagée en toute bonne foi par des tas de gens qui ne cherchent pas à contrôler leurs sources d'information.
C'est le même mode de pensée qui permet aux mouvements anti-vaccination de trouver des appuis chez certains parlementaires Verts, par exemple :
http://www.pseudo-sciences.org/spip.php?article2776
(eh oui, pas besoin d'aller chez Donald Trump pour trouver de l'obscurantisme : une partie de la « gauche » actuelle contribue largement sa part)
[^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand
Posté par Thierry Thomas (site web personnel, Mastodon) . É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 Kangs . Évalué à 2.
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 Memiks (site web personnel) . É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 Christophe B. (site web personnel) . É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 windu.2b . Évalué à 5.
Aura toujours QUOI ?
[^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand
Posté par Christophe B. (site web personnel) . Évalué à 5.
oups … raison
devant un juge l'homme de l'art (celui qui sais) aura toujours raison par rapport au client (celui qui ne sait pas).
Désolé …
[^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand
Posté par Christophe B. (site web personnel) . Évalué à 3.
Désolé je pense a quelque chose et écrit l'inverse :
devant un juge l'homme de l'art (celui qui sais) aura toujours tort par rapport au client (celui qui ne sait pas).
[^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand
Posté par totof2000 . Évalué à 5.
Je ne sais pas s'il aura raison ou tort. Par contre je ne savais pas que la terminaison d'un verbe changeait en fonction de la forme affirmative ou négative de la phrase.
[^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
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 Christophe B. (site web personnel) . Évalué à 2. Dernière modification le 06 février 2017 à 11:40.
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 Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
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');
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 Christophe B. (site web personnel) . É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 Kangs . É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 Christophe B. (site web personnel) . Évalué à 2.
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 Kangs . Évalué à 1.
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.
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)
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 Christophe B. (site web personnel) . É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 Kangs . É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 fmaz fmaz . É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 Christophe B. (site web personnel) . É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 Larry Cow . É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 Nicolas Boulay (site web personnel) . É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 wilk . É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 wilk . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.