Pour l'informaticien moyen qui lit 01net, ça doit faire super compliqué et calé, alors qu'en fait c'est un peu la base, l'utilisation de mysqldump quoi...
J'ai lu leur truc, c'est moyen, s'il y a voici mon script :
(Si vous voyez des améliorations, je veux bien, je vais sans doute faire un autre qui fera une requête pour lister le nom des bases disponibles au lieu d'aller voir les fichiers car si on a des bases innodb par exemple, il faut bien penser que tout est dans un/plusieurs fichiers au lieu d'un répertoire unique)
#!/bin/sh
#
# Script pour faire le backup des bases
# de données MySQL
# Exécuté par /etc/crontab
#
#
backup_dir=/mnt/backup-mysql
backup_dir_mysql=${backup_dir}/mysql
backup_tmp=${backup_dir}/tmp
backup_tmp_mysql=${backup_tmp}/mysql
for var in `find /var/lib/mysql/ -type d | grep -v "lost+found" | \
sed -e "s/\/var\/lib\/mysql\///"`; do
mysqldump --opt $var > ${backup_tmp_mysql}/mysql-$var-$date-$host.sql
done
# Création de l'archive Tar/gzip data et
# déplacement vers le répertoire des backups
tar czf ${backup_tmp}/mysql-$date-$host.tar.gz -C ${backup_tmp}/ mysql/
mv ${backup_tmp}/mysql-$date-$host.tar.gz ${backup_dir_mysql}/mysql-$host.tar.gz
N'étant pas du tout expert postgresql, j'ai quand même fait un script de backup également :
#!/bin/sh
#
# Script pour faire le backup des bases
# de données PostgreSQL
# Exécuté par /etc/crontab
#
#
backup_dir=/mnt/backup-pgsql
backup_dir_pgsql=${backup_dir}/pgsql
backup_tmp=${backup_dir}/tmp
backup_tmp_pgsql=${backup_tmp}/pgsql
dbnames=`psql -U postgres -q -t -A -d template1 -c "SELECT datname FROM pg_datab
ase WHERE datname != 'template0'"`
for db in ${dbnames}; do
echo -n " $db"
file=${backup_tmp_pgsql}/pgsql-${db}-$date-$host.Fc
pg_dump -U postgres -F c -d $db -f ${file}
done
# Création de l'archive Tar/gzip data et
# déplacement vers le répertoire des backups
tar czf ${backup_tmp}/pgsql-$date-$host.tar.gz -C ${backup_tmp}/ pgsql/
mv ${backup_tmp}/pgsql-$date-$host.tar.gz ${backup_dir_pgsql}/pgsql-$host.tar.gz
Et comment tu garantie l'intégrité des données si la base tourne pendant ce temps là ?
Dans ma boite l'admin arrete la base Oracle pour faire la sauvegarde complete le WE :/ (moi aussi ca m'a éttonné au debut qu'un produit comme oracle 8 nécéssite sont arret pour la sauvegarde)
tout à fait: mysqldump avec l'option: --lock-tables
un mélange d'options utilisé par chez moi:
--force --lock-tables --quick --extended-insert --no-create-db --no-create-info
Bon, on peut ajouter qu'il est possible d'avoir un autre server mysql sur une autre machine et de faire un:
mysqldump -hproduction -options | mysql -hbackup -options
Oui la réplication est une bonne idée mais le système de basculement est encore assez manuel d'après ce que j'ai lu et l'intégration d'un système automatique est prévu mais il faudra attendre un peu j'imagine.
Le serveur esclave incurgite en temps réel le changelog du serveur maitre et sert les requètes en lecture seule (ce qui donne un partage de charge à pas cher).
Dès qu'il reçoit une requète en écriture il arrête son mode de réplication et devient le maître.
(tant pis pour les anglicismes...)
Tu couple ça avec un heartbeat et c'est joué, failover automatique (ajoute un stonith pour plus de sécurité) et tant qu'on y est, chaîne les slaves pour plus de haute disponibilité et répartition des charges.
Tout ça depuis la version 3.23.15.
Mais pour sûr, c'est mieu fait dans les versions 4 et 5.
C'est sûr, ça dépend de l'utilisation. Pour la majeure partie des bases que j'ai utilisées jusqu'ici, un arrêt de 10 secondes à 3 minutes à 4 du mat', reste gérable. Pour d'autres par contre, ça ne l'est pas... Mais autant faire ultra-simple quand on peut.
Comme quoi l'humour peut être une arme dangereuse!
Pour ceux qui aurait la mauvaise idée de suivre ce conseil... dans la grande majorité des applications le problème n'est pas d'arrêter le serveur MySQL, encore moins à 4 heure du mat'.
Le problème n'est pas non plus de copier les fichiers.
Les deux problèmes majeurs sont:
- comment vérifier que la base s'est bien arrêtée?
- effacer la copie précédente avant de s'assurer de la réussite de la nouvelle copie
Je n'est par contre rien contre cette même ligne décomposée dans un script avec à chaque étape un test de "$?" ou à la SysAdmin sauvage style:
(/etc/init.d/mysqld stop && cp -r /var/lib/mysql /mnt/backup/ && /etc/init.d/mysqld start) || /usr/sbin/sendmail ...
# J'adore
Posté par farib . Évalué à 5.
# Bof
Posté par rootix . Évalué à 2.
(Si vous voyez des améliorations, je veux bien, je vais sans doute faire un autre qui fera une requête pour lister le nom des bases disponibles au lieu d'aller voir les fichiers car si on a des bases innodb par exemple, il faut bien penser que tout est dans un/plusieurs fichiers au lieu d'un répertoire unique)
#!/bin/sh
#
# Script pour faire le backup des bases
# de données MySQL
# Exécuté par /etc/crontab
#
#
backup_dir=/mnt/backup-mysql
backup_dir_mysql=${backup_dir}/mysql
backup_tmp=${backup_dir}/tmp
backup_tmp_mysql=${backup_tmp}/mysql
# répertoire de backup monté ?
monte=`mount | grep backup-mysql | grep -v grep`
if [ "${monte}" != "" ]; then
mkdir -p ${backup_dir} && chmod 0700 ${backup_dir}
mkdir -p ${backup_dir_mysql} && chmod 0700 ${backup_dir_mysql}
mkdir -p ${backup_tmp} && chmod 0700 ${backup_tmp}
mkdir -p ${backup_tmp_mysql} && chmod 0700 ${backup_tmp_mysql}
date=`date -I`
host=`hostname -s`
# Détermine la liste des bases et les copie
for var in `find /var/lib/mysql/ -type d | grep -v "lost+found" | \
sed -e "s/\/var\/lib\/mysql\///"`; do
mysqldump --opt $var > ${backup_tmp_mysql}/mysql-$var-$date-$host.sql
done
# Création de l'archive Tar/gzip data et
# déplacement vers le répertoire des backups
tar czf ${backup_tmp}/mysql-$date-$host.tar.gz -C ${backup_tmp}/ mysql/
mv ${backup_tmp}/mysql-$date-$host.tar.gz ${backup_dir_mysql}/mysql-$host.tar.gz
# Efface les fichiers temporaires
rm -f ${backup_tmp}/mysql/*.sql
fi
[^] # Re: Bof Un autre pour postgresql
Posté par rootix . Évalué à 2.
#!/bin/sh
#
# Script pour faire le backup des bases
# de données PostgreSQL
# Exécuté par /etc/crontab
#
#
backup_dir=/mnt/backup-pgsql
backup_dir_pgsql=${backup_dir}/pgsql
backup_tmp=${backup_dir}/tmp
backup_tmp_pgsql=${backup_tmp}/pgsql
# répertoire de backup monté ?
monte=`mount | grep backup-pgsql | grep -v grep`
if [ "${monte}" != "" ]; then
mkdir -p ${backup_dir} && chmod 0700 ${backup_dir}
mkdir -p ${backup_dir_pgsql} && chmod 0700 ${backup_dir_pgsql}
mkdir -p ${backup_tmp} && chmod 0700 ${backup_tmp}
mkdir -p ${backup_tmp_pgsql} && chmod 0700 ${backup_tmp_pgsql}
date=`date -I`
host=`hostname -s`
# Détermine la liste des bases et les copie
dbnames=`psql -U postgres -q -t -A -d template1 -c "SELECT datname FROM pg_datab
ase WHERE datname != 'template0'"`
for db in ${dbnames}; do
echo -n " $db"
file=${backup_tmp_pgsql}/pgsql-${db}-$date-$host.Fc
pg_dump -U postgres -F c -d $db -f ${file}
done
# Création de l'archive Tar/gzip data et
# déplacement vers le répertoire des backups
tar czf ${backup_tmp}/pgsql-$date-$host.tar.gz -C ${backup_tmp}/ pgsql/
mv ${backup_tmp}/pgsql-$date-$host.tar.gz ${backup_dir_pgsql}/pgsql-$host.tar.gz
# Efface les fichiers temporaires
rm -f ${backup_tmp}/pgsql/*.sql
fi
[^] # Re: Bof
Posté par Loïc Jaouen . Évalué à 1.
Utilise l'option "--all-databases" de mysqldump?
# J'ai plus simple
Posté par Colin Leroy (site web personnel) . Évalué à 3.
[^] # Re: J'ai plus simple
Posté par Mathieu Feulvarc'h . Évalué à 1.
[^] # Re: J'ai plus simple
Posté par rootix . Évalué à 1.
[^] # Re: J'ai plus simple
Posté par Hardy Damien . Évalué à 1.
Dans ma boite l'admin arrete la base Oracle pour faire la sauvegarde complete le WE :/ (moi aussi ca m'a éttonné au debut qu'un produit comme oracle 8 nécéssite sont arret pour la sauvegarde)
Dam
[^] # Re: J'ai plus simple
Posté par rootix . Évalué à 2.
[^] # Re: J'ai plus simple
Posté par Loïc Jaouen . Évalué à 2.
un mélange d'options utilisé par chez moi:
--force --lock-tables --quick --extended-insert --no-create-db --no-create-info
Bon, on peut ajouter qu'il est possible d'avoir un autre server mysql sur une autre machine et de faire un:
mysqldump -hproduction -options | mysql -hbackup -options
Et tant qu'à faire pourquoi pas de la réplication:
http://dev.mysql.com/doc/mysql/en/Replication.html(...)
[^] # Re: J'ai plus simple
Posté par rootix . Évalué à 1.
[^] # Re: J'ai plus simple
Posté par Loïc Jaouen . Évalué à 2.
Le serveur esclave incurgite en temps réel le changelog du serveur maitre et sert les requètes en lecture seule (ce qui donne un partage de charge à pas cher).
Dès qu'il reçoit une requète en écriture il arrête son mode de réplication et devient le maître.
(tant pis pour les anglicismes...)
Tu couple ça avec un heartbeat et c'est joué, failover automatique (ajoute un stonith pour plus de sécurité) et tant qu'on y est, chaîne les slaves pour plus de haute disponibilité et répartition des charges.
Tout ça depuis la version 3.23.15.
Mais pour sûr, c'est mieu fait dans les versions 4 et 5.
[^] # Re: J'ai plus simple
Posté par Matthieu . Évalué à 2.
Et on dit faire une sauvegarde base ouverte (en utilisation) ou base fermée (arrêtée).
Voila
[^] # Re: J'ai plus simple
Posté par Colin Leroy (site web personnel) . Évalué à 2.
[^] # Re: J'ai plus simple
Posté par Loïc Jaouen . Évalué à 1.
Pour ceux qui aurait la mauvaise idée de suivre ce conseil... dans la grande majorité des applications le problème n'est pas d'arrêter le serveur MySQL, encore moins à 4 heure du mat'.
Le problème n'est pas non plus de copier les fichiers.
Les deux problèmes majeurs sont:
- comment vérifier que la base s'est bien arrêtée?
- effacer la copie précédente avant de s'assurer de la réussite de la nouvelle copie
Je n'est par contre rien contre cette même ligne décomposée dans un script avec à chaque étape un test de "$?" ou à la SysAdmin sauvage style:
(/etc/init.d/mysqld stop && cp -r /var/lib/mysql /mnt/backup/ && /etc/init.d/mysqld start) || /usr/sbin/sendmail ...
# mysqldump ??
Posté par mac . Évalué à 4.
L'outil recommandé par MySQL est mysqlhotcopy (http://dev.mysql.com/doc/mysql/fr/mysqlhotcopy.html(...)). C'est quand même dommage de pas en parler.
[^] # Re: mysqldump ??
Posté par account . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.