Restauration backup VPS SBG =&gt; autre VPS

Salut @LaurenceC6

Quand tu parles de backup, tu entends quoi ?
backup interne de ton coté ? un snapshot ?

Dans le premier cas : commande d'un nouveau VPS et réinstallation complete
dans le second cas : ... faut attendre mais je pense que c'est mal barré :/

Jalinn

Helpful (0)

Non.

Pour le moment, a ce que je vois et lit sur les différent canaux, tout est KO.

Faut voir ce qu'ils vont pouvoir récupérer ou non.

Le plus rapide là, c'est commander un nouveau service et reconstruire depuis tes propres backup...

Helpful (0)

ClementB36

Ben mince...
On avait confiance au backup OVH et on était clairement pas préparé à cette éventualité.
J'ai pu lire par-ci par-là que les backups se trouvent à Roubaix.

Une possibilité de les télécharger et les monter dans une VM pour pouvoir récupérer les données ?

Helpful (0)

RaphaelG5

J'utilisais une double sauvegarde "Backup automatisé" + script de sauvegarde avec l'offre "Backup FTP"
Backup auto c'est mort en tout cas pour l'instant
Et l'accès au stockage "Backup FTP" est limité à certaines IP et le Manager et l'API ne permettent pas la reconfiguration car ils se basent sur le VPS qui n'est plus connu actuellement

Helpful (0)

GuillaumeG44

Bonjour,
J'ai également 4 VPS sur SGB mais j'ai pour chacun l'option de backup automatisé (qui sauve quotidiennement le disque sur 3 serveurs différents, dont un à Roubaix si je comprends bien).
De ce que je lis, il n'y a aucun moyen de récupérer ces backups ? Même à la mano via un bête téléchargement ...
Je ne vois pas non plus mes VPS SBG dans la liste ...
Merci pour votre aide si quelqu'un a une procédure à suivre

Helpful (0)

J'ai également 4 VPS sur SGB mais j'ai pour chacun l'option de backup automatisé (qui sauve quotidiennement le disque sur 3 serveurs différents, dont un à Roubaix si je comprends bien).

Où as tu vu ça ?

de mon côté, ce que je sais de l'infra OVH a ce sujet, c'est que le backup auto n'est rien d'autre qu'un snapshot pris tout les jours.
L'image est transférer sur l'infra de stockage des backup et mis a dispo des VPS au besoin.

Je n'ai lu/vu nul part que cette image est redondé sur 3 DC differents...

Helpful (0)

LoicB6

c'est marqué là pour les backups automatisés :
https://www.ovhcloud.com/fr/vps/options/

"La fonction auto-backup vous affranchit de cette complexité. Concrètement, une sauvegarde de votre VPS (hors disques additionnels) est planifiée quotidiennement, exportée puis répliquée trois fois avant d’être disponible dans votre espace client."

Je compte clairement là dessus, mais pour l'instant impossible de récupérer quoi que ce soit.

Helpful (0)

GuillaumeG44

Exact, c'est d'ailleurs tout l'intérêt de ce backup automatisé ...
Après maintenant il faudrait également pouvoir le récupérer rapidement.

Prochaine fois je mets en place des sauvegardes en local également ...

Helpful (0)

