lokale MySQL Sicherung mit Logrotate

Logrotate kann falsch genutzt werden um eine lokale MySQL Sicherung zu erstellen.

“logrotate” ist ein sehr weit verbreitetes Linux Werkzeug welches mit den meisten Linux Distribuntionen vorkonfiguriert ausgeliefert wird.

Im Verzeichnis /var/log sind die Dateien nach dem folgenden Schema angeordnet.:

Das ist wofür “logrotate” geschrieben wurde. Die Logdatei wird von /var/log/auth.log umbenannt zu /var/log/auth.log.0 und am folgenden Tag komprimiert und umbenannt in /var/log/auth.log.1.gz. Wenn mehr als vier sicherungen der Logdatei existieren werden überzählige Sicherungen gelöscht. Genau was eine lokale Datenbank-Sicherung erreichen soll.

Normalerweise mache ich meine MySQL Sicherungen mit einem Cronjob, der mir dann relativ schnell die Festplatte mit Datenbanksicherungen füllt. Da es die Aufgabe von “logrotate” ist Logdateien umzubenennen, zu komprimieren und alte Logdateien zu löschen eignet es sich auch sehr gut für eine kleine lokale Datensicherung.

Mit ein wenig chreativem falsch gebrauch des Werkzeugs “logrotate” kann es verwendet werden um MySQL Sicherungen zu rotieren.

Hier die Kurzanleitung wie ich dies erreicht habe:

Zuerst erstelle ich das Verzeichnis /var/backups/mysql/ in dem die Datensicherung der MySQL Datenbank angelegt werden soll.

Um den “logrotate” Deamon dazu zu bringen die Datenbank zu sicher erstelle ich die Datei /etc/logrotate.d/0-mysql-backup mit dem folgenden Inhalt:

Diese “logrotate” Konfigurationsdatei läuft täglich (daily), behält 10 Backups (rotate 10), läuft auch wenn die Datei nicht vorhanden ist (missingok), komprimiert die Daten mit dem in logrotate eingestellten Kompressionsalgorithmus (compress), erstellt im Anschluss keine neue Datei (nocreate) und erstellt vor dem lauf von „logrotate“ den MySQL Dump.

Da Logrotate ohne vorhandene Datei nicht einmal den Befehl im Bereich prerotate ausführt muss die sicherungsdatei database.sql zuerst angelegt werden.

Ob wir alles richtig gemacht haben können wir auf der Shell testen.

Bei dieser Sicherung handelt es sich nicht um ein vollwertiges Backup da das Sicherungsverzeichnis /var/backups/mysql/ sich auf dem gleichen Computer (oder sogar auf der gleichen Festplatte) befindet auf der auch der MySQL Server selbst läuft. Hier kann natürlich auch vor der Sicherung das Verzeichnis gemounted werden.

Verzeichnisstruktur mit nur „bestimmten“ Dateien kopieren

Die Verzeichnisse in denen ich meine Bildarchive verwalte wurden mit der Zeit von verschiedenen Archiv Programmen mit unglaublichen mengen an .sqlite und .xml und .txt und ähnlichem aufgefüllt die ich für meine Backups nicht benötige. Die Metadaten werden von den meisten Bildverwaltungen ohnehin zusätzlich in die exif Daten der Bilder geschrieben.

Da ich zum zusammenkopieren meiner „Backup-Zeile“ eine ganze Weile herumprobieren musste habe ich diesen Blogbeitrag verfasst.?

Einzeiler zum kopieren einer Verzeichnisstruktur und aller „.jpg“ Dateien:

rsync -aP --partial --size-only --include "*/" --include "*.jpg" --exclude "*" /media/sdkarte/ /media/Bildarchive2013

rsync – Programm zur Synchronisation von Daten

-a fasst die folgenden Optionen zusammen:

  • -r lässt rsync rekursiv arbeiten
  • -l kopiert symbolische Links
  • -p behält Rechte bei
  • -t behält Zeiten bei,
  • -g behält Gruppenrechte bei
  • -D behält Gerätedateien bei (nur wenn root rsync startet)

-P macht rsync gesprächig und gibt den fortschritt der Syncroisierung aus
–partial unfolständige Dateien beibehalten und fortsetzen
–size-only nur die Dateigröße prüfen
–include mit in der Sicherung durchführen
–exclude nicht mit in der Sicherung zufügen ausser ausrücklich includiert

Die Kamera nimmt die Bilder und auch zusätzliche GPS Informationen in Ordner auf, die dem Jahr-Monat-Tag entspricht. Die GPS und Richtungs Informationen die die Kamera in zusätzlichen Dateien aufnimmt brauche ich nicht im Archive und lasse sie auf diese weise einfach aus.