10.
2007
Platzsparende Datenbank-Backups via Cronjob
Abgelegt unter Netzszene, Webwork von Oliver Schlöbe
Viele kennen das Problem: Ein tägliches manuelles Backup einer Datenbank zu machen ist aufwändig und zeitraubend. Warum also nicht alles automatisch ablaufen lassen? Ein Backup einer Datenbank per Kommandozeile erstellen ist nicht allzu schwer, das was hier oft vergessen wird ist der Platz, den all die Sicherungen benötigen.
Wird jeden Tag ein DB-Backup angelegt, werden ältere Backups natürlich nicht überschrieben bzw. gelöscht, was es dennoch notwendig machte, manuell die alten Dateien zu löschen. Mit diesem Unix-Backup-Script für Cronjobs (das mit Daniel P. Schenk aus einer Notwendigkeit heraus entstand) schlagen Sie zwei Fliegen mit einer Klappe:
- Ein datumsorganisiertes Datenbank-Backup wird angelegt
- Ältere Backups werden automatisch gelöscht, um Speicherplatz zu sparen
Folgend nun das Script für einen Cronjob:
1 2 3 4 5 6 7 | #!/bin/sh DIR="/ihr/serverpfad/zum/backup/" DATUM=`date '+%d-%m-%Y'` mysqldump -u BENUTZER -p PASSWORT -h localhost --opt DATENBANKNAME > $DIR/backup.sql gzip -9 --best $DIR/backup.sql mv $DIR/backup.sql $DIR/backup-${DATUM}.sql.gz find $DIR/backup.sql -name \*.sql.gz -mtime +5 -exec rm {} \; |
Die zweite Zeile setzt eine Variable DIR mit dem Pfad zur Backup-Datei. Diese sollte erstellt werden, um bei einer Pfadänderung nicht an etlichen Stellen im Script Änderungen vornehmen zu müssen. Auf die Variable wird im weiteren Script per $DIR zugegriffen. Der Pfad muss absolut vom root angegeben werden, bspw. /home/www/web13/html/backup/. Wichtig: Der Pfad benötigt Schreibrechte (CHMOD755)!
Die dritte Zeile bestimmt das Datumsformat der Sicherungsdatei. In diesem Fall sähe es folgendermaßen aus, wenn es am 10.03.2007 gespeichert worden wäre: 10-03-2007 Dieser String, diese Datumsfolge wird dann dem Dateinamen hinzugefügt, um eindeutige Sicherungsdateien zu generieren.
Die vierte Zeile erzeugt nun das eigentliche Backup der Datenbank. Es werden einige Parameter erwartet, damit dieser Befehl erfolgreich ausgeführt werden kann:
- -u Benutzer: Der Benutzernamen für den Zugriff auf die Datenbank, bspw. -u web123
- -p Passwort: Das Passwort zur Datenbank, bspw. -p password123
- -h localhost: Der Datenbankserver, kann eine IP sein oder localhost, was zu 99% der Fall ist
- –opt DATENBANKNAME: Der Name der Datenbank, die gesichert werden soll, bspw. –opt db_span_1
Mit dem > – Zeichen wird der Dump nun in eine Datei geschrieben, in diesem Fall in die backup.sql im angegebenen Ordner. Den Namen können Sie selbstredend selbst bestimmen, sollten allerdings darauf achten, den Namen im weiteren Code ebenfalls zu ändern.
gzip in der fünften Spalte zippt das Backup, um Speicherplatz zu sparen. Der Pfad zur Datei und der Dateiname muss mit denen aus der zweiten und vierten Zeile übereinstimmen!
Die sechste Zeile des Scriptes schließt das Backup ab, indem es der Backupdatei einen eindeutigen Namen zuweist, der aus Dateiname und des in der zweiten Zeile eingestellten Datumsformats besteht. In diesem Fall würde die Sicherungsdatei nun heißen: backup-10-03-2007.sql.gz
Damit wäre das eigentliche Backup-Script abgeschlossen.
Um aber Dateiüberlauf zu verhindern, werden mit der letzten Zeile alle Dateien älter als 5 Tage automatisch gelöscht. Dazu wird der Unix-Befehl find genutzt. Folgende Parameter dienen uns hier:
- -name \*.sql.gz: Alle Dateien mit der Endung .sql.gz werden angesprochen; das stellt sicher, dass ggf. nur Sicherungsdateien gelöscht werden, falls sich noch andere Dateien im selben Ordner befinden.
- -mtime +5: Es werden alle Dateien gelöscht, die älter als 5 Tage sind, nachdem sie erstellt wurden. Ändern Sie diese Zahl je nach Belieben, bspw. auf 2 um alle Dateien älter als 2 Tage zu löschen
- -exec rm {}: Werden Dateien entsprechend der Suchmaske gefunden, wird der Befehl rm ausgeführt (executed), der diese Dateien aus dem Verzeichnis löscht.
Testen Sie nun das Script, um sicherzustellen, dass es auch funktionert. Es gibt nichts Frustrierendes als vom Glauben an ein funktionierendes Sicherungssystem enttäuscht zu werden. 
Fragen bitte in die Kommentare.
Wie sieht das aus wenn ich mehrere Datenbanken mit 1x sicher möchte? Was muss ich denn dann angeben?
Danke
21. März 2007 um 10:52
Euch sollte man die Füße küssen ! Großes Lob das Beste Script das mir je untergekommen ist !
1 + FÜR EUCH !
27. März 2007 um 00:39
Vielen Dank chris.
@Dümmling: Ab der 4. Zeile müsstest Du das Script einfach kopieren und die Dateinamen anpssen, damit sich nichts überschneidet.
Also bspw. “[...]
mysqldump -u BENUTZER2 -p PASSWORT2 -h localhost –opt DATENBANKNAME2 > $DIR/backup2.sql
gzip -9 –best $DIR/backup2.sql
[...]”
usw…
7. April 2007 um 01:45
Ich arbeite auch schon damit. Dies ist mittlerweile unabkömmlich geworden, alleins die Arbeit die man dadurch spart.
Beste Grüße Michi
19. Mai 2007 um 18:38
Lob und Vielen Dank! Einen Cronjob hatte ich zwar bereits, allerdings wurde da immer die letzte Version überschrieben – “-mtime +5:” war genau das wonach ich gesucht habe.
28. Mai 2007 um 17:44
Als was für eine Datei muss ich das denn speichern? Im Cronjob kann ich nur eine aufzurufende URL wählen, aber nicht den COde da einfügen
3. Oktober 2007 um 14:29 ⇓
Bspw. als .sh-Datei, die auszuführende Rechte benötigt.
8. November 2007 um 17:25
Bei mir entstehen immer leere .sql-Dateien, obwohl die db voll ist und die Daten stimmen. Kann es sein, dass das System kein mysqldump kennt? Wenn ja, gibt es Alternativn?
Habe leider keinen direkten Zugriff per SSH, sehe also nicht die Fehlermeldungen.
3. Januar 2008 um 14:13 ⇓
Kommando zurück, hatte mich nur vertippt. Kommentar bitte löschen
3. Januar 2008 um 14:28 ⇓
Hallo Oliver,
das ganze Script hat ein paar Nachteile.
Vorallem steht das Passwort im Klartext in der Prozessliste, waehrend das Script laeuft. Ein einfaches Auflisten der laufenden Prozesse in einer Mehrbenutzerumgebung foerdert somit das Passwort zur eigenen Datenbank zu Tage.
Siehe http://dev.mysql.com/doc/refman/5.0/en/password-security.html
Weiterhin legt es erst das Backup auf Festplatte und komprimiert es anschliessend – dies laesst sich sehr komfortabel in einem Schritt erledigen:
mysqldump -u BENUTZER -p PASSWORT -h localhost –opt DATENBANKNAME | gzip -c -9 > $DIR/backup-`date ‘+%d-%m-%Y’`.sql.gz
Gruesse
Stefan
4. Februar 2008 um 13:10 ⇓
Noch eine Anmerkung
@chris: mit dem Schalter –databases kannst du mehrere Datenbanken angeben
Es wuerde dann in etwa so aussehen:
mysqldump -u BENUTZER -p PASSWORT -h localhost –opt –databases datenbankA datenbankB datenbankC
Alternativ, wenn alle Datenbanken gesichtert werden sollen, benutzt man –all-databases
4. Februar 2008 um 13:13 ⇓
Hallo zusammen,
Das Script ist sehr nützlich und die Tipps von Stefan auch!
Kann man den dieses Script dazu benutzen, auch andere Daten zu sichern, wie etwa den Ordner, in dem sich eine Webseite befindet, z.B html/wordpress/ … oder eine beliebige Datei?
Grüsse
Christo
5. Juli 2008 um 02:46 ⇓
Christo,
das ist natürlich möglich. Nur müsstest du dann dem Befehl mysqldump ‘tip’ oder ‘tar’ nutzen, um die Dateien/Ordner zu packen.
6. Juli 2008 um 14:15
Danke Oli !
Das ist toll – wenn das auch geht. Hast du eigentlich ” “zip” oder “tar” ” gemeint?
Bin ziemlich neu in dem Bereich und daher können meine Fragen etwas dumm erscheinen, aber: Wie würde dann, beispielsweise, die Befehlszeile aussehen?
Gruss
Christo
6. Juli 2008 um 14:30 ⇓
Ja, ich meinte “zip”, sorry.
Hier findest du Infos zur Nutzung von Packing-Befehlen: http://www.linux-fuer-alle.de/doc_show.php?docid=76&catid=8
6. Juli 2008 um 14:34
Super,
Schaue ich mir an. Danke!
6. Juli 2008 um 14:40 ⇓
Find ich gut dein Skript, aber muss der find Befehl nicht eher so lauten?
find $DIR -name backup\*.sql.gz -mtime +5 -exec rm {} \;
Du gibts an wo er suchen soll und dann was.
Ich würde zum Datumsformat noch die Uhrzeit hinzu fügen
DATUM=`date ‘+%d-%m-%Y-%H:%M:%S’`
Damit bei Mehrfachausführung (auch unbeabsichtigte) die alten Dateien nicht überschrieben werden.
Gruß
koelli
10. Juli 2008 um 12:20 ⇓
Ein alternativer Vorschlag für für MySQL-Backups wäre das Script AutoMySQLBackup, das ich für recht brauchbar halte. Macht rotierende Backups über Tage + Wochen + Monate.
16. Juli 2008 um 03:39
Hi,
wenn ich das Script ausführe, erhalte ich folgende Fehlermeldung:
“USER:/# /var/www/sqlbackup.sh
-bash: /var/www/sqlbackup.sh: /bin/sh^M: bad interpreter: No such file or directory
”
Wenn ich die erste Zeile aus dem Script entferne, kommt folgende Meldung beim ausführen:
“USER:/# /var/www/sqlbackup.sh
: No such file or directory 3: /var/www/web0/html/backups/
: No such file or directoryhtml/backups/
mv: cannot stat `/var/www/web0/html/backups/\r/backup.sql’: No such file or directory
: No such file or directoryhtml/backups/”
Die Datei hat die benötigten Rechte und das Zielverzeichnis ist vorhanden und auch beschreibbar. Habt ihr eine Idee woran das liegen könnte ?
6. August 2008 um 16:42 ⇓
Hi Stefan
-bash: /var/www/sqlbackup.sh: /bin/sh^M: bad interpreter: No such file or directory
sieht für mich so aus also würdest du versuchen ein sh skript mit bash auszuführen. probier mal
sh /var/www/sqlbackup.sh
dabei muss natürlich die sh shell installiert sein.
würde mir an deiner stelle überlegen, ob es sinnvoll ist das das backup skript im www ordner liegt. ich würde/hab es im home verzeichnis.
nicht das du durch einen konfigurationsfehler jedem erlaubst das skript auszuführen.
gruß
koelli
16. August 2008 um 23:04 ⇓
Gibt’s eigentlich auch ein Skript mit dem ich eine Vollsicherung von einer Mysql-DB zur einer andern machen? Ich hab insgesamt 3 Stück zur Verfügung.
22. August 2008 um 18:54 ⇓
@Klaus: dafür gibt Replikation
22. August 2008 um 19:16 ⇓
Merci!
Heisst das, wenn ich im umgekehrten Fall vom Slave auf den Master repliziere, das alles wieder im Orginalzustand ist? Ich will damit das Thema Datensicherung vollständig erschlagen…
22. August 2008 um 19:34 ⇓
Hallo,
Wie und wo kann ich das Skipt testen bei einem Webhosting anbieter?
wo muss ich das Skript hinkopieren auf dem Server und wie wird es mit Cronjob aufgerufen, ist ja eine .sh Datei?
29. Januar 2009 um 16:31 ⇓
Hallo Jörg,
in deinem Konfigurationsprogramm wie Plesk oder Confixx musst du das Script in eine Crontab eintragen.
31. Januar 2009 um 17:37
Aber wo muss ich es hinkopieren auf meinem Webspace und wie heist die Dateiendung? Diese Antworten hätte ich noch gerne gewust (siehe oben)
Ist die Dateiendung mit .sh am Ende korrekt?
Jörg
31. Januar 2009 um 19:34 ⇓
Wo du die Datei hinkopierst, ist egal, sofern du in der Crontab den Pfad dorthin korrekt angibst. Und Shell-Scripte wie dieses haben die Endung .sh, ja.
1. Februar 2009 um 13:25