fritz2cat officiel (d'avant la migration)

Ok.

quand OVH parle de réplication, ils parlent de leur infra Ceph a mon avis.
Ceph va créer 3 cluster de disques differents et dupliquer les data sur ces disques.

Par contre, pour des questions de latences, a mon avis, les cluster en question sont tous sur SBG également...

Il va falloir attendre un peu je pense dans tout les cas.

Prochaine fois je mets en place des sauvegardes en local également ...

Je dirais même que c'est la base de tout bon backup... sinon, on n'appelle pas ça un backup...

Helpful (0)

Newbie

quand OVH parle de réplication, ils parlent de leur infra Ceph a mon avis.

mouais,
quand mon hébergeur me parle de 3 copies à des endroits distincts, ce n'est pas dens le même DC ni dans la même ville. Si jamais un 747 venait s'empaler sur le site ? Ou un grave attentat, ou une catastrophe, le Rhin qui déborde ?

Helpful (0)

Je ne dit pas que c'est cool d'un point de vu communication.
C'est certes trompeur je pense.

De mon côté, depuis le temps que je pratique OVH et les discussion que j'ai pu avoir avec le staff au travers du support et des différents event, quand ils parlent de "réplication x3", sans mention de DC ou autre => Ceph.
Sachant que Ceph est très sensible a la latence, je doute qu'ils aient mis un cluster ceph par DC...
Donc, il ont potentiellement mis leur infra dans plusieurs salles spécifique au sein du DC.

On ne le répéteras jamais assez, mais il ne faut JAMAIS mettre ses œufs dans le même panier quand la prod et le data sont critique.
Il faut toujours, a minima, doubler les backup en local (et ça, c'est VRAIMENT le minima).

Jalinn

Helpful (0)

GregoryG12

Je les avais contactés il y a quelques mois pou avoir des infos là dessus, et leur réponse était que les backups étaient faits dans des batiments distincts au sein d'un même DC. Ils mettaient en place (à quelle échéance) la réplication vers d'autres centres mais ce n'était pas encore faire à l'époque.

Helpful (0)

DamienL26

Bonjour à tous,

Même problème pour notre société, notre VPS a cramé et nous ne savons toujours pas ce qu'il en est du backup! Nous sommes au chômage depuis une semaine.

Le concept du backup automatisé (et facturé en option par OVH) est justement de le mettre dans un autre DC en cas de problème. C'est la base de la base, mais apparemment OVH aurait "omis" ce détails.
Du coup c'est la catastrophe en attendant de savoir ce qu'il en est...

Helpful (0)

EPIDORE

De ce que j'ai pu lire de la communication du CEO, tant que les serveurs que SBG3 ne sont pas redémarrés, on ne saura pas. D'ailleurs je me pose la question, s'il y a moyen de savoir sur quelle serveur se trouve son backup automatisé.

http://status.ovh.com/vms/sbg/index.html

Helpful (0)

Je suis d'accord, on compte aussi sur ces backups. Quand on annonce au client que les datas sont repliquées dans 3 endroits, il est en droit de penser que les données sont récupérables à tout moment en l'état où elles étaient au moins 24h avant.

Helpful (0)

fritz2cat officiel (d'avant la migration)

Contributor

Faut remercier les commerciaux qui font les plaquettes produits...
Il n'a jamais été dit que c'était répliqué dans 3 DCs différents, juste répliqué 3x... Mais c'est sur le même DC...
Donc oui, OVH a joué sur l'ambiguïté du "3x", mais ils n'ont jamais explicitement parlé de 3dcs différents...

Helpful (0)

Newbie

Il n'a jamais été dit que c'était répliqué dans 3 DCs différents, juste répliqué 3x... Mais c'est sur le même DC...
Donc oui, OVH a joué sur l'ambiguïté du "3x", mais ils n'ont jamais explicitement parlé de 3dcs différents...

C'est de la publicité trompeuse.

Je me doute bien que quand tu implémentes ton DRP/PRA, en tant que professionnel, tu envisages toutes les catastrophes possibles, débordement du Rhin, chute d'avion, hack à grande échelle de ton fournisseur favori ...

Quand tu prends du cloud avec 3 backups ce n'est pas que ton fournisseur de cloud les mette tous les trois dans le même coffre-fort. Désolé.

On peut aussi discuter sur la quantité de bois dans la construction du bâtiment et l'absence de système d'extinction autonome - avec des sprinklers qui gerbent 120 litres à la minute, au moins ça aurait peut-être limité les dégâts.
Le gaz Pro-inert c'est impayable dans les volumes de locaux dont on parle, et surtout conçus avec une convection naturelle et la cheminée de tirage au centre.

C'est très malheureux ce qui vient de se passer. J'ai vraiment mal pour tous les entrepreneurs qui ont tout perdu dans l'incendie, alors qu'ils pensaient être protégés.

Helpful (0)

janus57

Bonjour,

avec des sprinklers qui gerbent 120 litres à la minute, au moins ça aurait peut-être limité les dégâts.

avec les serveurs OVH qui sont pour les 3/4 dans des châssis non clos cela aurais juste tout détruit dans les salle ou il y a juste eu de la fumée (car détection donc réaction) sachant que le courant n'a pas été coupé immédiatement sur l'ensemble de SBG et que les onduleurs ont du prendre le relais dans SBG1/3/4.

Et pour infos c'est pas parce que il y avais du bois dans la construction du DC que c'est forcément ce qui a facilité la propagation du feu, le bois a très bien pu subir un traitement avant sa mise en place.

Après là on jette la faute sur OVH à cause de ces plaquette commerciale, mais c'est pas mieux chez les concurrent :
[quote]
Les volumes EBS sont conçus pour se prémunir contre les défaillances en se répliquant dans la zone de disponibilité (AZ), offrant ainsi une disponibilité de 99,999 %
[/quote]
Cf : https://aws.amazon.com/fr/ebs/?ebs-whats-new.sort-by=item.additionalFields.postDateTime&ebs-whats-new.sort-order=desc

==> du coup c'est pareil on se dit que tu va pour le mieux dans le meilleur des monde
Sauf que si on creuse :
[quote]
Une zone de disponibilité comprend un ou plusieurs centres de données discrets dotés d'une alimentation redondante, d'une mise en réseau...
[…]
Si une application est partitionnée entre plusieurs zones de disponibilité, les entreprises sont mieux isolées et protégées des problèmes tels que les pannes de courant, **les coups de foudre, les tornades, les tremblements de terre, etc**. Les zones de disponibilité sont physiquement séparées par une distance significative, c'est-à-dire plusieurs kilomètres, de toute autre zone de disponibilité, bien qu'elles se trouvent toutes à moins de 100 km (60 miles) les unes des autres.
[/quote]
Cf : https://aws.amazon.com/fr/about-aws/global-infrastructure/regions_az/
Perso ce que je lis entre les ligne c'est que là aussi ma réplication est soit local soit peut être distante mais c'est pas sûr, par contre si on veux une vraie distance géographique il faut répartir (comme chez OVH).

Je pense clairement que cette histoire à juste mis au grand jour ce que tout le monde avais pris pour acquis mais en faite ne l'était pas.

A savoir :
- pas besoin de faire des backup j’ai une option ==> non cela ne dispense pas de backup
-pas besoin de prévoir un PRA je suis sur un stockage répliqué (sous entendu réplication géographique mais on a jamais posé la question au fournisseur pour confirmation car flemme) ==> non car selon la technologie c'est juste pas possible d'avoir une réplication **synchrone** entre 2/3 sites séparé de plusieurs centaines de kms avec une latence "importante"

Du coup on arrive à des conclusion tel que :

Le concept du backup automatisé (et facturé en option par OVH) est justement de le mettre dans un autre DC en cas de problème. C'est la base de la base, mais apparemment OVH aurait "omis" ce détails.

Alors que non le concept du backup c'est d'avoir une copie des données en "sécurité" sur un support différent de celui d'origine (donc en dehors du serveur d'origine pour faire simple).
C'est le concept du 3-2-1 qui implique d'avoir ce backup géographiquement ailleurs.

Au passage je rappel le concept du 3-2-1 qui a ma connaissance n'est de toute façons pas respecté avec une option de backup (car 1 seule copie et pas forcément hors site)
[quote]
3 - disposer de **trois copies** de vos données au moins ;
2 - stocker ces copies sur **deux supports différents**;
1- conserver une copie de la sauvegarde **hors site**.
[/quote]
Cf : https://www.veeam.com/blog/fr/how-to-follow-the-3-2-1-backup-rule-with-veeam-backup-replication.html (lien très orienté pour leur outils, mais le fondamentale reste le même).

P.S. Je ne fait pas cela pour dédouaner OVH et/ou enfoncer les clients qui ont perdus leurs serveurs.
Il faut juste a un moment prendre le temps de poser les bonne questions et de bien définir ces besoins.

Si demain un client loue un VPS à 5€ pour y mettre son business mais ne fait rien pour le protéger car il pense que c'est l'hébergeur qui va tout faire à sa place, il faut blâmer qui ?
L'hébergeur qui essaye de vendre son produit ? Le client qui ne veux pas dépenser 5€ de plus pour prendre un VPS ailleurs (pour y envoyer des backups) ? Le client qui a décidé de se lancer tout seule et/ou sur recommandation de "un ami qui s'y connais en informatique" ? Ou alors le prestataire qui lui a vendu le site et qui lui a dit de procéder ainsi car l'hébergeur gère pour pas cher ?

Dans cette malheureuse histoire c'est bien souvent du 50/50 à savoir OVH qui fait de très bonne plaquette commerciale qui vend du rêve édulcoré avec des suggestion (techniquement non vrai) et la personne qui achète sur base de plaquette commerciale sans demander les informations techniques derrière (si j'achète un service qui est vendu comme répliqué "géographiquement", je vais demander au prestataire la localisation des 2 sites pour ne pas se rendre compte que lors d'un sinistre les 2 sites "géographique" était à 500m de distances…).

Cordialement, janus57

Helpful (0)

janus57

Bonjour,

du coup ça sert à quoi de répliquer 3 fois sans distanciation, si ce n'est pour vendre le produit et pouvoir en faire la pub ?

comme dit plus haut cette réplication 3x c'est juste pour vendre et dire que le service et résilient à une panne localisé (perte d'un rack suite une un problème électrique local par exemple).
Il faut considérer cette réplication comme un RAID qui s'étend sur 3 infrastructures se trouvant dans 3baies et/ou salles différentes.

Enfin de toute manière c'est une fausse bonne idée de se dire qu'on est en sécurité car répliqué 3x, si pour une raison X ou Y cette réplication vient à échouer (corruption/bug software spécifique etc.) et que OVH doit restaurer une sauvegarde interne qui date de 48H pour remettre en route cette réplication, vous allez tenir OVH pour responsable car vous n'avez pas mis vos données en sécurité ?
Idem pour ceux qui prenne le RAID pour un système de sauvegarde, si votre RAID échoue vous allez tenir OVH pour responsable car vous n'avez pas surveillé le RAID ?

Autre exemple d'offre OVH ou là aussi la réplication est intra-DC mais pas explicitement indiqué dans l fiche produit (sauf si un employé de OVH me corrige) : https://www.ovh.com/fr/cloud-disk-array/
[quote]
Les données sont répliquées 3 fois sur différents domaines de pannes pour garantir une **disponibilité** maximale de vos fichiers.
[/quote]
le mot clé qui me dit que c'est PAS réplique sur plusieurs DC c'est "disponibilité" et le fait que ce soit la technologie CEPH (sinon il y aurais eu une notion de "sécurité" ainsi que la présence d'une ligne indiquant un solution de réplication asynchrone sur un stockage différent).

Enfin je vous met au défit de mettre en place une réplication 3x synchrone sur 3DC différents sans impacter vos perfs (car techniquement c'est possible mais les perfs vont en prendre un coup).

Cordialement, janus57

Helpful (0)

Contributor

Entièrement d'accord.

Pour moi il y a le problème du commerce dans notre société de la comm.
Mais là ovh fait simplement comme les autres. C'est toute la société civile qui est concerné par ce monde de la comm, du blabla et du vas y que je t'enfume.

Et il y a aussi le problème des clients finaux qui ont bossé avec des prestas (donc infogérants) qui eux n'ont pas fait le taf comme il faut (les infogérants). Pensant qu'OVH ferait tout le taf sans qu'eux est à s'investir dans la gestion des backups. Eux sont réellement en faute pour défaut de conseil (rappel, ovh ne fait pas de conseil).

Après il y a tout ceux dont le business reposent effectivement sur un serveur et qui refusent de foutre quelques dizaines d'€ tous les mois dans du conseil et/ou quelques € de + dans la gestion des backups. Là je ne vais pas en dire + parce que je vais être désagréable... Pour l'avoir vu trop souvent ça me rend dingue...
Si on fait sois même sur un serveurs SYS on s'en sort pour 30/40€ / mois et on peut y mettre un packet de backups dessus... Même en comptant l'infogérance on s'en sort pour 100/200€ / mois (serveur + gestion)... C'est peanuts quand on a des salariés à payer, des stocks à écouler, un business à faire tourner...

Tout cela bien évidemment n'enlève rien au fait que bcp de monde va y laisser des plumes... OVH bien entendu qui va perdre des clients, des millions en indémnisation, en image de marque... Mais également les clients qui ont perdu leurs datas, ou sont en rupture de service pendant 2 semaines...
Sans oublier les infogérants qui auraient mal fait leur taf, mais là tant pis pour eux, c'est juste de la sélection...

Helpful (0)

Bonjour à tous, avez vous du neuf sur la possibilité de récupérer les backups automatiques ?
Sur certains de mes VPS ils sont a nouveau disponibles, mais comment faire un montage ou une restauration quand l'IP de base attaché au VPS n'existe plus ? Existe-t-il une procédure quelque part ?
merci pour vos retours

Helpful (0)

Contributor

Si c'est la nouvelle gamme de VPS, OVH est entrain de les remonter à partir des backups.
Si c'est du public cloud je doute qu'il soit possible de remonter les VMs avec l'ancienne IP... Pour ça que généralement on utilise des IPFO sur ces services...

Mais vous pouvez tjrs tenter de contacter le support... Mais vous aurez + de chance ici ou sur twitter...

Helpful (0)

Merci Sich,
j'ai contacté le support sans succès. Je pense que les backups sont, pour certains, remontés. Mais je ne sais pas comment les rendre dispo car le VPS initial lui a disparu.

Helpful (0)

Bonjour @FranckG24

Si le VPS n'a pas été détruit : il est simplement redémarer.
Si le VPS a été perdu :
- et si vous avez l'option de backup automatique / un snapshot d'existant : vous devriez pouvoir lancer une restauration d'un des backup visible dans l'onglet idoine.
- si vous n'aviez pas l'option autobackup et qu'OVH dispose d'un backup interne : vous devez simplement patienter. Vous serez informé par mail quand le VPS auras été restauré
- s'il n'y a pas de backup interne et que la VM est perdu, le service et l'ip ont du être migré sur une nouvelle zone et vous devez réinstaller le VPS directement (et remonter vos services depuis votre backup).

Par contre, si vous aviez du Public Cloud => les services sont mort et les IP perdues.
Les images ont été transférées sur une nouvelle région directement (SBG7 de mémoire).
Dans ce cas là, vous devrez créer une nouvelle instance sur SBG7 et, lors du choix de l'image, choisir le backup en question (attention : même flavor/taille de disque que celle de l'instance de base).

Jalinn

Helpful (0)

'option de backup automatique / un snapshot d'existant : vous devriez pouvoir lancer une restauration d'un des backup visible dans l'onglet idoine.

Bonjour Jalinn,

Oui j'ai bien l'option de backup automatique, mais en sélectionnant une date de backup pour faire soit une restauration soit un montage cela ne fonctionne pas, cela génère une erreur.

Helpful (0)

fritz2cat officiel (d'avant la migration)

Voici pour info un retour que je viens d'avoir d'OVH.
> Chère cliente, cher client,

> Nous vous informons que nos équipes viennent de procéder à la reconstruction de votre VPS vpsXXXX.ovh.net à partir d'une sauvegarde que nous avons pu récupérer.

> Si vous avez souscrit des options telles que Snapshot (sauvegardes manuelles) et/ou Auto-backup (sauvegardes automatiques), vous pourrez utiliser leurs fonctionnalités dès la remise en service de votre VPS.
> Notez que l'accès à vos sauvegardes réalisées avant le 10 mars ne sera pas possible.

C'est j'espère pour moi et mes clients, le premier d'une grande série. A suivre

Helpful (0)

SteveD5

idem ... on nous a monté dans /mnt notre backup , par contre
selon votre serveur ... nous n'avons plus la base de données, les fichiers n'étant pas suffisant.

nous voulons que le backup soit remonté en "maitre" et pas en point de montage!

Helpful (0)

Newbie

nous voulons que le backup soit remonté en "maitre" et pas en point de montage!

Un backup c'est un backup, récupérez ce qu'il faut de votre backup dans votre espace de production.
Les sites web et les bases de données ne sont pas dans /mnt

Helpful (0)

Contributor

vous êtes sûr de ne pas être en rescue ?
Ou alors effectivement ils n'ont pas réussi à remonter votre VM et vous proposes simplement de récupérer vos fichiers (enfin ce qui est récupérable), à vous ensuite de remonter une VM... Faut voir avec le support dans ce cas...

Helpful (0)

LoicB6

bon j'ai aussi récupéré mon vps avec un backup du 9/3.
c'est un VPS 2016 je crois que j'ai eu chaud...

c'était bien indiqué dans le mail que les backups dans l'interface sont inutilisable, ils on restauré le plus récent qu'ils avaient.

Seul bémol mon pwd root ne marche pas... Heureusement j'avais un plesk dessus j'ai pu m'en sortir, mais impossible de me connecter en ssh. Quelqu'un a réussi ?

Helpful (0)