commandes mysqldump & gzip pour créer correctement un fichier compressé d'une base de données MySQL en utilisant crontab
J'ai de la difficulté à obtenir une crontab au travail. Je souhaite automatiser une sauvegarde de base de données MySQL.
La mise en place:
- Debian GNU/Linux 7.3 (Wheezy)
- Version du serveur MySQL: 5.5.33-0 + wheezy1 (Debian)
- les répertoires utilisateur, sauvegarde et sauvegarde2 ont l'autorisation 755
- Les noms d'utilisateur pour la base de données MySQL et le compte Debian sont identiques.
Depuis le shell cette commande fonctionne
mysqldump -u user -p[user_password] [database_name] | gzip > dumpfilename.sql.gz
Quand je place ceci dans une crontab en utilisant crontab -e
* * /usr/bin/mysqldump -u user -pupasswd mydatabase | gzip> /home/user/backup/mydatabase-backup-`date +\%m\%d_\%Y`.sql.gz >/dev/null 2>&1
Un fichier est créé chaque minute dans le répertoire/home/user/backup, mais contient 0 octet.
Cependant, lorsque je redirige cette sortie vers un second répertoire, backup2, je remarque que le fichier mysqldumpfile dûment compressé est créé. Je suis incapable de comprendre quelle est l'erreur que je fais qui résulte en un fichier de 0 octet dans le premier répertoire et la sortie attendue dans le second répertoire.
* * /usr/bin/mysqldump -u user -pupasswd my-database | gzip> /home/user/backup/mydatabase-backup-`date +\%m\%d_\%Y`.sql.gz >/home/user/backup2/mydatabase-backup-`date +\%m\%d_\%Y`.sql.gz 2>&1
J'apprécierais grandement une explication.
Merci
La commande mysqldump est d'abord exécutée et le résultat généré est redirigé à l'aide du tube. Le canal envoie la sortie standard dans la commande gzip en tant qu'entrée standard. Le nom de fichier.gz est suivi de l'opérateur de redirection de sortie (>) qui continuera à rediriger les données jusqu'au dernier nom de fichier, c'est-à-dire où les données seront enregistrées.
Par exemple, cette commande va vider la base de données et l'exécuter à travers gzip et les données vont finalement atterrir dans trois.gz
mysqldump -u user -pupasswd my-database | gzip > one.gz > two.gz > three.gz
$> ls -l
-rw-r--r-- 1 uname grp 0 Mar 9 00:37 one.gz
-rw-r--r-- 1 uname grp 1246 Mar 9 00:37 three.gz
-rw-r--r-- 1 uname grp 0 Mar 9 00:37 two.gz
Ma réponse initiale est un exemple de redirection du cliché de la base de données vers de nombreux fichiers compressés (sans double compression). (Depuis que j'ai numérisé la question et sérieusement manqué - désolé pour ça)
Voici un exemple de recompression de fichiers:
mysqldump -u user -pupasswd my-database | gzip -c > one.gz; gzip -c one.gz > two.gz; gzip -c two.gz > three.gz
$> ls -l
-rw-r--r-- 1 uname grp 1246 Mar 9 00:44 one.gz
-rw-r--r-- 1 uname grp 1306 Mar 9 00:44 three.gz
-rw-r--r-- 1 uname grp 1276 Mar 9 00:44 two.gz
C’est une bonne ressource pour expliquer la redirection d’E/S: http://www.codecoffee.com/tipsforlinux/articles2/042.html
Vous pouvez utiliser la commande tee pour rediriger la sortie:
/usr/bin/mysqldump -u user -pupasswd my-database | \
tee >(gzip -9 -c > /home/user/backup/mydatabase-backup-`date +\%m\%d_\%Y`.sql.gz) | \
gzip> /home/user/backup2/mydatabase-backup-`date +\%m\%d_\%Y`.sql.gz 2>&1
voir la documentation ici
si vous devez ajouter une date-heure à votre nom de fichier de sauvegarde (Centos7), utilisez les éléments suivants:
/usr/bin/mysqldump -u USER -pPASSWD DBNAME | gzip > ~/backups/db.$(date +%F.%H%M%S).sql.gz
cela créera le fichier: db.2017-11-17.231537.sql.gz
Personnellement, j’ai créé un fichier file.sh (à droite 755) dans le répertoire racine, fichier qui fait ce travail, sur l’ordre de la crontab.
Code Crontab:
10 2 * * * root/root/backupautomatique.sh
Code File.sh:
rm -f /home/mordb-148-251-89-66.sql.gz # (pour effacer l'ancien)
mysqldump mor | gzip> /home/mordb-148-251-89-66.sql.gz (ce que vous avez fait)
scp -P2222 /home/mordb-148-251-89-66.sql.gz root @ otherip: /home/mordbexternes/mordb-148-251-89-66.sql.gz
(envoyer une copie quelque part ailleurs si le serveur d'envoi se bloque, car trop vieux, comme moi ;-))
www.tikvamal.org