Mise à jour du 23 mars

Le serveur de Magic-ville est toujours dans un cas à part.
• Il a été emmené à Croix pour subir un traitement de nettoyage très technique.
• Il sera ensuite branché dans un datacenter à Roubaix ou Gravelines, et on saura à ce moment là s'il est récupérable.

Le rédémarrage du serveur devrait intervenir entre le 28 et le 29 mars.

En attendant, Magic-ville reste sur un mode "consultation" avec une base de données datant du 29 janvier. Tous les services interactifs ont été déconnectés (S'inscrire, passer une commande, soumettre une combo, une illustration, un bug, modifier son mot de passe, etc...) à queqlues exceptions près :
• Vous pouvez poster dans le forum (theme ash uniquement)
• Vous pouvez modifier ou créer de nouveaux decks. Ils seront effacés si on récupère le serveur, mais je vous donnerai un accès aux listes modifiées ou créées.

je n'osais pas trop en parler !!!
mais je suis pareil que mes collègues avec une saisie régulière de cartes si on repart du 10 mars c'est perfecto !!
j'en profite pour remercier JMB de ses informations et de son humour.
bon courage !

AMHA si OVH assure quelque chose ce sera seulement la période entre l'outage et la livraison du serveur de rechange (donc 4-5 jours dans le cas de MV). Et encore, je pense qu'il vont juste offrir quelques mois d'hébergement gratuits, mais rien en rapport avec le CA réel du client.

Enfin à moins d'avoir délégué contractuellement la gestion des sauvegardes à OVH avec une clause pour les désastres, mais je pense pas que ce soit le cas. A vrai dire je suis même pas sûr que OVH propose ça, et s'ils le font je pense que JMB aurait pu récupérer un backup plus frais issu d'un autre datacenter.

Oui, OVH va faire un avoir de 3/6 mois selon les cas. La seule solution de backup pour dédiés qu'ils proposent, c'est ce que j'avais, un disque séparé auquel on ne peut accéder qu'à partir du serveur (c'est pas le plus pratique) et qui peut se trouver dans le même bâtiment que le serveur ou dans le bâtiment à côté. Donc en gros, c'est une sauvegarde pour le cas ou tu fais une mauvaise manip ou si le disque dur fond, mais sur un gros sinistre, ça SAR.

En bref, j'attends avec un poil de nervosité que cet épisode se termine, et je monterai un serveur identique, le jumeau maléfique de MV, avec une latence de 1h ou 2h. Mais j'aurais l'occasion de reparler de tout ça dans pas longtemps je l'espère.

Yep, c'est ce qu'il me semblait pour le backup OVH automatique. Mais bon c'est jamais évident de fixer la bonne limite de "parano" pour les sauvegardes, surtout quand tu bosses pour toi-même (quand c'est pour un client c'est de suite plus facile, c'est généralement lui qui vient te demander de détailler ton plan de reprise d'activité, tâche souvent un peu relou).

Dans ton cas, un simple backup quotidien (genre tâche CRON) de la BDD sur un autre datacenter c'est peut-être suffisant, non ? Après si tu peux le régler sur un rythme plus fréquent voire faire un miroir complet (code, données et infrastructure) sans gros surcoût (financier & perfs), y a pas de raison de s'en priver en effet.

Attention à ne pas dériver de tâche CRON vers tâche Macron !

La bonne idée après coup, pour les transactions, on reçoit un mail d'ouverture avec l'id, le pseudo et le montant. Pourquoi ne pas y mettre aussi le listing des cartes concernées ? Dans la pratique certaines pourront être remises en vente ou supprimées de la transac, mais ça fait une sauvegarde sur les serveurs mails des vendeurs. En temps normal, ces mails pourront être mis de côté (genre pour quelques mois glissants) mais dans une situation comme l'actuelle, ça permettrait de reconstituer le stock écoulé.

Petite question, j’ai un ami qui a passer une commande le 9 au soir sur le MV shop, comment cela ce passe si on pars d’une sauvegarde ou son compte n’existait pas (créer le 2 mars) ?

Tout d'abord as-tu vérifié que ton ami existe toujours ?

@Madmox + farfadet : Cet incident m'a fait réalisé qu'en plus des problèmes de backup, il y avait aussi l'interruption de service. J'avais en tête qu'en cas de coupure, je pourrais toujours prendre un nouveau serveur (dispo habituellement en 120 s) et faire repartir le truc rapidement. Sauf que qui dit gros incident dit des milliers de clients qui ont besoin d'une machine en même temps, et du coup en commandant très tôt, j'ai pu être servir en 4/5 jours, pour d'autres, ça a été le double. D'où la nécessité d'un serveur redondant (à une bonne distance du premier) qui fait sauvegarde et solution de repli. Ça va rajouter 1500 balles par an, mais le jour où j'apprends en me levant qu'un monstre gigantesque cracheur d'acide a détruit Strasbourg, je modifie la zone DNS et je me refais un café (et après je poste "Je suis Strasbourg" sur Twitter obv.)

@Almann95 : L'incendie n'a pas détruit les données du compte bancaire de la boutique, donc si dans le pire des cas on ne peut pas récupérer les données de la commande, il sera remboursé.

J'espère vraiment qu'on va récupérer le serveur du coup.

Pour le coup, moi j ai pas mal chatté avec mon achat chez magicB, j avais pris en photo ma liste il manquait juste les quantités par exemplaire et on a retrouvé ca à 2. Ca s est fait tranquillement grace à JMB que je remercie :p
Bref good luck pour la suite. j ai d autres cartes à acheter :p

Si tu estimes que la durée d'interruption (* la probabilité que ça arrive) vaut ce tarif, en effet c'est raisonnable. Y a plus qu'à faire de ce miroir ton environnement de test pour les améliorations sensibles, histoire de faire double usage :)

On sent que tu baignes dans le métier ...
Pareil de mon coté, perso, travaillant dans un très grand groupe et gérant tous les incidents informatiques majeurs, je m'étonne encore qu'OVH n'ait pas un DRP (Disaster Recovery Plan) si un de ses datacenters est HS. En terme de résilience, c'est plutôt moyen ...

Ca, c'est plus qu'une bonne idée. Et pourquoi pas carrément chez un autre hébergeur au cas où OVH ne précise pas où serait stocké ce "clone" ?

Ça me surprend pas tant que ça, l'hébergeur ne peut pas assurer le plan de reprise d'un client à sa place. Déjà parce que ça impliquerait qu'il fasse des copies de ses données sans son autorisation (à la limite c'est faisable en option, comme pour la sauvegarde "locale" OVH dont JMB parlait), mais surtout parce qu'il ne peut pas gérer la restauration complète de son infrastructure (il y aura la plupart du temps de la config à revoir dans le site "miroir").

Généralement les hébergeurs cloud se contentent de mettre à disposition de leurs clients des outils pour qu'ils assurent eux-même leur plan de reprise : sauvegardes géo-redondantes automatisées (bases de données et serveurs), déploiement d'infrastructure scripté, etc.

Bon, là, apparemment OVH ne met même pas ces outils à disposition, donc c'est pas ouf de leur part, c'est vrai. Par contre ils avaient a priori suffisamment de machines en rab pour remonter un datacenter "nu" équivalent (en plusieurs jours/semaines, certes), c'est déjà pas si mal, je suis pas sûr que beaucoup d'hébergeurs plus petits en soient capables.

En effet, tu as raison.

Quand tu loues un dédié, tu choisis le datacenter, donc pas de souci de ce côté là, c'est plutôt pour les disques de backup que tu sais pas s'ils l'ont foutu dans la baie d'à côté ou a 600 km.

Bonjour à tous,
D'accord avec vous^^ croisons les doigts.... Si on se met tous à croire il parait que ça va marcher!

Merci JMB, grâce à toi j'ai pu vérifier que je savais toujours contenir mes fous rires durant les conf call.

Ce serait normal, selon moi, de savoir où sont les disques de backup.