mysqldump Problem

Micha74

Micha74

New Member
Hallo Community,

ich hab mal wieder ein Problem bei dem ich befürchte den Wald mal wieder vor lauter Bäumen nicht zu sehen...vielleicht helft Ihr mir mal wieder au die Sprünge.

Ich hab folgendes Script zum Anlegen von mysql-Backups:
Code: 
#!/bin/bash
mysqldump -u root --password=iheqoqit user > user.sql
mysqldump -u root --password=iheqoqit threads > threads.sql
echo "Dumps erstellt!"
sleep 30

DATE=$(date +"%Y%m%d")
tar cvfz $DATE.tar.gz char.sql realmd.sql
echo "Archiv erstellt!"
sleep 60
rm char.sql
rm realmd.sql
mv $DATE.tar.gz /server/backup/

Soweit so gut wenn ich's nun per
Code: 
./backup.sh
ausführe ist die Welt auch in Ordnung. Wenn ichs aber mit cron laufen lassen will sind meine Backups defekt.
Vom Cron Daemon bekomm ich folgende Nachricht:
Code: 
Subject: Cron <root@mydomain> /server/forum/cron/./daily_backup.sh
Content-Type: text/plain; charset=UTF-8
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
Message-Id: <20090202030240.CBBBF22052@mydomain>
Date: Mon,  2 Feb 2009 04:01:10 +0100 (CET)

mysqldump: Got errno 28 on write
mysqldump: Got errno 28 on write
Dumps erstellt!
char.sql

gzip: stdout: No space left on device
Archiv erstellt!

Irgendwas lass ich doch ausser Acht nur was?
Kein freier Speicherplatz kanns doch nicht sein sonst würde es ja von Hand auch fehlschlagen oder seh ich das falsch?

Gruß Micha
 
Hallo Armadillo,

hier die Ausgabe von df -h:
Code: 
Dateisystem            GröÃe Benut  Verf Ben% Eingehängt auf
/dev/sda1             3,0G  2,9G     0 100% /
varrun                 40G   20G   19G  52% /var/run
varlock                40G   20G   19G  52% /var/lock
udev                  4,0G  364K  4,0G   1% /dev
devshm                4,0G     0  4,0G   0% /dev/shm
/dev/mapper/vg-tmp    8,0G  168M  7,4G   3% /tmp
/dev/sda2             168G   84G   79G  52% /home_old
/dev/mapper/vg-home   199G  114G   75G  61% /home
/dev/mapper/vg-var     40G   20G   19G  52% /var
/dev/mapper/vg-mysql   20G  5,4G   14G  29% /var/lib/mysql
/dev/mapper/vg-backup
                       20G  9,2G  9,8G  49% /backup
curlftpfs             7,5T     0  7,5T   0% /ftp-sync/ovh_backup
Hab ich da etwa was übersehen?

Gruß Micha
 
Code: 
/dev/sda1             3,0G  2,9G     [COLOR="Red"]0 100% [/COLOR]/
Beim manuellen Starten ist das Arbeitsverzeichnis wahrscheinlich nicht auf /
 
Oh man....das seh ich echt jetzt erst!

wie peinlich ist das denn :o

Das kann ja nix werden.

Gruß Micha
 
Offtopic:
Ich möchte auch so einen Backupspace:
Code: 
curlftpfs             7,5T     0  7,5T   0% /ftp-sync/ovh_backup
7,5 Terrabyte.... :eek:
 
Hallo Community,

noch immer hab ich identische Meldungen vom cron-job.
Platz hab ich geschaffen:
Code: 
Dateisystem            GröÃe Benut  Verf Ben% Eingehängt auf
/dev/sda1             3,0G  2,0G  902M  69% /
varrun                 40G   20G   19G  53% /var/run
varlock                40G   20G   19G  53% /var/lock
udev                  4,0G  364K  4,0G   1% /dev
devshm                4,0G     0  4,0G   0% /dev/shm
/dev/mapper/vg-tmp    8,0G  168M  7,4G   3% /tmp
/dev/sda2             168G   84G   79G  52% /home_old
/dev/mapper/vg-home   199G   97G   93G  52% /home
/dev/mapper/vg-var     40G   20G   19G  53% /var
/dev/mapper/vg-mysql   20G  4,8G   15G  26% /var/lib/mysql
/dev/mapper/vg-backup
                       20G  9,3G  9,6G  50% /backup
