Franchement, il y a des moments où j’aimerais être un champion de Catch et certains fournisseurs/éditeurs des adversaires déguisés en Spiderman adipeux ou Batman famélique histoire de pouvoir, en toute conscience et en toute tranquillité distribuer les bourre-pifs et les mandales. Où alors, avoir le pouvoir de créer une HADUPI, une “Haute Autorité Des Uppercut et des coup-de-Pieds Incisifs” pour lui demander de repérer via des audits systématiques des entreprises à la recherche des logiques de sauvegarde qui datent des années 80, pour ensuite leur envoyer un courrier d’avertissement ayant valeur de négligence caractérisée dans les solutions de sauvegarde proposées aux clients.
Rendez-vous compte, nous avons des outils fantastiques pour réaliser des snapshots de volumes quasi instantanément, des fonctions spécifiques permettant d’assurer de manière industrielle la cohérence des données ainsi protégés, des systèmes élaborés pour pouvoir réaliser des sauvegardes à chaud, sans perturber le moins du monde la production. Et qu’est-ce qu’on nous propose pour réaliser des backups des bases de données ? … “Ben heu, vous auriez pas un petit 800 Go qui traîne pour faire un dump de la base ? Et ensuite, vous venez le chercher, ça vous va ?”. Et vous voulez que je vous fasse le plein du véhicule aussi ? Je vous signale que ce n’était pas dans vos demandes initiales de volumétrie ! “Ha, oui, pardon, on s’est trompé, mais bon, c’est juste 800 Go, maintenant, c’est pas cher les Go”. Ben voyons.
NON, ça ne nous va pas, Je suis client et je veux de la sauvegarde économe en volume, élégante, rapide, qui prenne en compte les technologies ACTUELLES et notamment les snapshot cohérents, je veux une vraie analyse des volumes réels nécessaires au fonctionnement d’une application, qui prenne en compte l’ensemble du périmètre et pas juste le volume de la BDD. Est-ce trop demander ? D’autant qu’évidemment, ces volumes sont un gâchis d’espace absolument dingue. j’ai calculé que rien que sur nos applis institutionnelles (une grosse trentaine aujourd’hui, soit 25% des applications hébergées), on consommait pas moins de 20 To rien que pour ces espaces de manœuvre.
Et le plus inadmissible dans tout cela, c’est que toute l’ingénierie permettant d’adapter ces méthodes ante-diluviennes de backup, ce ne sont pas les fournisseurs qui l’apporte, ce ne sont même pas forcément les constructeurs (même s’il proposent des produits), mais bien, nous, client, qui sommes obligé, par nécessité d’économie et de sobriété (relative …) en matière d’espace disque, de l’assumer ou en tout cas d’en supporter le poids financier.
Décidément, comme dit l’autre, si on enlevait les impressions et la sauvegarde, les informaticiens seraient des gens heu-reux !
J’avoue que de notre côté nous n’avons pas ce problème. Nous ne leur laissons pas le choix. Nous utilisons les plans de sauvegarde que nous avons définis en interne. La plupart du temps ça ne leur pose pas de problème.
Je parle bien sûr pour les SGBD classique MSSQL et Oracle.
Par contre dernièrement nous avons réussi à travailler avec le fournisseur de notre DPI afin de qualifier une nouveau plan de sauvegarde. Leur application utilise la SGBD Caché que vous devez bien connaître. Nous avons remplacé le classique dump par un snapshot consistant de la base. Ça marche bien et le fournisseur supporte cette solution.
Bon dans ce cas, le fournisseur de l’application et de la SGBD est le même donc ça aide.
Bonjour Gaël ! Je pense que vous êtes du Sud :D ! Effectivement, c’est un sujet de travail de notre coté aussi actuellement (vous devriez être contacté bientôt, si ce n’est pas déjà fait, par un de nos ingénieurs).
Il faut aussi remettre mon coup de gueule dans le contexte (une manière comme une autre d’évacuer un peu la pression, disons), tout nos fournisseurs ne sont pas comme cela. D’ailleurs, certains ne savent même pas de quoi on parle quand on évoque le sujet et nous disent “faites comme vous voulez” ;)
Ca aurait été sympa de liste les moyens technologiques modernes pour éviter les dumps, peut être que ca aurait fait ’tilt’ dans la tête ce certains.
Dans le même esprit, je passe une coup de gueule contre les éditeur qui veulent réservés 4vCPU de 2Ghz et tu te rends compte qu’au final, il squatte 200Mhz max..
Ben, tiens, ce billet “coup de gueule” d’il y a quelques semaines devrait te faire plaisir, Joff :)
https://vblog.io/rognotudju-du-jeudi-arretez-avec-les-vcpus/
Ah beh tiens, j’avais déjà posé le même commentaire sur ce sujet :)