Quel délai réel pour la restauration "réel" d’une base ?

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...

```text une commande est du genre :
```text
mysqldump --host=serveur --user=utilisateur --port=port --password=password nom_de_la_base > nom_de_la_base.sql
```

par confort, création d'un fichier `.my.cnf` dans le dossier courant:
```text
[client]
user=
password=
host=
port=
```
sauvegarde:
```text
# une base
mysqldump --opt --databases nom_de_la_base > nom_de_la_base.sql
# une base, gzip
mysqldump --opt --databases nom_de_la_base | gzip > nom_de_la_base.sql.gz
```

restauration:
```text
# une base
mysql --verbose nom_de_la_base < nom_de_la_base.sql
# une base, gzip
gunzip < nom_de_la_base.sql.gz | mysql --verbose
```

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

Oui effectivement c'est ce que je fais actuellement :
mon site _pro1_ va taper sur la base _pro2_ sur laquelle j'ai importé la sauvegarde de la base _pro1_

Les admins OVH sont censés examiner ce problème de restaurations impossibles sur la _pro1_ ...

Bon, résultat des courses :
Base de données défectueuse.
Je l'ai supprimée. J'en ai recréé une autre.
Et j'ai importé le fichier de la sauvegarde du Manager.

A priori tout va bien.
Un moyen de vérifier l'intégrité de la base ?

je ne connais pas de moyen en dehors de restaurer pour tester (l'option --verbose est utile en cas d'erreur)

J'ai trouvé via ce script sur internet :
https://www.scriptol.fr/sql/verifier-tables.php
Je vais l'essayer…

si tu veux, mais c'est pour les tables sur le serveur
juste des commandes mysql :o/

Oui c'est vrai qu'on peut checker les tables avec phpMyAdmin...

J'ai quand même un petit souci avec ces bases OVH, là...
- la sauvegarde depuis le manager est OK (en tous cas le fichier texte commence et ferme bien)
- par contre l'export via phpMyAdmin plante toujours avant la fin aujourd'hui.
Pas rassurant...

oui, ce n'est pas le même principe...
manager c'est avec mysqldump
phpmayadmin, c'est avec php
mais ta base ne semble pas suffisamment grosse pour poser soucis?

Ben oui... Je l'ai réduite en supprimant ou vidant des tables non nécessaires.
Elle fait 57Mo maintenant contre + de 100Mo avant.
Mais toujours impossible de faire un export complet avec phpMyAdmin...

- Si je fais une analyse ou un check des tables avec phpMyAdmin j'ai un OK partout (sauf sur 2 tables InnoDB. Normal donc si j'ai bien compris)
- Par contre je n'ai pas encore faire de Somme de contrôle / Optimiser / Réparer

57 ou 100 c'est pas gros, quel est ton CMS?

Joomla

Oops... les 2 tables qui n'avaient pas le OK n'étaient pas des InnoDB mais des MEMORY. Mais c'est Normal apparemment d'avoir ce résultat -là.

J'ai fait un Somme de contrôle et obtenu un nombre ≠ de 0 pour chacune des tables non vides. (je ne sais pas quoi faire avec cette info…)

Par contre j"hésite à faire Optimiser ou Réparer vu que phpMyAdmin ne réussit pas à exporter la base...

sur des tables innoDB, pas faisable
tu as contrôlé les tables, pas d'erreurs?

si besoin:
https://www.percona.com/blog/2008/07/04/recovering-innodb-table-corruption/

tu as des messages d'erreurs à communiquer?

Oui j'ai contrôlé (check) toutes les tables avec phpMyAdmin : Pas d'erreur
- les MyISAM sont OK
- les InnoDB sont indiquées OK. Mais d'après le lien que tu m'envoies, ça ne signifie pas quelles ne soient pas corrompues...
- les MEMORY renvoie " The storage engine for the table doesn't support c..."

Je n'ai pas de messages d'erreurs en faisant fonctionner le site.
Mais tu me parlais peut-être de checker avec les outils de Percona, non ?

non, non, je ne te comprends plus, si pas d'erreurs pourquoi veux tu réparer?

> Mais toujours impossible de faire un export complet avec phpMyAdmin...

qu'est ce qui te fais dire cela alors??

ça me dépasse, joomla marche ou pas?

Ben là je marche sur des œufs parce que :
il y a eu des soucis de base de données qu'il a fallu supprimer (elle ne voulait plus restaurer une sauvegarde réalisée 1h30 avant...).
Et je me dis que "possiblement" la base merdait déjà avant (=au moment de la sauvegarde).

Effectivement pour l'instant je n'ai pas de souci visible (=Joomla marche) mais comme je vais construire sur cette base, j'aimerais être sûr des fondations...

L'export n'est pas complet avec phpMyAdmin (encore un problème donc...) car le fichier résultant est s'arrête brutalement au milieu de l'export d'une table.

Par contre la sauvegarde depuis le manager est complet.
(-- Dump completed on 2019-01-31 17:51:40)

du mal à te suivre, utilise `mysqdump --verbose` pour tester, import/export

Oui je comprends…

En fait il y a des soucis avec phpMyAdmin : les sauvegardes ne vont pas au bout. Elles s’interrompent à différents moments. Et à la fin du fichier de sauvegarde il y a un code html qui est inséré par phpMyAdmin qui mentionne :

> MySQL a répondu :
> 2006 - MySQL server has gone away
> Warning in ./libraries/OutputBuffering.php#88
> Cannot modify header information - headers already sent by (output started at /home/phpmyadmin/www/libraries/export.lib.php:169)

Pas assez de mémoire allouée par OVH à la base ?

ta base n'a pas vraiment de quoi mettre à genoux un serveur...

> 2006 - MySQL server has gone away

peut-être mauvaise config du serveur?
https://stackoverflow.com/a/9479681/9580455

ou les incidents incessants du datacenter de paris depuis décembre?

mais la seule chose qui fera référence, c'est mysqldump, pas un script php (PMA)

Bonjour,
Peut-être ai-je mal lu mais combien de temps pur restaurer un site Web avec snapshot?
Mon site de https://pourmonmec.com/ parfum aphrodisiaque reçoit des visites et je ne souhaite pas faire fuir les clients.
Merci pour votre réponse.

tu parles de quoi? ftp ou base de données?
ftp, souvent des bavures, plusieurs heures, timeout 72h
mais tu peux le faire manuellement, plus sûr: https://docs.ovh.com/fr/hosting/restauration-ftp-filezilla-espace-client/

base: pas entendu parler de délai très long

bonjour, je relance la question quel délais pour une restauration de site complete..
J'ia tache ne cours depuis 3h pour monsite
cordialement

je relance la réponse

je ne sais pas si c'est un dogme, mais le ftp, c'est plutôt le lendemain j'ai l'impression, si pas de timeout 72h

réponse du support:
> Le délai de récupération de sauvegarde peut varier entre 12 et 72 heures selon la taille de la sauvegarde en question.
> Je vous prie de patienter, le temps de la finalisation de l’opération.