curlftpfs             7,5T     0  7,5T   0% /ftp-sync/ovh_backup

Ich beführchte das irgendwo was schief läuft nur was, das will mir nicht ganz klar werden. Ich bin allerdings nicht der einzige Admin der hier an dem System arbeitet ich bin nur als letzter dazu gekommen.
Deswegen tu ich mich auch schwer mit der Fehlersuche wenn ich's selber eingerichtet hätte wäre es wohl leichter.

Ich hoffe Ihr habt noch mehr nützliche Tipp zum ansetzten!

Wie zb kann ich dafür sorgen das der cron-job in /home ausgeführt so wie es eigentlich sein sollte.

Gruß Micha
 
Micha74 said:
Code: 
#!/bin/bash
mysqldump -u root --password=iheqoqit user > user.sql
mysqldump -u root --password=iheqoqit threads > threads.sql
Warum gibts Du denn nicht den Pfad explizit an?
z.B.
Code: 
mysqldump -u root --password=iheqoqit user > /mybackupdir/user.sql
So wie das jetzt eingestellt ist, versucht der auf currentdir des jeweiligen Users zu arbeiten. Root ist ja eh schon ein besonderer User und cron hat vieleicht wieder ein ganz anderes current dir.
Click to expand...
 
Hallo,

Wie ich das sehe existieren direkt zwei Fehler:
Das hier sind die ersten beiden:
mysqldump: Got errno 28 on write
mysqldump: Got errno 28 on write
Die passieren beim ausführen von:
Code: 
mysqldump -u root --password=iheqoqit user > user.sql
mysqldump -u root --password=iheqoqit threads > threads.sql
Error Code 28 ist, wie wir schon festgestellt haben: No Space on device.

Du solltest die Befehle mal manuell aufrufen und schauen wie Groß so ein Dump wird und dann entscheiden auf welche Partition du ihn packst.

Also erster Schritt: Dump einmal Manuell ausführen.
Zweiter Schritt, Script anpassen mit einem Pfad der genügend Platz bietet:
Code: 
mysqldump -u root --password=iheqoqit user > /pfad/zu/space/user.sql

Gleiches gilt für diesen Aufruf:
Code: 
tar cvfz $DATE.tar.gz char.sql realmd.sql
zu:
Code: 
tar cvfz /pfad/zu/$DATE.tar.gz /pafd/zu/char.sql /pfad/zu/realmd.sql
Und für diese Anweisungen musst du jetzt Transferleistung erbringen ;):
Code: 
rm char.sql
rm realmd.sql
mv $DATE.tar.gz /server/backup/

P.S.: Ich hoffe 'iheqoqit' ist nicht dein wirkliches MySQL Root Passwort ............................

P.P.S.: Mir ist aufgefallen dass dein Script: threads.sql und user.sql erstellt. Du packst in das Archiv aber: char.sql realmd.sql. Ist das so richtig?
 
Last edited by a moderator:
Danke Djrick,

ich hab das mal wie vorgeschlagen abgeändert nun bin ich mal gespannt was mein cron-job morgen früh veranstalltet.

Ich werde mich melden ob Erfolg oder Misserfolg.

Gruß Micha
 
Micha74 said:
nun bin ich mal gespannt was mein cron-job morgen früh veranstalltet.
Click to expand...
Wie gesagt: Ich würde es erstmal alles von Hand aus probieren um zu gucken wie groß der Dump überhaupt wird. Ist die MySQL Datenbank bei dir so groß?
Die kleinste Partition hat noch 900 MB frei...nehmen wir den Fall an, dass er den Dump auch da ablegt dann müsste der MySQL Dump zuminest 900 MB groß werden...das ist für eine Datenbank (nur Text) schon ziemlich viel.
 
You must log in or register to reply here.
Back
Top