Jump to content

Récupération De Mes Données Sur Ma Boutique


Recommended Posts

Bonjour,

 

J'ai sur ma boutique des produits. Par mégarde, mon développeur faisaient des tests sur un module qu'il a développé et a supprimé des produits important que j'ai sur ma boutique.

 

J'aimerais les récupérer et les réinstaller sur ma boutique dans les memes catégories qu'ils y étaient.

 

Maintenant, mon hébergeur a restaurer un backup et voici ce qu'il me dit comme réponse:

 

Je crois qu'une partie du probleme provient du fait de l'indexation de la base de donnees. Le forfait Inno_db est assurément plus efficace en rapidite que le format de storage MyISAM, mais il comporte des désavantages qui a ce niveau n'est pas a neglige. Si la base devient corrompu ou il y a un crash dans l'indexation du fichier innodb, ca récuperation est quasi impossible.
 
Il faut a ce moment que l'usager/client, s'assure qu'il a une copie "fonctionnel" de toute sa base de donnees et de tous les fichiers .ibd qui sont les indexations. La structure et donnees seront bien dans les fichiers, mais sans une indexation correction, la base de donnees, ou cette partie, ne sera pas recuperable.
 
Donc dans le cas de votre programmeur, il y est probablement pour rien. le grand coupable est le choix du storage engine innodb qui je cris est inappropriée dans un environnement de serveur mutualise. 
 
Comme je vous l'ai deja ecrit pas le passe, moi meme pour l'installation de notre systeme de facturation, nous prenons un backup a tous les heures, et nous avons force le script php a faire un storage en MyIsam au lieu d'InnoDB C'est plus lent, mais plus facile a recuperer.
 
Ma question maintenant si je comprends la réponse de mon hébergeur est l'importation de la base de données INNO_DB ett comment je fais cela dans Prestashop 1.5.6.0 pour réimporter mes produits ?
Link to comment
Share on other sites

Ma seule conclusion est: change d'hébergeur, change aussi de "programmeur"

 

1/ A moins de disque en chocolat les crash bdd extrêmement rare.

2/ On peut très bien récupérer une bdd InnoDB, les index (si jamais ils posaient problème) on les reconstruit depuis le schéma. La difficulté principale n'est pas l'indexation mais les float/decimal/double dont la taille n'est pas dans l'idb mais dans le fmt si les 2 sont désync, il faut tatonner un peu (enfin pas avec PS puisque nous connaissons avec exactitude le format via le schéma)

3/ Quand on fait des manips dans la bdd, on fait les backup appropriés

4/ Aucune manip autre que delete/drop/truncate ne provoque de disparition de données excepté en cas de #1 et on sait tout retrouver si on a fait #3

5/ MyISAM n'est pas forcément plus lent qu'InnoDB, tout dépend de la fragmentation, du type de requête, de l'optim du moteur, et du volume de données en jeu. Certaines requêtes sont même plus rapide en MyISAM - notament les count(*).

6/ Une copie des fichiers de la bdd n'est pas un backup. C'est un snapshot et cela peut être totalement inexploitable si l'on doit changer le système.

7/ Quand on est hébergeur "mutu" si on sait que l'on est pas capable de faire de l'innoDB on désactive l'engine. Prestashop dans ce cas choisira MyISAM à l'install

 

