Kerio Connect auf MacOS X – Backup mit Hindernissen

Man sollte meinen, das wäre die einfachste Aufgabe der Welt: Die Daten eines Kerio Connect (früher als Kerio Mail Server bekannt, nach eigenen Angaben bester Mailserver wo gibt 🙂 ) zeitgesteuert und unbeaufsichtigt auf einen externen Storage sichern. Richtig? Leider nicht ganz. Das Problem? Der Mailserver und damit auch das Backup läuft im Systemkontext, also quasi als Root. Aber eins nach dem anderen:

1. Backup des Kerio in Reinform

Man sollte meinen, es ist alles da: Man kann wählen, an welchem Tag und um welche Uhrzeit ein vollständiges Backup stattfindet, wann ein differenzielles, wo die Backups gespeichert werden, wer per e-Mail benachrichtigt wird usw. Unter „Erweitert“ kann man sogar angeben, wieviele vollständige Backups aufgehoben werden sollen und wie groß die „chunks“ sein sollen, in die die Backup-Datei aufgeteilt wird. Als Resultat legt Kerio im angegebenen Pfad ZIP-Dateien im Format [F|I]YYYYMMDDTHHMMSS.NN.zip an, wo die Datum- und Uhrzeitangabe dem Beginn der Sicherung entsprechen, ein F für „Full“ und ein I für „Incremental“ steht.

2. Enter external storage

Nun habe ich aber natürlich nicht auf fest verbaute Datenträger, sondern auf externen Storage sichern wollen – in diesem Fall eine Thecus 5200, die eine Vielzahl von Protokollen beherrscht, unter anderem auch AFP, SMB und FTP. Also: eine Share eingehängt, den Backup-Pfad bei Kerio geändert, eine Testsicherung laufen lassen – alles war gut. Bis eines Nachts durch eine Stromschwankung die Netzwerkverbindung zwischen dem Kerio-Server und dem Storage abbrach – kurz zwar, aber da es während der Sicherung war, genügte es, damit das Volume ausgehängt wurde.

Man sollte vielleicht meinen – eine Negativmeldung an die eingestellte e-Mail-Adresse? Weit gefehlt. Sowohl das fragliche Backup als auch die folgenden liefen glatt durch. Bis eines Tages der Server schrie, die Systemplatte sei voll. Ich schrieb ja schon, Kerio läuft als Root. Nun, was macht ein Root, wenn er die Datei /Volumes/Thecus/kerio.bak/I*****.ZIP anlegen will, das Volume „Thecus“ aber nicht da ist? Richtig, er legt einfach unter /Volumes wo er ja ein Schreibrecht hat, einen neuen Ordner namens Thecus an und schreibt los. Dieser Ordner liegt dann aber natürlich auf der Systempartition.

Somit scheidet ein direktes Backup auf einen externen Storage leider aus, wenn das Ganze einigermaßen unbeaufsichtigt laufen soll.

3. Backup auf Umwegen

Ich hatte noch Platz auf einem FireWire-Laufwerk (das ist das RAID5-Volume, das man oben auf dem Screenshot sieht). Da sich die Einbindung des NAS-Volumes als „too flaky“ für ein unbeaufsichtigtes nächtliches Backup herausstellte, beschloss ich, ein robusteres Protokoll zwischen Mailserver und NAS zu benutzen, nämlich FTP. Es gibt eine Fülle von Backup-Programmen für den Mac, die FTP als Ziel unterstützen, die Wahl fiel auf Bonkey. Die Einrichtung war Bonkey-typisch unkompliziert, doch gleich bei der Testsicherung zeigten sich Fehlermeldungen wie

. Ein kurzer Blick auf die Zugriffsrechte der vom Kerio Backup angelegten ZIP-Dateien verriet auch sofort die Ursache:

Oha! Das sind ja nicht wirklich viele Rechte! Das hat man also davon, auf ein lokales Volume zu sichern. Nun ja, im Zweifel besser als 777, dennoch muß eine Lösung her. Und da es mir, wie jedem anderen Admin auch, widerstrebt, ein interaktives Backup-Programm (was dazu noch in Java geschrieben ist) ständig als Root laufen zu lassen, müssen die Zugriffsrechte auf den Dateien nach deren Erstellung angepaßt werden. Leider läßt das Kerio Backup die Funktion „Skript nach Sicherung ausführen“ vermissen (Kerio! Hört ihr mich? Diese Ergänzung ist dringendst nötig!!!), so daß man das mit anderen Mitteln regeln muß.

4. Zugriffsrecht, chmod dich!

Da, wie wir gesehen haben, nur der Root überhaupt Zugriff auf die Files hat, muß der entsprechende chmod-Befehl als Root laufen. Da ich einen relativ guten Überblick darüber hatte, wie lange die Backups brauchen, beschloß ich, auf die zusätzliche Komplexität der Üerwachung des Ordners auf neue Dateien hin zu verzichten und den entsprechenden Befehl einfach als zeitgesteuerten Task laufen zu lassen. Letzten Endes ist es ja nur wichtig, daß die Anpassung der Zugriffsrechte zwischen der Erstellung der Datei und dem Versuch, sie über FTP auf das NAS zu kopieren, geschieht – und da hat man buchstäblich den ganzen Tag Zeit.

Jetzt wollen wir mal als Root arbeiten (um den Root-Benutzer zu aktivieren und dessen Kennwort zu setzen, s. hier: http://support.apple.com/kb/HT1528):

Schnell kontrollieren, ob administrative Handlungen ohne interaktive Passwort-Abfrage durchgeführt werden können:

OK, alles in Ordnung, der Skript wird zeitgesteuert laufen können. Verlassen vi mit

Nun zu der eigentlichen Zeitsteuerung. Das ganze läuft auf einem MacOS 10.5.8 Server ab, d.h. die cron-Funktionalität ist zwar in launchd eingebunden, die Tasks, die als Root laufen sollen, verwenden aber nach wie vor cron.  Schauen wir mal, ob bereits cron-Aufgaben für den Root definiert wurden:

Die crontab ist also leer, das erleichtert die Sache. Dann legen wir einfach eine neue Datei und lesen sie ein:

In die nun geöffnete leere Datei fügen wir dann

(was soviel bedeutet wie: setze jeden Tag um 12:00 die Zugriffsrechte für alle Dateien in dem Backup-Ordner auf 755) und bestätigen mit

wonach es nur noch übrig bleibt zu kontrollieren, ob cron bereits läuft:

und falls nicht, einmal den daemon mit

zu starten. Beim nächsten Systemstart prüft launchd, ob eine crontab vorhanden ist, und ruft dann den cron-daemon automatisch auf.

Das war’s!

1 Kommentar

Antworten

Deine E-Mail-Adresse wird nicht veröffentlicht.


*


Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.