DUPLICATION D'UNE BASE DE DONNÉES POUR SAUVEGARDE

Commentaire de webdeb le 19/12/2008 00:51:30

Ca ne sert strictement à rien comme code. Tu t'exposes à de gros problèmes de pertes de cohérence des données au moment de la sauvegarde en procédant de cette manière. De plus ton code est complètement mal écrit pour de multiples raisons :

1/ Le bon tag PHP d'ouverture de script est <?php et non <? qui peut-être désactivés sur les serveurs dignes de ce nom,
2/ Quel est l'intérêt de faire des variables pour stocker les identifiants de connexion plutôt que de les écrire directement en dur dans le mysql_connect() ?
3/ Que se passe-t-il si la connexion au serveur SQL ne se fait pas ? Pourquoi le script continue-t-il ?
4/ Pourquoi mettre des apostrophes inutiles autour des variables ?
5/ Et si je n'utilise pas l'UTF-8 comme encodage de chaque table ?
6/ Que se passe-t-il si un mysql_query() échoue ? Pourquoi continuer le script ?
7/ Malheureusement, il n'y a aucune transaction (donc pas de moteur de stockage InnoDB) pour assurer que toutes les données ont bien été copiées et que l'intégrité référentielle entre les tables a été respectée.
8/ Pas de mysql_close() ?
9/ ...

Bref tout ça pour dire que tu peux jeter ton code à la poubelle ! On ne fait jamais de backups d'une base de données comme ça sur un site en production, c'est complètement fou. Un backup doit être réalisé par une tâche automatique qui lance périodiquement un script shell qui appelle par exemple l'utilitaire mysqldump. C'est beaucoup beaucoup beaucoup beaucoup plus performant et beaucoup beaucoup beaucoup moins dangereux pour la base de données car mysqldump est un utilitaire qui maîtrise les sauvegardes et qui est conçu pour ça.

Pour rappel :

mysqldump -u root -p MaDatabase > MaDatabase.sql

permet en 1 ligne de commande de dumper proprement MaDatabase dans le fichier MaDatabase.sql.

Commentaire de fmarie le 19/12/2008 01:14:52

Je passerai sur les différents points où tu as raison et que je modifierai plus tard en effet, à savoir les points 1,3,4,6,8.
Point 2, je fais un include logiquement pour n'avoir qu'un fichier de connexion et j'ai simplement fait la copie des variables.
Point 5, à vrai dire, je n'ai pas trouver la solution et je n'ai pas non plus cherché beaucoup en effet. Si tu as la réponse, je suis preneur.
Point 7, qu'appelle-tu transaction ? Un lien d'explication me suffira.

En ce qui concerne le dump, je suis évidement d'accord avec toi mais je ne sais pas comment faire pour que sur une page d'administration d'un site internet, les utilisateurs puissent lancer cet utilitaire à tout moment.
Pour moi, l'important est que les utilisateurs puissent faire une sauvegarde avant de modifier de façon significative une base de données.

Merci de tes éventuelles réponses.

Commentaire de fmarie le 19/12/2008 12:14:52

J'ai oublié de mettre la ligne :
begin();


entre :

$SQL="CREATE TABLE $dbdest.$enr[0] SELECT * FROM $db.$enr[0];";

et

$result=@mysql_query($SQL);

Commentaire de fmarie le 19/12/2008 14:27:29

Ok ! Merci de l'information !
Mes bases sont en effet en MyISAM.

Et si tu as encore 5 minutes à me consacrer pour les questions de mon message de 01:14:52 ;)

Commentaire de neigedhiver le 20/12/2008 22:15:13

Salut,

Concernant l'exécution d'un script shell par l'utilisateur, il est vivement recommandé, à moins d'apporter un soin extrême à la configuration de PHP et du serveur (ce qui n'est pas une mince affaire), de ne pas le faire directement par PHP.

Le mieux est, comme le disait WebDeb, d'utiliser une tâche auto avec cron, exécutée sous root.
Il n'est pas nécessaire que la tâche soit exécutée 1 fois par jour... On peut imaginer que le script de backup cherche un fichier précis à un endroit précis (lequel aura été créé par PHP dans un répertoire de l'utilisateur qui ne se trouve pas dans l'arborescence de publication http). Si le fichier est trouvé (il peut d'ailleurs contenir le(s) nom(s) de la / des base(s) à sauvegarder), alors le dump est effectué. Sinon, non.
Cette tâche peut très bien être exécutée toutes les 5/10 minutes par exemple.
Dans le même ordre d'idée, pour la restauration, on peut imaginer l'inverse... L'utilisateur doit placer son fichier .sql à un endroit précis. La tâche de restauration cherche les fichiers SQL dans ce répertoire précis et les exécute. Idem, elle peut tourner toutes les 5/10 minutes.

C'est à mon avis une des solutions les plus simples à mettre en place sans sacrifier la sécurité (plutôt que d'avoir un script PHP qui exécute un script shell contenant le mot de passe MySQL de root) et, puisque tu t'adresses  à des personnes qui ont un serveur dédié, bien plus adaptées qu'un script PHP.

Pour revenir sur le point 2 évoqué par WebDeb : pourquoi utiliser MySQL connect sur chaque page avec des variables définies dans un autre fichier ? Pourquoi ne pas simplement inclure un fichier qui contient la fonction mysql_connect() avec les arguments ? Bon c'est du détail, hein...

Sinon, pourquoi ne pas utiliser l'extension mysqli plutôt que mysql ?

Commentaire de pouyelayese le 11/01/2009 17:28:59

slt je m'adresse à fmarie s'il peut mettre des commentaires dans son code car pour les débutants comme nous c'est un peu difficile de comprendre.