Si tu as accès à un backup, pour retrouver tes produits, récupère les tables ps_product, ps_product_lang, ps_product_shop, ps_category_product (il peut y avoir d'autres tables satellite à récupérer si le "programmeur" a été plus que violent - en gros toutes les tables ps_product*). Récupérer == remonter le backup, refaire un backup des seules tables supprimées et réimporter

Link to comment
Share on other sites

Ce n'est pas un backup. C'est un snapshot (une capture des fichiers de base de données... étaient-ils ouverts, quel version de mysql exacte, les règlages du jeux de caractères ...)

Si tu as de la chance tu remontes un mysql (en croisant les doigts), tu copie les fichiers dedans ... tu te crées un user pouvant voir ces tables et tu fais un BACKUP.

 

Bon courage a toi.

Link to comment
Share on other sites

Réponse de mon hébergeur:  JE NE SAIS PLUS QUOI FAIRE !!!!!

 

 

C'est un point de vue exprime. Je ne peux rien dire d'autre. Faite une recherche sur internet, vous verrez ce que plusieurs en penses de InnoDB versus MyISAM. http://www.tux-planet.fr/mysql-les-principales-differences-entre-myisam-et-innodb/

Je ne crois pas que se soit un choix d'hebergeur, mais un choix de clients/programmeurs de prendre InnoDB ou non. Nous sommes la pour offrir les differentes options de storage, aux clients de prendre sa decision en toute connaissance de ces capacites.

Dans votre cas, c'est difficle de trouver une raison pour laquelle les fichiers ont disparus. Nous sommes intervenus apres coups, on ne sait pas quel periode de temps il y a eu entre la perte des fichiers .ibd et la premeire demande d'assitance.

Si vous verifiez la base de donnees infoconcep_chat, par rapport a infoconcep_cart, est que dans infoconcep_chat, les deux format de storage sont presents, InnoDB et MyISAM. Lorsque ils sont en MyISAM, vous avez 3 fichiers, .frm, .MYI et .MYD, dans le cas de innoDB, vous avez deux fichiers, .frm et .ibd.

Cependant dans la base infoconcep_cart, quelques tables sont aussi sous cette forme, mais plusieurs ont uniquement des fichiers .frm. Ou sont passes les restes des fichiers ? C'est une bonne question aux personnes qui avaient a intervenir directement sur le serveur.

Si vous verifiez les fichiers du repertoire infoconcep_cart, vous verrez que plusieurs fichiers de prestashop (il debute par ps_ ), ont uniquement des fichiers .frm. Ou sont passes les fichiers .ibd ? Il s'est assurement passes quelques choses, mais quoi. Tous nos copies de sauvegardes sont a peu pret semblables pour votre base infoconcep_cart. Pourquoi ? Parce que c'est exacetement ce qu'il y avait dans le serveur au moment de la prise du backup par r1soft.

On a meme demande assistance a R1soft, pour qu'il verifie l'installation, au cas ou quelques choses aurait mal fonctionner, et ce n'etait pas le cas.

R1Soft, c'est une solution assez fiable. Beaucoup de nos clients ont cette solution dans notre centre de donnees. Aussi bien des clients avec moins de serveurs, que des clients qui ont 1000 a 2000 serveurs avec nous.

Quant au point 7, apporte par un tiers comme argument, ca ne tient pas la route. Les deux storages engine fonctionnent tres bien et sur le meme serveur ou vous etes heberge ou sur d'autres de nos serveurs, aucun autre client a des problemes. Naturellement, on ne fait pas des miracle lorsque les fichiers en questions ne se retrouvent sur aucun fichiers des copies de sauvegardes. Nous ne sommes pas magicien.

Link to comment
Share on other sites

Une réponse qui en dit long. Le lien fournit ...

On parle d'un temps ...:

- que les moins de 20 ans ne peuvent pas connaitre (ah si mais tout juste)

- où les disques SSD c'était de la science fiction

- où les Prestashop n'existait pas

- parlons même pas de MariaDB

- la norme était PHP4

- ...

- où on venait de découvrir le feu...

 

Sans déconner c'est quoi l'argument là ? Des scientifiques très réputé défendaient bec et ongle que l'éther existait il y a a peine 120 ans... compte tenu du temps en informatique ce papier a à peu près le même age. N'en déplaise à ton hébergeur la technologie à évolué depuis 2007 dans le reste de l'univers

 

Donc l'hébergeur a perdu les fichier idb (table content) de certaines tables, mais pas les .frm (table definition) ... ceci n'est pas dans la sphère de manipulations possible d'un programmeur au sens cité, ni d'un utilisateur d'une solution mutu ... Il faut être root ou mysql pour effacer ces fichiers ou que le disque soit parti en vacances sur Betelgeuse.

 

Je n'ai pas dit qu'on ne devait pas proposer de l'innodb mais si je cite "le grand coupable est le choix du storage engine innodb qui je cris est inappropriée dans un environnement de serveur mutualise. " donc si c'est vrai on met en place quelque chose de fonctionnel pour des clients pas quelque chose qui va leur péter à la g....e

 

Donc R1soft (je ne sais pas ce que c'est) à fait des backups (je ne vois que des snapshops) à plusieurs reprise (toutes nos copies) et donc ... tu as passé combien de temps avant de demander une restauration? 1j 2j 10j ...

 

 

Bon là ce qui parait clair c'est que toutes les données sont soit perdues soit vérolées ... je ne peux que compatir à ta douleur.

 

PS: Je suis parti sur l'idée que le moteur innodb était configuré de manière moderne 1 fichier par table. Mais... par défaut avant les 5.5 de mysql l'innodb s'installait avec un seul fichier pour toutes les tables ... ibdata1.idb ... c'est ancien mais c'est peut-être là que résident des données ... dans un gros fichier partagé par toutes les tables innodb du système, les tiennes et celle des autres ... enfin c'est juste une hypothèse de dernière minute.

Edited by doekia (see edit history)
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...