Mauvaise sauvegarde MySQL

Bonjour,
J'ai quelque chose que je comprends pas sur mon serveur. Si un expert MySQL pouvait m'expliquer à défaut de m'aider...

Voilà. Je faisais de mauvaises sauvegardes de mes bases de données. En effet, j'ai appris hier après mon problème que j'aurais du sauvegarder mes bases en faisant un mysqldump puis en sauvegardant le fichier créé. Alors que jusqu'à maintenant, assez naïvement, je sauvegardais le dossier mysql de mon serveur (donc les fichiers frm, MYI, MYD).

Hier gros soucis. Je vous passe les détails mais je merde complètement dans un truc et je me dis, bon... plutôt que de passer 2h à réparer ce que j'ai merdé, je vais restaurer une sauvegarde, ça ira plus vite.

Je restaure... mais je me retrouve avec les données d'il y a plusieurs semaines en arrière ! Je ne comprends pas et vérifie ma sauvegarde... Pourtant j'ai bien pris la sauvegarde d'il y a 1 heure et d'ailleurs le dossier de sauvegarde a été créé à la bonne date.
Tant pis, je prends la sauvegarde d'il y a 3 heures (en sauvegarde j'ai 'actuel', '1 heure', '3heures', '1 jour', '3 jours', '1 semaine', '1 mois'). Mais... Pareil ! Exactement les mêmes données !! Je ne comprends pas pourquoi...
Pareil avec celle d'1 jour et 3 jours...

Mon utilitaire de sauvegarde (gsync) n'a pas l'air de buggé... Alors j'imagine que le soucis vient de ma manière de sauvegarder mySql, mais pourquoi ? Les données ne sont-elles donc pas inclus dans ces fichiers ? Un truc que je pige pas...

EDIT : Je complète ma demande car je fais des recherches en même temps. J'ai vu un fichier ibdata1 à la racine de là où se trouve les bases de données. Peut-il contenir des données de mes bases ? En gros, si j'ai restauré mes fichiers se trouvant dans le dossier correspondant à ma base de données, est-ce que c'est censé fonctionner ou bien y'a-t-il d'autres fichiers à restaurer ?

Pourrais-tu faire un diff sur tes fichiers, juste pour savoir s'il sont exactement identique.

Peut-etre que ton script de sauvegarde à un problème à faire passer la sauvegarde de 1 heure à celle de 3 heures.

Par exemple:
Copier 1h -> 3h.
Copier 3h -> 1 jour // Mais ici, ton 3h à été effacé: donc tu es en train de dupliquer le même fichier partout.


-----

Normalement la copie des fichiers peut causer des problèmes, mais ca devrait fonctionner. Au moins assez pour te permettre de récupérer tes données, et de les ré-importer adéquatement.

Utilise-tu un serveur avec réplication ? Tes backup sont-ils pris sur des slaves non-syncronisées ?

As-tu essayé de restaurer tes fichiers sur un autre serveur MySQL, question d'être sur que tu restaure bien quelque chose ... Si ca se trouve peut-être que tu commet une erreur idiote du genre: restaurer tes fichiers dans le mauvais dossier, et MySQL ne les chargent même pas, alors tu crois qu'ils sont anciens, mais il ne sont juste pas pris en compte.



.... bref, comme tu vois, je n'ai pas tellement d'idée, mais peut-être que ca apportera des pistes de réflexions.

La sauvegarde simple du répertoire de la BDD est une méthode qui ne fonctionne que si tu n'utilises que le moteur MyISAM pour tes tables.
Si tu utilises le moteur InnoDB, les données sont ailleurs et il faut utiliser mysqldump ou un autre outil, comme expliqué dans la doc MySQL.

Bonjour,

Merci pour ses réponses (et pour avoir placé le sujet sur le sous-forum adapté).

Il est possible que ce soit la sauvegarde qui a merdé... Je n'ai pas d'erreurs dans le log mais j'utilise un logiciel de sauvegarde développé par mon prestataire d'hébergement pour lequel il y a assez peu de recul...
Justement il y a des différences entre les fichiers et les différentes sauvegardes mais elles sont minimes. Parfois certains fichiers ont la même taille, d'autres fois certains ont une taille différente mais ces différences se jouent à pas grand chose...

