mysqldump & gzip commandes de créer correctement un fichier compressé d'une base de données MySQL à l'aide de crontab

Je vais avoir des problèmes avec l'obtention d'un crontab de travail. Je veux automatiser une sauvegarde de base de données MySQL.

De la configuration:

Debian GNU/Linux 7.3 (wheezy)
MySQL Server version: 5.5.33-0+wheezy1(Debian)
répertoires de l'utilisateur, de sauvegarde et de backup2 ont 755 autorisation
Les noms d'utilisateur pour la base MySQL et des comptes de Debian sont les mêmes

De la coquille cette commande fonctionne

mysqldump -u user -p[user_password] [database_name] | gzip > dumpfilename.sql.gz

Quand je l'ai placer dans un crontab à l'aide de la commande " 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.

Mais quand je suis rediriger la sortie vers un deuxième répertoire, backup2, je remarque que le bon mysqldumpfile dûment comprimé est créé. Je suis incapable de comprendre ce qu'est l'erreur que je fais que les résultats dans un fichier de 0 octet dans le premier répertoire et la sortie attendue dans le second dossier.

* * /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

Je serais très reconnaissant une explication.

Grâce

désolé pour la faute de frappe dans la première ligne de code, il devrait être gzip au lieu de zip
Je ne serait pas présent à chaque minute
Je courais juste pour tester les commandes.

InformationsquelleAutor user3397547 | 2014-03-09

crontab mysqldump

93

Premier de la commande mysqldump est exécutée et la sortie générée est redirigé à l'aide de la pipe. La pipe est l'envoi de la sortie standard dans le gzip commande comme entrée standard. À la suite de la filename.gz, est la redirection de la sortie de l'opérateur (>) qui va continuer de rediriger les données jusqu'à ce que le dernier nom de fichier, qui est l'endroit où les données seront enregistrées.

Par exemple, cette commande de vidage de la base de données et le lancer à travers gzip et les données seront finalement atterrir dans three.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 est un exemple de rediriger le dump de la base de beaucoup de fichiers compressés (sans double compression). (Depuis que j'ai scanné la question et sérieusement manqué désolé)

Ceci est un exemple de recompresser ensuite 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 en expliquant redirection d'e/S: http://www.codecoffee.com/tipsforlinux/articles2/042.html
- Le problème que je rencontre est que la commande mysqldump et gzip commandes de travail. Dans la première rediriger vers le répertoire "backup" un fichier de 0 octet est créé. La deuxième rediriger vers le répertoire 'backup2 qui ne n'implique pas de re-compression crée le fichier que je veux. Je voulais savoir pourquoi ce qui se passe.
- La sortie n'est pas courante dans gzip, il est redirigé. Il va rediriger jusqu'à ce qu'il arrive à la dernière partie. C'est alors que gzip va le ramasser et de le compresser
- Bash reconnu la redirection et d'une première tentative pour ouvrir le fichier. Le fichier a été ouvert (créé), puis bash détermine comment les données doivent être redirigé. Si il y a une erreur openeing le fichier, la commande échoue et écrit des erreurs sur la sortie stderr. Si la sortie est redirigé à nouveau le stdin de la première commande est envoyé avec le fichier suivant dans la ligne. Si le fichier ne s'ouvre pas et il n'y a pas d'autres redirections, puis les données sont écrites dans le fichier.
- Merci pour expliquer que bash redirige stdin de sortie jusqu'à la fin de la ligne, puis gzip actes de compresser le fichier à la fin. Je pense que j'ai eu > /dev/null 2>,&1 dans mon code initial et la commande mysqldump fichier a été envoyé à /dev/null et jetés. J'ai maintenant le code du travail comme il se doit.
- mineur: ne pas ajouter le mot de passe dans la commande. il va finir dans vous de l'histoire et peuvent être récupérées. (pour cron, il est très bien)
- La restauration serait alors gunzip < three.gz | mysql -u user -pupasswd my-database. Réf. blog.remibergsma.com/2012/10/08/....
InformationsquelleAutor m79lkm
11

Vous pouvez utiliser le tee de commande 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
- Ma question était de savoir comment le premier rediriger les résultats dans un fichier de 0 octet et le second dans un dossier complet
- désolé à ce sujet - j'ai posté une réponse à votre question initiale. Je vais quitter ce ici - j'espère que ce petit extrait de code va être utile à quelqu'un.
- En effet, c'était 🙂
InformationsquelleAutor m79lkm
11

si vous avez besoin d'ajouter une date-heure à votre nom de fichier de sauvegarde (Centos7) utiliser les éléments suivants:
```
/usr/bin/mysqldump -u USER -pPASSWD DBNAME | gzip > ~/backups/db.$(date +%F.%H%M%S).sql.gz
```
cela va créer le fichier: db.2017-11-17.231537.sql.gz

InformationsquelleAutor Unmesh
0

Personnellement, j'ai créer un file.sh (droit 755) dans le répertoire racine, un fichier qui font ce travail, sur l'ordre de la crontab.

Crontab code:

10 2 * * * racine /root/backupautomatique.sh

File.sh code:

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

(pour l'envoi d'une copie ailleurs, si le serveur d'envoi se bloque, parce que trop vieux, comme moi ;-))

InformationsquelleAutor Jean-Marc Lambert

Vous devez vous connecter pour publier un commentaire.