backup d'un systeme

Le Tue, 01 Feb 2005 16:40:37 +0100, Rakotomandimby (R12y) Mihamina a écrit
:

/var/lib/mysql . Est ce que :
- Arret des services
- Copie de /var/lib/mysql
- Reprise des services
- archivage + compression de la copie de /var/lib/mysql

est une "bonne" stragegie ? Il y a mieux c'est sur, mais pour commencer
peut-on commencer par cela?

C'est une façon de faire. On fait rarement comme ca en général parce que
1) faut arrêter le système, donc quand il est utilisé en production c'est
embêtant (et il n'y a pas toujours de créneaux de non utilisation).
Si la base est en plus utilisée pour des services critiques (style
authentification), c'est *très* embêtant
2) on n'archive que les données au format du SGBDR, donc à la
restauration il faut exactement le même SGBDR, compilé de la même façon,
sur la même plate-forme, et la même version bien entendu.
Ce qui peut être gênant, et fait que ces sauvegardes ne pourront
probablement pas être utilisées pour une migration, par exemple.
Par opposition un dump de la base sous forme de requêtes SQL (CREATE
TABLE, INSERT, etc...) permet de rejouer la sortie plus généralement, et
ne prend pas forcément plus de place (c'est du texte, donc on peut
compresser). Dans les bons SGBDRs on peut faire un dump cohérent à chaud.

Parmi les autres solutions, on peut aussi penser à la réplication.

est ce que la copie /var/lib/mysql peut servir de restauration par un
simple desarchivage?

Normalement oui, mais
1) à vérifier dans la documentation MySQL
2) à vérifier en pratique pour de vrai sur un cas concret

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

( Tue, 01 Feb 2005 17:23:50 +0100 ) Patrick Mevzek :

Par opposition un dump de la base sous forme de requêtes SQL (CREATE
TABLE, INSERT, etc...) permet de rejouer la sortie plus généralement, et
ne prend pas forcément plus de place (c'est du texte, donc on peut
compresser). Dans les bons SGBDRs on peut faire un dump cohérent à chaud.

- Est ce que MySQL 4.0.x est un "bon" SGBDR ?
- Est ce que tu aurais un bookmark qui pourrait m'aider dans ce sens ? Oui
il y a la doc MySQL (au fait elle est enorme, si tu as le temps de me
pointer ce que je dois lire... ), mais beaucoup de doc, ca n'a jamais fait
de mal.

--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)

Le Tue, 01 Feb 2005 17:59:51 +0100, Rakotomandimby (R12y) Mihamina a
écrit :

( Tue, 01 Feb 2005 17:23:50 +0100 ) Patrick Mevzek :

Par opposition un dump de la base sous forme de requêtes SQL (CREATE
TABLE, INSERT, etc...) permet de rejouer la sortie plus généralement, et
ne prend pas forcément plus de place (c'est du texte, donc on peut
compresser). Dans les bons SGBDRs on peut faire un dump cohérent à chaud.

- Est ce que MySQL 4.0.x est un "bon" SGBDR ?

Non.

- Est ce que tu aurais un bookmark qui pourrait m'aider dans ce sens ? Oui
il y a la doc MySQL (au fait elle est enorme, si tu as le temps de me
pointer ce que je dois lire... ), mais beaucoup de doc, ca n'a jamais fait
de mal.

http://dev.mysql.com/doc/mysql/fr/backup.html

--
Sébastien

On 2005-02-01, Rakotomandimby (R12y) Mihamina <mihamina@mail.rktmb.org> wrote:

Sur un serveur dédié on est plusieurs a travailler ensemble.
Nous nous occupons du backup des données.
Il y a des backups de toutes les bases et tables SQL a faire (MySQL)
Le repertoire $HOME de SQL est /var/lib/mysql .
Est ce que :
- Arret des services
- Copie de /var/lib/mysql
- Reprise des services
- archivage + compression de la copie de /var/lib/mysql

