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 un crontab pour travailler. Je veux automatiser une sauvegarde de base de données MySQL.
Le programme d'installation:
- Debian GNU / Linux 7.3 (wheezy)
- version MySQL Server: 5.5.33-0+wheezy1 (Debian)
- les répertoires utilisateur, sauvegarde et backup2 ont 755 permission
- les noms d'utilisateur pour MySQL db et Debian sont les mêmes
à Partir de la coquille de cette commande fonctionne
mysqldump -u user -p[user_password] [database_name] | gzip > dumpfilename.sql.gz
quand je le place 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 /home/utilisateur/répertoire de sauvegarde, mais a 0 octets.
cependant quand je redirige cette sortie vers un second répertoire, backup2, je note que le bon mysqldumpfile dûment compressé y est créé. Je suis incapable de comprendre ce qu'est l'erreur que je fais il en résulte un fichier de 0 octets dans le premier répertoire et la sortie attendue dans le deuxième 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 beaucoup une explication.
Merci
3 réponses
D'abord la commande mysqldump est exécutée et la sortie générée est redirigée en utilisant le tuyau. Le tube envoie la sortie standard dans la commande gzip comme entrée standard. Suivant le nom de fichier.gz, est l'opérateur de redirection de sortie (>) qui va continuer à rediriger les données jusqu'au dernier nom de fichier, qui est l'endroit où les données seront sauvegardées.
par exemple, cette commande va vider la base de données et l'exécuter via 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 originale est un exemple de redirection du dump de la base de données vers de nombreux fichiers compressés (sans double compression). (Depuis que j'ai scanné la question et sérieusement manqué désolé)
c'est 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 expliquant I/O redirection: 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 documentation ici
si vous avez besoin d'ajouter une date-heure à votre nom de fichier de sauvegarde (Centos7) utilisez le suivant:
/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