mysqldump & gzip-Befehle zum Erstellen einer komprimierten Datei einer MySQL-Datenbank mithilfe von crontab
Ich habe Probleme damit, eine crontab zur Arbeit zu bekommen. Ich möchte eine MySQL-Datenbanksicherung automatisieren.
Die Einrichtung:
- Debian GNU/Linux 7.3 (Wheezy)
- MySQL Server Version: 5.5.33-0 + wheezy1 (Debian)
- die Verzeichnisse user, backup und backup2 haben die Berechtigung 755
- Die Benutzernamen für MySQL-Datenbank und Debian-Konto sind identisch
Von der Shell aus funktioniert dieser Befehl
mysqldump -u user -p[user_password] [database_name] | gzip > dumpfilename.sql.gz
Wenn ich dies in einem Crontab mit Crontab -e platziere
* * /usr/bin/mysqldump -u user -pupasswd mydatabase | gzip> /home/user/backup/mydatabase-backup-`date +\%m\%d_\%Y`.sql.gz >/dev/null 2>&1
Eine Datei wird jede Minute im Verzeichnis/home/user/backup erstellt, hat jedoch 0 Byte.
Wenn ich diese Ausgabe jedoch in ein zweites Verzeichnis umleiten, backup2, stelle ich fest, dass die ordnungsgemäß komprimierte mysqldumpfile-Datei darin erstellt wird. Ich kann nicht herausfinden, was der Fehler ist, den ich mache, der zu einer 0-Byte-Datei im ersten Verzeichnis und der erwarteten Ausgabe im zweiten Verzeichnis führt.
* * /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
Ich würde mich sehr über eine Erklärung freuen.
Vielen Dank
Zuerst wird der Befehl mysqldump ausgeführt und die erzeugte Ausgabe wird mithilfe der Pipe umgeleitet. Die Pipe sendet die Standardausgabe als Standardeingabe an den Befehl gzip. Nach dem Dateinamen.gz ist der Operator für die Ausgabeumleitung (>), der die Daten bis zum letzten Dateinamen umleitet, an dem die Daten gespeichert werden.
Mit diesem Befehl wird beispielsweise die Datenbank gesichert und über gzip ausgeführt, und die Daten landen schließlich in 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
Meine ursprüngliche Antwort ist ein Beispiel für das Umleiten des Datenbankdumps zu vielen komprimierten Dateien (ohne doppelte Komprimierung). (Da ich die Frage gescannt und ernsthaft verpasst habe - entschuldige das)
Dies ist ein Beispiel für das Rekomprimieren von Dateien:
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
Dies ist eine gute Ressource, die die I/O-Umleitung erklärt: http://www.codecoffee.com/tipsforlinux/articles2/042.html
Sie können den Befehl tee verwenden, um die Ausgabe umzuleiten:
/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
siehe Dokumentation hier
wenn Sie Ihrem Sicherungsdateinamen (Centos7) ein Datum und eine Uhrzeit hinzufügen müssen, verwenden Sie Folgendes:
/usr/bin/mysqldump -u USER -pPASSWD DBNAME | gzip > ~/backups/db.$(date +%F.%H%M%S).sql.gz
dadurch wird die Datei erstellt: db.2017-11-17.231537.sql.gz
Persönlich habe ich im root-Verzeichnis eine file.sh (rechts 755) erstellt, die diese Aufgabe erledigt, im Auftrag der Crontab.
Crontab-Code:
10 2 * * * root /root/backupautomatique.sh
File.sh-Code:
rm -f /home/mordb-148-251-89-66.sql.gz # (Zum Löschen des alten)
mysqldump mor | gzip> /home/mordb-148-251-89-66.sql.gz (was Sie getan haben)
scp -P2222 /home/mordb-148-251-89-66.sql.gz root @ otherip: /home/mordbexternes/mordb-148-251-89-66.sql.gz
(um eine Kopie woanders zu senden, wenn der sendende Server abstürzt, weil zu alt, wie ich ;-))
www.tikvamal.org