Si des fois que ça serait plus pratique que le chat, on peut éventuellement en faire une discussion. Comme ça tous les experts pourront dire qu'ils savaient mieux qu'OVH et qu'eux auraient fait différemment et que c'est vraiment des incompétents. 😆

Guybrush Best practice ever: ovh faisait ses backups dans la salle serveur juste à côté de celle qui a brûlé...

Note qu'il me semble que c'est assez fréquent d'avoir le backup pas très loin du serveur.
Je me souviens de clients qui faisaient un backup sur bande (5 bandes, 1/jour + x bandes pour x semaines) et les cassettes n'étaient jamais mises au coffre, elles n'étaient pas très loin dans la salle serveur, étiquetée lundi, mardi, mercredi...

Je ne sais pas où c'est actuellement dans ma boîte, mais on a une salle avec un rack de serveur, je pense que les backups sont au même endroit (et c'est juste le backup du TFS avec tous les codes des clients - donc notre "valeur" commerciale). Non pas tout le code, beaucoup de clients ont leur propre TFS ou un TFS Azure.

J'ai vu le topic après avoir répondu à Tchou sur le minichat, mais voici l'article à propos du système d'extinction :
www.journaldunet.com/web…

La partie "utile" (fin d'article):

Au-delà de ces questions, une certitude demeure : Les centres de données d'OVHCloud à Strasbourg ne sont pas dotés de réseaux d'extinction. Ils ne sont pas équipés de gicleurs d'eau comme c'est le cas dans les datacenters d'OVHCloud à Beauharnois au Canada, ni de brumisateurs haute pression permettant de résorber les flammes tout en protégeant les machines contre l'eau, ni de gaz inerte, à l'instart de la plupart des datacenters du marché. Des gaz qui ont pour vocation de vider les salles serveurs de leur oxygène pour étouffer l'incendie en évitant là-encore de causer des dégâts aux équipements.

Pas la vérité absolue, mais quelques billes

GuybrushBest practice ever: ovh faisait ses backups dans la salle serveur juste à côté de celle qui a brûlé...

Pas tous les backups cela dit, néanmoins ce n'était peut être pas un si mauvais compromis, écrire des gros volumes de données à des endroits géographiques différents est compliqué et coûteux au niveau archi réseau. C'est clairement pas le même prix que paiera le client, et tous sont loin d'être prêts à payer.
Un datacenter électriquement séparé mais géographiquement proche, ça peut être un choix raisonnable.
À noter que sur la plupart des offres, la redondance des données est à la responsabilité du client, le service de backup de l'hébergeur est plus un secours au cas où le client a vrillé ses données.

TchouJ'ai vu cette info nulle part ? Perso, ce qui m'étonne, c'est que depuis le début, pas le signe du moindre mot concernant le système anti-incendie. surtout que ça implique beaucoup de chose pour leurs autres DC, s'ils ont besoin de patcher tous les bâtiments c'est chaud

Beaucoup de datacenters OVH ont des structures très différentes, en fonction de leur lieu d'installation. Par exemple si je me souviens bien, SBG1 est un assemblage de conteneurs de transports. Je pense que les systèmes anti-incendie sont du sur-mesure dans la plupart des cas.

FabePas tous les backups cela dit, néanmoins ce n'était peut être pas un si mauvais compromis, écrire des gros volumes de données à des endroits géographiques différents est compliqué et coûteux au niveau archi réseau

OK pour l'aspect financier, mais d'un point de vue pratique, c'est quand même une mauvaise habitude. Faire des backup dans la salle à côté des originaux, c'est prendre le risque qu'en cas de catastrophe, à la fois les originaux et le backup disparaissent c'est ce qui s'est passé cette fois-ci.

Je suis très étonné de voir que des systèmes anti-incendie ne font pas partie de la conception de base des datacenter. J'en ai visité deux, certes l'un des deux était particulièrement impressionnant (MRS01), mais même dans le "petit", le soin apporté aux systèmes d'étouffement du feu (par remplacement de l'oxygène par un autre gaz dans les deux cas) me faisait croire que c'était une fonction de base d'un datacenter.

Boah ça me choque pas plus que ça. Dans l'it, y a toujours un gap énorme entre les bonnes pratiques et la réalité.

Y a deux ans, j'ai visité le centre de données du gouvernement espagnol et c'était pareil : aucune précaution ou presque, juste des rangées un peu désordonnées avec les machines. A l'entrée, y avait même un gros bouton poussoir rouge qu'on nous a formellement interdit de toucher car ça coupait tout (vous imaginez : un groupe de 50 inconnus internationaux qui pourraient individuellement couper le gros de l'informatique d'un gouvernement ? Bah oui...)

C'est un peu la même chose avec la sécurité tout court des données qui transitent.
Si tu ne fais pas le concept au départ et que tu n'y prend pas garde au départ, plus tard ça devient compliqué (et cher) de patcher une application existante pour lui ajouter de la sécurité.
Le client ne voit aucun avantage direct, mais doit payer très cher, donc ...
Là, ça doit être pareil, tu trouves des locaux, ça te plaît, tu t'installes, tu poses des serveurs, beaucoup de serveurs et tu te rends compte qu'il n'y a pas de système anti-incendie.

Et comme Fabe le dit plus haut:

À noter que sur la plupart des offres, la redondance des données est à la responsabilité du client, le service de backup de l'hébergeur est plus un secours au cas où le client a vrillé ses données.

Chez nous, c'est le contraire, ils mettent en place toutes les bonnes pratiques de l'IT...
Sauf que ca ne marche jamais lol.

La semaine passée, le principale DC est tombé (coupure de ligne), ben les 2 autres DC redondant n'ont jamais pris le relay.
Résultat, une journée de boulot de perdu pour toute l'administration Bruxelloise ^^.

Fun fact, sur le site sur lequel je travaille, on a du tracking géré par un prestataire qui avait son infrastructure sur l’un des data centers qui a brulé.

Vu qu’on ne charge plus leur pixel de tracking de merde, on a des temps de chargement super fluides ! La page charge en quelques secondes, mais avec le pixel, on prenait sur certains appels du 20 à 40 secondes dans les dents à cause du pixel.

On a eu beau batailler avec le département tracking, qui a toujours donné une fin de non recevoir, et maintenant on a de belles preuves et on va pouvoir faire de la politique pour dégager ce pixel.

Un prestataire qui m'ajoute 20s de temps de chargement c'est lui que je vais cramer je pense