Vous n'avvez pas précisé le volume des données MySQL (par exemple,
celui dans le repertoire /var/lib/mysql) et l'espace disque
disponible.

Je n'ai jamais professionnellement administré des SGBDR, mais je
suggère plutot de lancer par crontab au début de la nuit un script tel
que:

mysqldump --all-databases --lock-tables
| gzip > $BACKUPDIR/mysqlbackup.sql.gz

D'aprèe mes grossières estimations, même pour une centaine de
gigaoctets de données MySQL, la commande ci-dessus tourne en
(nettement) moins d'une nuit. Ensuite, vous archivez le fichier de
sauvegarde $BACKUPDIR/mysqlbackup.sql.gz

On peut aussi faire un mysqldump par base sauvegardée.

J'imagine que l'arrêt des applications clientes (par exemple par arret
du serveur mysql, deconnection du réseau, redemarrage du serveur mysql
pour la commande de sauvegarde) accelère les choses.

Quelle que soit votre strategie de sauvegarde, il est important de la
tester effectivement, en rechargeant vos bases après une sauvegarde
(essayez le avant les pepins).

Tout cela étant dit, je n'ai jamais administré de SGBD de taille
professionnelle. Pour l'instant, mes dumps ainsi produits sont de
l'ordre du megaoctets, et la commande de dump dure nettement moins
d'une seconde.


Le format d'un mysqldump est bien plus perenne que celui des
fichiers binaires dans /var/lib/mysql (qui ne seront pas forcément
compatibles à la prochaine évolution du logiciel mysql ou de votre
matériel, par exemple passage de x86 vers Amd64 ou PowerPC G5)


Le plus important, c'est de tester regulièrement votre procédure (au
sens humain ou organisationnel, pas seulement informatique) de
sauvegarde!

Prenez d'autres avis (par exemple sur http://forums.mysql.com), je
ne suis pas expert en MySQL.

Bon courage.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France

On 2005-02-01, Rakotomandimby (R12y) Mihamina <mihamina@mail.rktmb.org> wrote:

( Tue, 01 Feb 2005 17:23:50 +0100 ) Patrick Mevzek :

Par opposition un dump de la base sous forme de requêtes SQL (CREATE
TABLE, INSERT, etc...) permet de rejouer la sortie plus généralement, et
ne prend pas forcément plus de place (c'est du texte, donc on peut
compresser). Dans les bons SGBDRs on peut faire un dump cohérent à chaud.

- Est ce que MySQL 4.0.x est un "bon" SGBDR ?

Dans le sens ci-dessus, il me semble bien qu'on peut faire un
mysqldump sur une base "active". Donc dans ce sens là, MySQL est un
"bon" SGBDR ?

(mais je ne suis pas un expert MySQL).




--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France

Basile Starynkevitch [news] <basile-news@starynkevitch.net> wrote:

Je n'ai jamais professionnellement administré des SGBDR, mais je
suggère plutot de lancer par crontab au début de la nuit un script tel
que:

mysqldump --all-databases --lock-tables
| gzip > $BACKUPDIR/mysqlbackup.sql.gz

D'aprèe mes grossières estimations, même pour une centaine de
gigaoctets de données MySQL, la commande ci-dessus tourne en
(nettement) moins d'une nuit. Ensuite, vous archivez le fichier de
sauvegarde $BACKUPDIR/mysqlbackup.sql.gz

Le dump ou sauvegarde logique, c'est en effet bien pratique pour les
raisons exposées par Patrick.

Mais il ne faut pas oublier qu'un dump ne contient que des ordres SQL.
C'est à dire qu'un index sera sauvegardé sous la forme d'un ordre SQL de
création d'index.

Cela signifie que la restauration d'un dump peut prendre beaucoup,
beaucoup de temps. Un temps qui sera beaucoup plus important que la
durée de la sauvegarde. Alors si la sauvegarde totale dure une nuit, la
restauration totale pourra prendre des jours !!

