Bonjour,
Suite à une fausse manip dans le traitement de données de la base de données, j’ai souhaité revenir en arrière et faire la restauration d’un snapshot de la base que j’avais fait antérieurement sur le manager OVH.
Donc je demande la restauration sur le manager. Ça mouline quelques minutes.
Puis j’ai le signal « La restauration de la sauvegarde a bien été effectuée. »
Je pense que tout va bien mais je me rends compte que le contenu du site Joomla reste celui de la version avec la fausse manip…
Ça n’est pas immédiat ?
Il faudrait que je vide la base avant ?
Je suis sur : Hébergement Pro - Cluster 003 et Filer 318
Merci pour l’aide
Paul
si c'est terminé, tu ne vois plus rien voir dans les tâches en cours
si il y a eu une erreur, tu ne le vois pas non plus 
tu peux aussi récupérer avec phpmyadmin, le snapshot j-1 ou j-7, et le réimporter dans le current. tu verras explicitement certaines erreurs éventuelles
J'ai fait des sauvegardes de la base à chaque étape de mes manipulations sur la base. Je vais essayer de m'en servir pour ne pas perdre trop de travail…
Là je viens de supprimer les tables de la base avec phpMyAdmin.
Puis j'ai fait la restauration depuis le Manager. Ça a mouliné. Message « La restauration de la sauvegarde a bien été effectuée. »
Mais la base est vide : aucune table visible dans phpMyAdmin.
Il y a un problème du côté OVH là…
Comment faire ?
Bon là j'essaye de restaurer la base depuis mon Mac avec phpMyAdmin, mais ça va ramer avec ma connexion lente…
C'est fiable avec phpMyAdmin ?
Il y a des logs pour vérifier que tout c'est bien passé ?
un table sauvegardée dans le manager doit être restaurée via le manager ou en ssh avec mysqldump
pour restaurer avec phpmyadmin (pma), une base doit avant avoir été exportée avec pma
quand tu te connectes à pma, tu choisis la date du snapshot
Moi j'ai simplement téléchargé la sauvegarde depuis le mail d'ovh :
La sauvegarde de votre base de données xxx_1.mysql.db a été créée avec succès.
Vous pouvez restaurer votre base de données à partir de cette sauvegarde depuis votre espace client.
(…)
Si vous souhaitez conserver la sauvegarde de votre base sur votre ordinateur, vous pouvez la télécharger en cliquant sur ce lien : …
C'est cette sauvegarde téléchargée que j'essaie d'installer via pma
C'est pas bon ?
non, ce n'est pas bon
je pense avoir été clair dans mon message précédent
pma est indépendant
le manager c'est mysqldump
Oui tu avais été clair…
Là je découvre ssh et je ne connais rien à mysqldump (je suis sur Mac)
Je ne suis pas sorti de l'auberge…
mysqldump n'est pas obligatoire, le manager le fait
moi je te suggérais plutôt ' d'exporter avec pma "j-1" et réimporter avec pma dans "current"
> mysqldump n'est pas obligatoire, le manager le fait
Enfin… le manager le fait normalement. Car en ce moment il est dans les choux pour restaurer.
A ce que je vois le fichier téléchargé MySQL dump 10.13 semble correct (commence et fini bien)
Il faut vraiment que j'essaie de restaurer mon dump fait à 17:36
Trop de travail sinon.
- ou j'attends que OVH rétablisse la restauration via manager (?)
- ou je te demande de l'aide pour le mysqldump 
J’ai pensé à un quota de base de données dépassé (?) à cause de toutes les sauvegardes que j’ai faites…
« Si vous dépassez l’espace de stockage recommandé, vos droits seront limités à un accès en lecture seule. »
Mais non : après avoir fait le ménage, recalculé les quota, et réssayé de réinstaller. Toujours rien.
Pas mieux en essayant de restaurer la sauvegarde de j-1
Un problème côté OVH donc, non ?
Je vais regarder mysqldump…
une commande est du genre : <br />```text<br />mysqldump --host=serveur --user=utilisateur --port=port --password=password nom_de_la_base > nom_de_la_base.sql<br />```<br /><br />par confort, création d'un fichier `.my.cnf` dans le dossier courant:<br />```text<br />[client]<br />user=<br />password=<br />host=<br />port=<br />```<br />sauvegarde:<br />```text<br /> # une base<br />mysqldump --opt --databases nom_de_la_base > nom_de_la_base.sql<br /> # une base, gzip<br />mysqldump --opt --databases nom_de_la_base | gzip > nom_de_la_base.sql.gz<br />```<br /><br />restauration:<br />```text<br /> # une base<br />mysql --verbose nom_de_la_base < nom_de_la_base.sql<br /> # une base, gzip<br />gunzip < nom_de_la_base.sql.gz | mysql --verbose<br />```<br /><br />https://dev.mysql.com/doc/refman/5.7/en/using-mysqldump.html
Merci pour ces lignes précieuses. Ça me semble encore trop délicat à utiliser. Mais je vais m'y mettre très prochainement et tes conseils me serviront !
J'ai essayé de réimporter le mysqldump, généré par le Manager, et que j'avais téléchargé. Tout le process a semblé très bien se passer, mais au final la base était toujours vide après…
J'ai aussi suivi ton conseil et récupéré avec phpmyadmin, le snapshot j-1. Par contre j'ai eu un blocage d'activité de 1440 secondes quand j'ai essayé de le réimporter dans le current.
En tous cas, impossible d'importer quoi que ça soit dans la base (Manager et phpMyAdmin) depuis que je l'ai vidée en fin d'après-midi.
Nous ne pouvons pas actuellement restaurer les versions de sauvegarde de notre base de données chez OVH.
Il y a un comme un souci…
les bases sont grosses?
je pense que tes exports ont une erreur 
Elle font dans les 95Mo
J'espère que les exports sont OK, parce que sinon c'est la grosse galère…
Il y a un moyen de vérifier l'intégrité des exports ?
J'avais eu un soucis ± similaire début janvier :
https://community.ovh.com/t/restaurer-database-effacer-lancienne-avant
C'est pour ça que je me demande si ça ne vient pas d'OVH (j'ai cru comprendre que le site était en préparatif de migration)…
je ne connais pas de moyen en dehors de restaurer pour tester (l'option --verbose est utile en cas d'erreur)
95Mo, en gzip, cela induit une base de 6 ou 700 Mo environ, donc tu ne peux tester sur une autre base dans un hébergement "pro" pour le test
Bon ce matin ton message m'a fait un peu flipper, évidemment : " je pense que tes exports ont une erreur "
J'ai réessayé divers imports et j'ai pu :
1° importer sur la base "défectueuse" la sauvegarde OVH d'un autre compte Pro mais qui ne fait "que" 54Mo
Ça a pris du temps, ± 45 mn, mais ça a fonctionné.
Là je flippe et conclus aussi que le souci vient de mon côté…
2° importer, comme tu le proposais, la sauvegarde OVH de la base problématique sur un autre compte Pro. Et là ça a marché et assez rapidement.
Là mon moral remonte car je me dis que le problème vient donc d'OVH (problèmes de liaison, stabilité, timeout, etc. vers la base "défectueuse") …
NB : ma sauvegarde OVH (celle que j'essaie de remettre depuis le début), pèse 92Mo et une fois réinstallée sur l'autre compte Pro fait 103Mo.
J'imagine que je dois la télécharger gzippée depuis OVH et qu'elle doit se décompresser automatiquement sur mon Mac à la fin du download pour arriver aux 92Mo.
quand je télécharge une sauvegarde du manager, j'ai un fichier: mysql584.xxx.2019-01-23-21h42.gz
donc au format gzip, qui a 2 à 3 fois moins de poids que le format "sql" (du texte en fait)
si ton Mac décompresse automatiquent, c'est un fonctionnement de ton système qui m'échappe.
si ta taille finale décompressée fait moins de 400Mo, tu peux donc alors l'injecter dans les petites bases accessoires d'un hébergement pro
mais non compressée ou pas, le manager s'adapte si tu importes un fichier pour restaurer
OK
Bon je viens d'effacer la base d'un autre Pro et réimporter la sauvegarde OVH : nickel
C'est à dire que j'arrive à importer là la même sauvegarde que je n'arrive pas à importer sur mon autre hébergement Pro…
Là on bascule du côté "dysfonctionnement OVH"…
si je comprends
* tu as réussi sur un autre hébergement pro (ex pro2),
* tu échoues sur un hébergement pro spécifique (ex pro1)?
si c'est le cas, tu peux te servir de la base sur pro2, sous réserve qu'elle soit dans le même datacenter j'imagine
au moins temporairement, le temps de comprendre