OVH Community, votre nouvel espace communautaire.

La sauvegarde de ma base de données via phpmyadmin ne marche pas ?


nibik
03/01/2014, 11h34
concernant le point 2, à J+1 tout est rentré dans l'ordre et les 2 bases on presque la même taille à 1Mo près.

Tout semble Ok, en ayant utilisé le .dump par mail + l'importation par requêtes SQL en petits morceaux.

Merci à tous pour votre aide

Excellente année à vous

nibik
02/01/2014, 12h00
Merci Nowwhat, je prends bonne note de toute tes indications et je garde ça sous le coude !! C'est la meilleure méthode selon toi ?

Car info de dernière minute, j'ai retenté une importation via phpmyadmin avec des requêtes SQL issues du .dump, en plein de petits morceaux (moins de 8Mio), moitié moins que la capacité de 16, et cette fois s'est passé !! Mais :

- j'obtiens une bdd de 238Mio (contre 200Mio pour l'originale), c'est normal ? J'ai comparé les 2 bases (la sauvegarde restaurée et l'originale) ;
1 - sur pypmyadmin, je constate que la différence des 40Mio provient principalement de la table-post : 129Mio sur l'originale, 170 sur la sauvegarde restaurée. Cela pourrait provenir d'où ?
2 - sur OVH, gestion des bases SQL j'ai cette chose étrange :
originale : 105.061 Mo (je ne comprends pas pourquoi c'est une taille différente encore ?)
sauvegarde restaurée : 13.118 Mo .... ?

Qu'en pensez-vous ?

Nowwhat
02/01/2014, 08h56
Aha, si t'as l'accès SSH:
Citation Envoyé par nibik
...
Alors déjà nowwhat, ovh me précise que j'ai bien accès au ssh... je dois m'y prendre comment ?
puis, suivant le doc ( ) http://guide.ovh.com/ImportBaseMySQL ou tu trouve en bas:
Par ligne de commande
Pour les offres Plan, vous avez la possibilité de faire directement la sauvegarde par ssh. Vous vous connectez donc en ssh sur votre espace, puis vous vous dirigez dans le répertoire où vous avez placé le fichier à importer (avec FTP bien sur) et vous tapez cette commande :
cat nom_de_la_base.sql | mysql --host=serveur_sql --user=nom_de_la_base --password=mot_de_passe nom_de_la_base
Exemple: J'ai un 90Plan donc 5 bases de 40 Mo.
je sauvegarde ma base nommé papyteame107 avec bien sur le même nom de l'utilsateur qui existe sur le serveur "mysql5-29.90":
mysqldump -upapyteame107 -pmon-mot-de-passe -hmysql5-29.90 papyteame107 > mon-dump.sql
L'exportation dure environ 3 secondes.
Puis, pour preuve:
ls -al *.sql
me donne
-rw-r--r--+ 1 papyteam users 38493442 Jan 2 08:14 mon-dump.sql
soit un fichier 'dump' de 38 Mo.

Impossible bien sur de re-importer avec PHPMyadmin ce genre de fichier sur un Mutu OVH.

Je procède à l'importation d'une autre base vide (de mémoire, j'en ai 4 pour mon Mutu) sur le serveur MySQL "mysql5-32.90" - le nom de cette base labas est "papyteamtest" - l'utilisateur aussi.
cat mon-dump.sql | mysql --host=mysql5-32.90 --user=papyteamtest --password=mon-mot-de-passe papyteamtest
Et hop.
C'est passé - ça pris bien 5 secondes.

Il me semble que faire la même chose avec une base de 200 Mo, c'est probablement possible.
Mais c'est quand même un sacre pavé.

Le découpe de ton fichier mon-dump.sql en deux, voir trois ou même quatre portions, c'est possible.
On parle d'un fichier "dump" non zippé bien sur, donc pas la version .gz

Exemple:
Le fichier mon-dumpl.sql d'origine (plus petit - que deux tables présent avec leur données, histoire de simplifier la démo) : http://pastebin.com/PfBCNdzC
Maintenant, je le coupe en deux:
-rw----r--+ 1 papyteam users 48259 Jan 2 08:41 mon-dump-1.sql => http://pastebin.com/3NVAhHxi
-rw----r--+ 1 papyteam users 2077 Jan 2 08:42 mon-dump-2.sql => http://pastebin.com/nAceuaV1
Donc : mon-dump-1.sql + mon-dump-2.sql == mon mon-dump.sql d'origine.

Puis (j'ai vide la base papyteamtest avant de débuter):
cat mon-dump-1.sql | mysql --host=mysql5-32.90 --user=papyteamtest --password=mon-mot-de-passe papyteamtest
cat mon-dump-2.sql | mysql --host=mysql5-32.90 --user=papyteamtest --password=mon-mot-de-passe papyteamtest
Une controle avec https://phpmyadmin.ovh.net me montre bien que les deux tables, présent dans les deux fichiers mon-dump-1.sql et mon-dump-2.sql ont bien été importé dans la base papyteamtest sur mysql5-32.90

De la même façon, sur un Mutu Pro, j'ai bien réussie à importer une base de 256 Mo (fichier dump SQL brut, non comprimé)

FAIT TRES ATTENTION:
Utilise Notepad++ ou UltraEdit pour le traitement de texte concernant ces fichiers sur ton PC.
Utilise la méthode transfert FTP 'binaire' !!!
Sinon, le encodage risque de changer - et ça, ça fout tout en l'air.
N'oublie jamais que l'encodage des characters sur un PC (ou MAC) n'est pas la même qu'un sur un système Debian (Linux).

nibik
02/01/2014, 00h20
Merci à tous d'essayer de m'aider... pas simple tout ça

Alors déjà nowwhat, ovh me précise que j'ai bien accès au ssh... je dois m'y prendre comment ?

bossboss, j'ai tenté bigdump, résultat : j'ai 89 tables sur 117 qui s'ajoutent, et bizarrement à l'inverse la sauvegarde crée une bdd de 230Mio... alors que l'originale fait 200Mio...

Enfin gaston, j'ai créé un fichier "/sauvegarde" avec dedans la sauvegarde.gz et un fichier import.php avec dedans :
error_reporting(E_ALL); // Activer le rapport d'erreurs PHP

$db_charset = "utf8"; /* mettre utf8 ou latin1 */

$db_server = "xxxxxx"; // Nom du serveur MySQL. ex. mysql5-26.perso
$db_name = "xxxxxx"; // Nom de la base de données. ex. mabase
$db_username = "xxxxxx"; // Nom de la base de données. ex. mabase
$db_password = "xxxxxx"; // Mot de passe de la base de données.

$cmd_mysql = "mysql";

$archive_GZIP = "sauve_base_format_gzip.gz";

if (!is_file($archive_GZIP)) echo "Le fichier ".$archive_GZIP." n'existe pas
\n";

echo " Restauration de la base $db_name par mysql depuis le fichier $archive_GZIP
\n";
$commande = "gzip -d < ".$archive_GZIP." | ".$cmd_mysql." --host=".$db_server." --user=".$db_username." --password=".$db_password." ".$db_name;
$CR_exec = system($commande);
?>

j'obtiens 45 tables seulement sur 117, et un poids de 2Mio..

Gaston_Phone
01/01/2014, 20h48
Citation Envoyé par nibik
- la solution proposée sur ce forum par Gaston est KO : http://www.wordetweb.com/word-et-web...-script-FR.htm
C'est curieux cette méthode fonctionne partout.
Peux(tu préciser ce que tu as fait ?

bossboss
01/01/2014, 20h03
Citation Envoyé par nibik
Bonjour et bonne année à tous o//

Je ne comprends pas, j'ai découpé le fichier en morceaux de 10Mo et ça ne marche pas... phpmadmin plante.


J'ai testé toutes les solutions proposées ici et rien ne fonctionne ;

- la solution OVH est KO : http://guide.ovh.com/ImportBaseMySQL

- la solution proposée sur ce forum par Gaston est KO : http://www.wordetweb.com/word-et-web...-script-FR.htm



ça sent pas bon.........
Tu peux essayer Big DUMP.

nibik
01/01/2014, 19h39
Bonjour et bonne année à tous o//

Je ne comprends pas, j'ai découpé le fichier en morceaux de 10Mo et ça ne marche pas... phpmadmin plante.


J'ai testé toutes les solutions proposées ici et rien ne fonctionne ;

- la solution OVH est KO : http://guide.ovh.com/ImportBaseMySQL

- la solution proposée sur ce forum par Gaston est KO : http://www.wordetweb.com/word-et-web...-script-FR.htm



ça sent pas bon.........

Nowwhat
31/12/2013, 15h05
Citation Envoyé par nibik
.....
Pour l'import, via phpmyadmin c'est ça ? ( à condition que mes morceaux fassent moins de 16mio)
Exact.
Et si t'as un accès SSH (ou t'es capable d'écrire une ligne PHP) tu importe sans l'aide de PHPMyadmin d'OVH qui fait sauter le plafond de 16 Mo.

nibik
31/12/2013, 14h59
Merci à toi, je vais essayer ça !

lorsque tu dis "découvre le format", = ça change quelque chose ?

Pour l'import, via phpmyadmin c'est ça ? ( à condition que mes morceaux fassent moins de 16mio)

Nowwhat
31/12/2013, 14h34
Plan B:

Procure-toi un edituer de texte potable: notepad++

Ouvre avec ce traitement de texte ton fichier .sql (ou .dump)

Découvre le format de ce fichier.
Coupe-le en morceau - chaque fois, découpe au debut de la ligne.

Importe tes fichiers morecau-1.dump - morecau-2.dump etc.

Fini.

nibik
31/12/2013, 14h21
Bonjour,

Pour tester les différentes sauvegardes, nous avons créer une copie du forum avec une nouvelle base... mais le problème reste entier : impossible de restaurer : on a un blocage "max_execution_time"...

Que faire ?

bon réveillon à tous

Gaston_Phone
25/12/2013, 22h32
Citation Envoyé par nibik
Quand je regarde sur phpmyadmin ma bdd fait 198,5 Mio
un sql de 131Mo ou .sql.gz de 36Mo vous paraissent toujours cohérents ? ça semble hyper light..
En sortant tous les espaces non remplis des champs --> OUI.

Rizz
25/12/2013, 22h21
Pourquoi pas.
Quand tu regarde sur phpmyadmin tu as le poids des index and cie.
Plus prendre en compte que la compression de texte c'est ce qui est le plus efficace.

Par contre pour l'importation ensuite ? C'est pas limité a 16Mo sur les .pro ?

nibik
24/12/2013, 14h16
Quand je regarde sur phpmyadmin ma bdd fait 198,5 Mio

un sql de 131Mo ou .sql.gz de 36Mo vous paraissent toujours cohérents ? ça semble hyper light..

J'effectue les contrôles ce soir ou demain (pas accès depuis mon poste de travail)

Gaston_Phone
24/12/2013, 12h30
Citation Envoyé par Nowwhat
Avant de créer un "gz", le fichier "sql' est "pipé" dans gzip.
L'ensemble de ce deux est forcement plus longue et 'intensif' que la fabrication d'un fichier dump sql seul..
Curieusement c'est le contraire que j'ai constaté pour mes sauvegardes.

Je tombais souvent en "Time-Out" pour une sauvegarde SQL de grosse base.
Et jamais de problème pour la sauvegarde de la même base en mode ".sql.gz".

Nowwhat
24/12/2013, 12h17
Citation Envoyé par Gaston_Phone
Tests à effectuer de préférence sur les ".sql.gz" qui sont moins touchés par les "Time-Out".
Avant de créer un "gz", le fichier "sql' est "pipé" dans gzip.
L'ensemble de ce deux est forcement plus longue et 'intensif' que la fabrication d'un fichier dump sql seul.
L'avantage de "gz" est que, pour le transfert FTP, ça se passe plus vite.

Gaston_Phone
24/12/2013, 11h59
Citation Envoyé par nibik
Mais je vais tester les différents moyens de contrôle dont tu parles, merci.
Tests à effectuer de préférence sur les ".sql.gz" qui sont moins touchés par les "Time-Out".

nibik
24/12/2013, 10h42
Merci beaucoup pour votre aide !

J'ai peur que la sauvegarde ne soit pas complète à cause d'un temps de script trop long, car le temps d’exécution d'un script est limité à priori.

Mais je vais tester les différents moyens de contrôle dont tu parles, merci.

Nowwhat
24/12/2013, 10h17
Citation Envoyé par nibik
.....
Qu'en dîtes vous ? Ce n'est pas "peu" pour un forum de 4500 membres et 126000 messages ? Ces sauvegardes sont-elles sûres à 100% ou y-a-t-il un risque ?
Pourquoi cette question ?
Pourquoi tu n’ouvre pas ton fichier "sql" avec un traitement de texte (notepad++ est parfait pour faire ça)

Puis, découvre que la structure d'une sauvegarde MySQL possède une structure toute à fait lisible.

Tu trouveras la table qui liste toutes tes utilisateurs.
T'en trouve 4500 ?
Tu trouvera la table qui contient toutes les messages de ton forum.
Tu trouves les 126000 entrées ?

Compte avec l'accès PHPMyadmin le nombre des tables.
Compte maintenant dans ton fichier SQL le nombre des "CREATE TABLE" (notepad++ possède la fonction recherche et compter).
Si tout va bien, t'as la même nombre des tables.

Gaston_Phone
24/12/2013, 09h00
Pour moi c'est logique.
Il est préférable d'utiliser la solution qui travaille avec les fichiers compressés ".sql.gz" .

nibik
24/12/2013, 00h58
Bonsoir,

Nous avons testé les 2 solutions :

- le script proposé par OVH (solution 3) : http://guide.ovh.com/BackupBaseMySQL
j'obtiens un ".sql" à 131 Mo + un ".sql.gz" à 36 mo

- le script de cette page : http://www.wordetweb.com/word-et-web...-script-FR.htm
j'obtiens un ".sql.gz" à 36 mo

Qu'en dîtes vous ? Ce n'est pas "peu" pour un forum de 4500 membres et 126000 messages ? Ces sauvegardes sont-elles sûres à 100% ou y-a-t-il un risque ?

Merci

Gaston_Phone
23/12/2013, 15h54
Et pour restaurer la base de données --> OVH - Sauvegardes et Restaurations de Bases de Données via un script.

nibik
23/12/2013, 14h47
Merci Nowwhat pour l'info je prendsbonne note, je vais déjà essayer de réussir à sauvegarder la bdd, ensuite je regarder pour l'importation

Nowwhat
23/12/2013, 14h36
Citation Envoyé par nibik
Ma base de donnée fait 104Mo environ selon mon panneau admin OVH, 130Mo d'après le .dump
Pour l'importer, https://phpmyadmin.ovh.net te montre " ... (Taille maximum: 16Mio) ..." - il s'agit d'un limite imposé à Apache, le serveur web.
Donc, le upload dans https://phpmyadmin.ovh.net est impossible.

Dans ce cas il faut utiliser l'ancien méthode.
a) Upload avec FTP (lui: illimité) ton fichier dump.
b) Adapte cette ligne pour "importation":
Code PHP:
system("mysql -u utilisateur-pmot-de-passe -h  serveur_sql  nom-de-la-base < nom_de_la_base.sql"); 
(petit détail: l'option -p et le mot de passe sans espace !!)

Puis, avec ton navigateur, visite ton fichier PHP qui va exécuter l'importation.

nibik
23/12/2013, 14h03
Re,

Par contre sur la page http://guide.ovh.com/BackupBaseMySQL il donnent un autre script, lequel est le mieux ?

echo "Votre base est en cours de sauvegarde.......

";
system("mysqldump --host=serveur_sql --user=nom_de_la_base --password=mot_de_passe nom_de_la_base > nom_de_la_base.sql");
echo "C'est fini. Vous pouvez récupérer la base par FTP";
?>

Enfin, j'ai un doute sur la façon dont je dois exécuter le script... via phpmyadmin ? Je n'en ai jamais fait.

nibik
23/12/2013, 12h24
je vais essayer ça, merci pour cette réponse rapide

Gaston_Phone
23/12/2013, 12h18
Essaie avec un script --> OVH - Sauvegardes et Restaurations de Bases de Données via un script.

nibik
23/12/2013, 12h16
Bonjour,

Je souhaite copier ma base de données, pour l'importer sur un nouveau forum phpbb. J'ai lu votre guide : http://guide.ovh.com/BackupBaseMySQL mais j'ai des difficultés à sauvegarder ma bdd ;

- Avec la solution 1 en recevant le .dump par mail, comment le ré-injecter ensuite ? ça ressemble à ce topic : http://forum.ovh.com/showthread.php?...ase-sql-(dump)
- via phpmyadmin, l'écran devient blanc et plus rien..

Ma base de donnée fait 104Mo environ selon mon panneau admin OVH, 130Mo d'après le .dump

Merci pour votre aide !