OVH Community, votre nouvel espace communautaire.

Reinstal ou restore?


TBC_Ly0n
14/07/2015, 08h53
Citation Envoyé par bbr18
et pour l'avenir, quand tu devras faire une mise à jour, fais des sauvegardes avant (en plus des sauvegardes régulières habituelles), ça t'évitera de tout perdre, là tu as eu de la chance mais ce ne sera pas le cas à chaque fois.
Surtout ça, je dirais
Et prévoir éventuellement quelqu'un si on a peur de faire des bêtises.

bbr18
10/07/2015, 18h52
et pour l'avenir, quand tu devras faire une mise à jour, fais des sauvegardes avant (en plus des sauvegardes régulières habituelles), ça t'évitera de tout perdre, là tu as eu de la chance mais ce ne sera pas le cas à chaque fois.

pl.lamballais
10/07/2015, 18h44
Merci, c'était bien ça. Modification parasite du cnf à l'update.

Nowwhat
10/07/2015, 18h10
Dans
/etc/lib/mysql
t'as quelques des fichiers ... genre:
Code:
-rw-r--r--  1 mysql mysql    0 Apr 19 20:15 debian-5.5.flag
-rw-rw----  1 mysql mysql 5.0M Jul 10 18:05 ib_logfile0
-rw-rw----  1 mysql mysql 5.0M Jul 10 18:05 ib_logfile1
-rw-rw----  1 mysql mysql  58M Jul 10 18:05 ibdata1
-rw-------  1 mysql mysql    6 Apr 19 20:15 mysql_upgrade_info
et des répertoires:
Chaque repertoire est le nom d'une base (dans MySQL). En suite, dans un répertoire t'as des fichiers, leur nom est lié à la table (dans cette base) concernant.

Cet endroit ne tombe pas du ciel.
C'est défini dans /etc/mysql/my.cnf
Regarde:
grep 'datadir' /etc/mysql/my.cnf
datadir = /var/lib/mysql
C'est comme ça je (et MySQL ) trouve l'endroit ' /var/lib/mysql'

Donc, si toutes tes bases sont ici
/home/test/bidon/parla
il suffit de edit
/etc/mysql/my.cnf
edit modifier le chemin après le paramètre 'datadir='

=>> !! Fait ça uniquement quand MySQL est ARRETE !! <<==
Après le edit, démarre MySQL et il va utiliser les données (bases, etc) d'ici /home/test/bidon/parla

pl.lamballais
10/07/2015, 17h43
Je remet un message suite à une découverte assez étonnante.... En suivant les explications de Nowwhat, je me balade sur mon disque et je trouve évidement dans var/lib/mysql, des fichiers. Je rappelle qu'après update de MariaDB (mais aussi, j'ai l'impression, de MySQL), je n'ai soit disant plus de table.
Or, aprés avoir compacté les tables de var/lib/mysql, je me balade sur le disque pour trouver un répertoire de dépot et.... je tombe sur un autre dossier mysql... Et dedans.... y'a toutes mes tables!
Je pense donc qu'il y a eu un conflit entre l'update de MariaDB et celle de MySQL, le chemin d'accès aux tables ayant été modifié par l'une ou l'autre des mises à jours. Il faut maintenant reparamètrer tout ça pour indiquer où se trouvent les bonnes tables.

Hop, un nouveau message avec la réponse...
La mise à jour de MySQL + MariaDB semble provoquer des conflits entre les deux. Le fichier my.cnf est modifié ou en tout cas, le système semble reprendre le fichier par défaut qui, dans mon cas, ne pointait pas sur mon dossier de table. J'ai donc cherché ce fichier et je l'ai modifié (/etc/mysql/my.cnf). Sauf qu'un autre problème est survenu: la prise en compte de ce fichier modifié demande l'arrêt de MySQL. Or un "stop" ne fonctionne pas. Là encore à prioris à cause d'un mélange entre MariaDb et MySQL. Après pas mal de recherches et pas mal d'essais, la seule manière brutale que j'ai trouvé pour arrêter Mysql c'estun "killall mysqld". Ensuite redémarrage, prise en compte du my.cnf modifié: tout est remis en place.
Merci à Nowwath pour sa réponse, qui m'a permis de diriger les recherches!