Je ne sais pas si j'utilise InnoDB ou MyIsam. Je ne connais pas assez MySQL. Les fichiers MYx ne signifient-ils pas que c'est du MyIsam ? En tout cas ça doit être ça car j'ai bien essayé de restaurer sur un autre serveur et ça fonctionne... Enfin ça fonctionne pareil : j'ai bien les mêmes données d'il y a plusieurs semaines... Ce qui ferait donc pencher la balance sur la sauvegarde qui a foiré... A vrai dire, j'ai fait des recherches hier en même temps que j'ai posé cette question et sans trouver de réponses aussi précises qu'ici, au fil de la journée j'ai plutôt suspecté la sauvegarde et perdu espoir pour récupérer mes données...

Allez, une longue journée de travail m'attend ce dimanche ! Faut tout refaire... :( Et je vais creuser les supers sauvegardes et peut-être changer le service...

Pour mon backup, il fait (enfin il est censé faire du coup...) en fait du versioning. La synchronisation des fichiers se fait toujours sur un autre serveur et à chaque moment défini (toutes les heures), il stop la synchro, met de côté le dossier qui était en cours de synchro, en recréé un nouveau et redémarre la synchro (après avoir éventuellement purgé les vieux dossiers qui ne servent plus). Ce que j'ignore, c'est la phase de création du nouveau dossier : est-ce qu'il créé un nouveau dossier vide pour le resynchroniser avec les données du serveur ou bien une copie du dernier dossier (de la dernière synchro) pour resynchroniser les fichiers modifiés uniquement. J'aurais tendance à dire que si il est bien fait il repart de la dernière synchro... Mais du coup c'est peut-être là que ça bug depuis plusieurs semaines. Le serveur étant un serveur d'hébergement, il ne redémarre pas souvent si un service tourne toujours mais qu'il bug, je ne m'en rends pas compte...

Citation:

---

Envoyé par CinePhil

La sauvegarde simple du répertoire de la BDD est
Si tu utilises le moteur InnoDB, les données sont ailleurs

---

Je sais que c'est hors sujet, mais à quel endroit sont elles ?

Citation:

---

Envoyé par FMaz

Je sais que c'est hors sujet, mais à quel endroit sont elles ?

---

Les données des tables InnoDB sont stockées dans le fichier idbdata1 du répertoire mysql (sous Linux dans /var/lib/mysql).
De plus, les fichiers ib_logfile_N contiennent, comme leur nom l'indique, des logs permettant de reconstituer les opérations faites sur les tables et doivent être également sauvegardées.

Par contre, je n'ai jamais fait d'opération de restauration avec ces fichiers donc je ne sais pas comment ça fonctionne. Voir doc MySQL.

Même avec, les tables InnoDB, il existe quand même uyn répertoire par base de données contenant un fichier .frm par table donnant le format de la table, c'est à dire la composition de ses colonnes.

C'est pour ça que si on n'utilise que des tables InnoDB (ce qui est un bon choix pour bénéficier des contraintes de clés étrangères) et qu'on ne sauvegarde que le répertoire de la BDD, on ne récupère que le format des tables et pas les données.

J'ai lu qu'une sauvegarde des fichiers InnoDB reste possible à condition de bien arrêter le serveur MySQL avant de faire la sauvegarde ou avant de restaurer...

Du coup je ne suis pas en InnoDB mais bien MyIsam.
C'est fou ce que j'ai appris sur MySQL en un week-end ! Mon soucis aura au moins eu ce mérite.

Sinon pour conclure sur ce sujet, j'ai trouvé le responsable de mes malheurs. Il s'agit bien de l'utilitaire de sauvegarde. Il a l'air de planter sans planter...
A un moment donné, pour une raison que j'ignore encore (peut-être simple bug de l'utilitaire), il cesse d'inscrire des informations dans son log. A partir de ce moment là, il semble encore tourner car les dossiers de sauvegarde sont créés régulièrement. Les dossiers semblent bien se créer par copie de la dernière sauvegarde, puis l'utilitaire synchronise. Il semble bien synchroniser les fichiers qui ont changé de date mais pas ceux qui conservent la même date, même si leur taille change. (je parle de date de création du fichier bien évidemment).
Si je relance l'utilitaire, ça fonctionne bien (il modifie les fichiers de même date mais qui n'ont plus le même contenu) mais au bout d'un moment, ça replante...

Bref... Je vais voir avec mon prestataire au sujet de ce bug (c'est lui qui fournit l'utilitaire) et bien le remercier pour les 40 heures de boulot perdu... :(

Et sans doute changer d'utilitaire pour quelque chose de plus fiable...

Merci pour votre aide. J'aurais appris pas mal de choses quand même.