Dés que la volumétrie devient importante, la seule sauvegarde réellement
efficace (qui assure un temps de restauration raisonnable) est la
sauvegarde physique :
- Arrêt de la base
- Sauvegarde de l'ensemble des fichiers constituant la base
- Redémarrage de la base

Attention d'être sûr de ne pas oublier des fichiers. Il est si facile,
dans un environnement un peu bordélique (comme c'est souvent le cas)
d'ajouter des fichiers dans un autre file system qui n'est pas inclus
dans la sauvegarde. De ce point de vue, la solution la plus sécurisée
est de constituer la liste des fichiers de manière dynamique en
interrogeant la base avant de l'arrêter ou alors d'être rigoureux dans
la gestion de l'espace disque.

La taille de la base à partir de laquelle une sauvegarde physique est
indispensable dépend de la puissance du serveur et du nombre de bases
concernées (restaurer un ensemble de fichiers sans se poser de question
est quand même beaucoup plus simple que restaurer une série de dump
...).

Après je ne connais pas suffisament MySQL pour donner des conseils plus
précis mais ces principes me paraissent communs à toutes les bases de
données.

--
Bruno
http://errance.lirano.net : photographies

Le Tue, 01 Feb 2005 19:30:00 +0100, Basile Starynkevitch [news] a écrit :

On 2005-02-01, Rakotomandimby (R12y) Mihamina <mihamina@mail.rktmb.org>
wrote:

( Tue, 01 Feb 2005 17:23:50 +0100 ) Patrick Mevzek :

Par opposition un dump de la base sous forme de requêtes SQL (CREATE
TABLE, INSERT, etc...) permet de rejouer la sortie plus généralement,
et ne prend pas forcément plus de place (c'est du texte, donc on peut
compresser). Dans les bons SGBDRs on peut faire un dump cohérent à
chaud.

- Est ce que MySQL 4.0.x est un "bon" SGBDR ?

Dans le sens ci-dessus, il me semble bien qu'on peut faire un mysqldump
sur une base "active". Donc dans ce sens là, MySQL est un "bon" SGBDR ?

Oui et non.
Comme vous le dites vous-même:
mysqldump --all-databases --lock-tables
^^^^^^^^^^^^^
pendant le dump, les tables sont vérouillées, donc aucune mise à jour
n'est possible.

Si je lis le man de pg_dump par exemple:
pg_dump makes consistent backups even if the database is being used concurrently. pg_dump does not
block other users accessing the database (readers or writers).

Comportement différent donc, probablement lié au fait que l'un est
transactionnel depuis le début, l'autre uniquement récemment et
partiellement.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Le Tue, 01 Feb 2005 16:40:37 +0100, Rakotomandimby (R12y) Mihamina a écrit
:

/var/lib/mysql . Est ce que :
- Arret des services
- Copie de /var/lib/mysql
- Reprise des services
- archivage + compression de la copie de /var/lib/mysql

Au fait, j'ai cru comprendre que dans les nouvelles versions de
posgresql, on peut faire ca, mais sans arrêter le SGBDR. Il faut bien
entendu envoyer un ordre SQL d'abord pour signifier au SGBDR qu'on va
faire une copie des fichiers, et quand on a terminé.
(cf http://www.postgresql.org/docs/8.0/interactive/backup-online.html)

J'imagine que les autres gros SGBDR permettent ce genre de choses aussi.

Les snaspshots au niveau système de fichiers sont aussi une possibilité
(mentionnée dans le doc mysql, mais il n'y a pas que Veritas qui permet
ca il me semble), mais là il faut toujours arrêter le SGBDR.

Voir http://www.postgresql.org/docs/8.0/interactive/backup.html
c'est dédié à postgresql, mais cela parle de 3 solutions différentes de
backup, donc ca donne de bonnes pistes à éventuellement adapter pour
d'autres SGBDR.
Il manque la réplication, parce que ce n'est pas natif dans ce SGBDR.
(elle est mentionnée dans la page de la doc mysql)

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>