pl.lamballais
10/07/2015, 17h31
Merci pour ta réponse. Effectivement quand je vais voir ce qu'il y a dans var/lib/mysql il y a pas mal de fichier donc un qui semble correspondre aux données. Je pense que je vais copier ces fichiers et suivre cette explication sur comment reconstruire partir des fichiers IDB.
http://dba.stackexchange.com/questio...and-a-ibd-file

Je remet un message ici pour indiquer comment j'ai fait, ça pourras peut-être servir à d'autres.

Nowwhat
10/07/2015, 16h42
Soit, c'est pire: t'as un raid0 et là, c'est le cata total. Je t'invite à consulter un bon wiki pour connaitre les différences entre toutes ces modes raid.

Le méthode RAID n'est pas une sauvegarde (!!!!)
C'est un système pour agrandir la chance qu'en ca d'un pépin (crash d'un disque) le serveur continue de tourner.
Exception : le Raid0 : quand un des deux disques meurt, les données sur LES DEUX sont cuit.

Pas de sauvegarde ==> plus des données.
(sauf rescue au niveau cluster .... je te dit pas le boulot)

Réinstaller => effacement table de partitions. Il y a des moyens de récupérer quelque chose mais cas nécessite un "as-de-d'admintration" d'un serveur (et ces gens la ont des sauvegardes, cars il déteste ce boulot à la con)

Par contre: un mise à jour de MariaDB .. il s'agit d'un simple mise à jour des paquets Debian et t'as perdu toutes tes bases ?
Ceci est très sérieux.
Même quand je dé-installe MariaDB de mon serveur Debian Jessie, les données - les bases (typiquement dans /var/lib/mysql/) sont toujours là.

Je sais que j'ai sur le second disque les mêmes données que sur le premier.
Donc tu sais que les données sur ces deux disques sont identiques.
Ok, parfait - et tant mieux, c'est le but d'un RAID-1

Ma question c'est comment je fais pour remettre les données du second sur le premier!
Mdr ...... T'es sérieux ? C'est justement le boulot du système raid ça.

Mais si tu insiste: tu va déguster : http://denisrosenkranz.com/tuto-mdad...raid-logiciel/ ce tuto est OBLIGATOIRE dès que tu travaille avec un RAID. Sans lui ce n'est même pas la peine que tu utilise un 'raid'..
Des divers exercices sont à effectuer dès la prise en maison de ton serveur - pour que tu soit préparé en cas de 'crash disque'.

Mais je n'ai toujours pas compris pourquoi tu souhaite copier des données de disque /sda vers /sdb (ou l'autre sens) si ces deux disques ont déjà les même données ....

pl.lamballais
10/07/2015, 16h32
ça je m'en doute. Je sais que j'ai sur le second disque les mêmes données que sur le premier. Ma question c'est comment je fais pour remettre les données du second sur le premier!

sich
10/07/2015, 15h51
ben si t'as un RAID1 les données du 2° disques sont déjà synchronisées avec le premier.... Sinon ça ne serait pas du raid....

pl.lamballais
10/07/2015, 15h42
Bonjour,

J'ai un dédié Soyoustart avec 2 disques de 2To (donc un RAID) sous Debian Whezzy. Suite à une mise à jour de MariaDB, je constate que mes tables de BDD ont toutes disparues. Comme les copies sont pas à jours (grand classique), je me demande si je ne peux pas récupérer simplement ce qu'il y a sur le second disque (donc le "RAID") car à la limite, tout écraser ne gène pas.
Sur le manager il y a un lien "réinstall"... Est-ce que cela réinstalle l'OS et que l'OS ou bien est-ce que ça prend tout le second disque pour le copier "brutalement" sur le premier?
Et si ça ne prend que l'OS, comme reprendre les data du second disque pour les mettre sur le premier? J'ai jete un oeil sur les docs OVH, mais dans le genre pas clair...
Il y aussi des infos sur NETBOOT mais celui-ci me propose deux "rescue". laquelle choisir et la question reste la même: est-ce une copie compléte ou partielle des données?

D'avance merci pour les pistes
Amitiés
PL