Der Admin des TSM-Servers der Uni bat mich, unsere Maschinen am Scheduling durch den Server teilnehmen zu lassen und in Zukunft nicht mehr per Cronjob die Daten ‚rüberzuschieben. Die Idee gefällt mir, insbesondere nachdem ich die Lastverteilung des TSM-Servers gesehen habe. Was ist eigentlich so attraktiv an 4:00 Uhr morgens als Zeit für’s Backup? Naja, jedenfalls war er ein wenig entsetzt, als er gelesen hat, dass ZFS und TSM nicht so richtig kooperieren. Damit war die Idee für einige Maschinen erst mal vom Tisch: Alle Maschinen, die irgendwo ein ZFS haben, müssen weiter per Cronjob ihr Backup schieben. Ich war aber so frei, und haben Termine ausserhalb der Spitzenzeiten gewählt.
Die ZFS-freien Maschinen stellen wir jetzt langsam, also eine nach der anderen, auf ge-schedule-tes Backup um. Eigentlich sind dafür nur zwei-drei zusätzliche Zeilen in der dsm.sys notwendig. Anschließend startet man einen kleinen Daemon names dsmcad, der sich dann die Backupzeiten mit dem Server vereinbart und entsprechend den dsmc startet. Ein guter Grund, sich endlich mal mit den Service-Definitionsfiles für das SVC zu beschäftigen, damit dieser Daemon automatisch bei Systemstart gestartet wird.
Schick ist auch, dass man vor und nach dem eigentlichen Ausführen des ge-schedule-ten Backups mit den Paramentern preschedulecmd und postschedulecmd irgendwelche Skripte ausführen lassen kann, beispielsweise um das Viele-MB-Logfile sich zurechzustutzen und als Mail kommen zu lassen.
Zu meiner großen Freude waren diese Optionen auch mal in der Doku sauber erklärt. Daher diesmal ein Lob an IBM, die Doku scheint zumindest an dieser Stelle was zu taugen (unser TSM-Server-Admin fluchte aber über einige andere Kapitel).
Update 31. Oktober 2007:
Da TSM jetzt ZFS anscheinend richtig unterstützt, werden wir nach um nach auch die übrigen Maschinen auf ein Scheduled Backup umstellen. Der Test auf den übrigen Maschinen war sehr erfolgreich, durch das Scheduling haben sich die Backup-Dauern stark verkürzt.