Ein kleines HOWTO zum unbeaufsichtigten Backup mit Windows 2000 NTBACKUP und dem Removable Storage Manager.
For an English version of this article look over here.
Kleine Einführung
Das mit Windows 2000 mitgelieferte NTBACKUP und der "Removable Storage Manager" sind beides Entwicklungen von Seagate, die von Microsoft für die Verwendung in den Windows 2000, XP and 2003 Server Betriebssystemen lizensiert wurde. Es ist eine ziemlich "erleichterte" version von Veritas BackupExec. Obwohl es grundsätzlich eine "gute Idee"(tm) und, verglichen mit dem NTBACKUP von Windows NT 4, ein großer Schritt vorwärts ist, ist die Handhabung des RSM kompliziert und die Dokumentation nur mangelhaft, teilweise sogar falsch.
Was ist an RSM denn nun so besonders?
In den guten alten NT4-Zeiten hatte man nur das bekannte NTBACKUP.
Es sah keinen Betrieb von Tape Libraries vor. War mehr als ein Sicherungslaufwerk angeschlossen, könntet ihr mal auf die Idee gekommen sein, im Lauf des Backupvorganges einfach auf das Medium im zweiten Laufwerk zu schreiben, wenn das erste gefüllt war. Wahrscheinlich seid ihr bei der Idee auch stecken geblieben - es hat schlicht nicht funktioniert.
Es kannte nur zwei Betriebsmodi: entweder einen Sicherungssatz an das Band anzuhängen, oder aber das Band mit dem aktuellen Sicherungssatz zu überschreiben. Wenn die Medien dabei von unqualifiziertem Personal gewechselt wurden, lief man bei geplanten Backups stets Gefahr, dass ein inkrementielles Backup fälschlicherweise von einem Vollbackup (auch "Normalbackup") überschrieben wird, wenn das Band zum falschen Zeitpunkt im Laufwerk liegt.
RSM räumt diese Probleme der Vergangenheit aus dem Weg.
Was macht dieses "RSM" denn nun?
Eigentlich ist "RSM" eine API, die von Backup-Anwendungen benutzt werden soll. Es verwaltet Sicherungs(band)medien, indem es eine eindeutige Medienkennung (die Medien-GUID) neben anderer Information (Medienname, Beschreibung, Kommentare, verfügbare Seiten) in einer Datenbank speichert. Damit kann es jedes Medium identifizieren, welches schon einmal im System genutzt wurde.
Außerdem können mit Hilfe des RSM die Medien nun in einer baumartigen Struktur organisiert werden - ähnlich der Organisation von Dateien in Verzeichnissen auf einem Dateisystem. Das RSMische Gegenstück für Verzeichnisse heißt "Medienpool". Ein Medienpool kann entweder Medien eines vordefinierten Typs oder weitere untergeordnete Medienpools enthalten.
Ein anderes Feature ist die Zuordnung eines Mediums zu einer bestimmten Anwendung. Dieses medium wird dann als zur Anwendung "gehörend" gekennzeichnet und kann somit nicht von einer anderen Anwendung versehentlich überschrieben werden. Dies sogar dann, wenn die Anwendungen einander und das Datenformat der jeweils anderen nicht "kennen".
Was heißt das für NTBACKUP?
NTBACKUP benutzt RSMs Fähigkeiten zur Identifikation der Medien und das Pooling. Wenn entsprechend angewiesen, kann es ein spezielles Medium aus einer automatischen Bänderbibliothek ziehen - nur mit der Angabe der entsprechenden Medien-GUID oder des Mediumnamens. Oder aber ein beliebiges Band aus einem vordefinierten Backup Pool ziehen, die Sicherung starten und diese auf einem anderen Band aus demselben Pool fortsetzen, sobald das erste voll ist. Es spielt dabei auch keine Rolle, ob das zweite Band im selben Laufwerk eingesetzt ist - es muss lediglich als zum selben Backup Pool gehörig markiert sein.
Das ist alles toll, aber nichts neues. Warum belästigst du die Welt mit Altbekanntem?
Als ich versuchte, einige Backup-Scripts für ein eher einfaches Szenario (Beschreibung weiter unten) zu erstellen, ist mir aufgefallen, dass die Dokumentation zu NTBACKUP fehlerhaft und die Möglichkeiten, RSM in einem Script zu beeinflussen, sehr beschränkt sind. Ich habe versucht um diese Beschränkungen herumzuarbeiten und das ist genau das, wovon der restliche Teil dieses HOWTOs handelt.
Los geht's
Das Backup-Szenario
Jedes kleine Kind Jeder Sicherungsoperator weiß, dass eine gute Backup-Strategie notwendig ist, um Backups bezahlbar zu halten und nicht zu viele Medien, Zeit und anderer Ressourcen zu ver(sch)wenden, auf der anderen Seite aber möglichst viele Daten zu sichern und stets die Möglichkeit zu haben, jede Datei in den Zustand eines beliebig gewählten Zeitpunktes zurück zu versetzen.
Eine Strategie, die sich als effizient, gut handhabbar und flexibel erwies, ist die abwechselnde Sicherung in den Modi "Vollbackup" und "Inkrementielles Backup". Dabei wird das Vollbackup (auch "Normalbackup") regelmäßig, aber eher selten durchgeführt (z.B. ein Mal wöchentlich oder ein Mal monatlich). Inkrementielle Backups werden zwischen den Vollbackups und auch wesentlich häufiger durchgeführt (z.B. ein oder zwei Mal täglich).
Die Medien des Vollbackups werden über eine gewisse vorher definierte Zeit (z.B. ein Jahr) verwahrt, bevor sie im Schema rotieren und von einem neueren Vollbackup überschrieben werden.
Die Medien der inkrementiellen Sicherung rotieren nach jedem Vollbackup, werden aber nicht gelöscht/überschrieben, sondern mit zusätzlichen Sicherungssätzen versehen. Natürlich führt dies dazu, dass die Medien der inkrementiellen Sicherung sich mit der Zeit füllen, deshalb müssen diese Medien regelmäßig durch neue ersetzt werden (zur Häufigkeit des Wechsels kann man dabei keine generelle Empfehlung geben - es hängt von der Kapazität der Bänder und dem täglich zu sichernden Volumen ab). Da Bänder Teile eines mechanischen Systems sind und damit auch verschleißen, ist es eigentlich eine gute Idee, den Mediensatz durch fabrikneue Bänder zu ersetzen, anstatt einen bereits benutzten Mediensatz wiederzuverwenden.
Ich nehme hier an, dass der Wechsel der Bänder von weitesgehend unausgebildetem Personal durchgeführt wird - die Personen können lediglich die obigen Instruktionen zum Herausnehmen eines Mediums aus dem Laufwerk, dem Einlegen eines neuen Mediums und Rotation/Bänderaustausch befolgen.
Die Anforderungen
Wir brauchen ein mehr oder minder intelligentes Backup-Skript, dass Fehlbedienung erkennt - wenn z.B. ein inkrementielles Medium eingelegt wurde, aber ein Vollbackup ansteht oder umgekehrt. Des Weiteren soll das Skript auch komplett neue Medien erkennen und richtig behandeln - ob im Fall eines Voll- oder eines Inkrementialbackups. Und nicht zuletzt wollen wir irgendeine Art der Rückmeldung vom Sicherungsprozess - ein Log mit den Sicherungsprotokollen in einer E-Mail an den Sicherungsoperator z.B.
Wird nicht NTBACKUP all dies für uns tun?
Man erwartet von einer professionellen Sicherungssoftware, dass alles obige ohne besonderen Konfigurationsaufwand erledigt werden kann. Nur ist NTBACKUP in diesem Sinne alles andere als professionell, also muss man dort noch gehörig Hand anlegen. Das einzige, was NTBACKUP selbständig machen kann, ist entweder ein neues/unbekanntes Band zu nehmen, es zu formatieren und zu beschreiben, oder Sicherungssätze an ein bestehendes Band anzuhängen. Insbesondere kann es keine intelligente Unterscheidung zwischen einem zu überschreibenden Vollbackup-Band und einem keinesfalls zu überschreibenden Band mit inkrementiellen Sicherungssätzen machen und natürlich wird es auch keinerlei Logs per E-Mail verschicken. Schlimmer noch - es wird bestehende Log-Dateien schon nach kurzer Zeit (Zyklus von 10 Log-Dateien) überschreiben.
Also, was nun?
Wir brauchen einige Vorbereitungen:
Konfiguration neuer Backup-Pools
Wir öffnen das MMC Snapin "Computerverwaltung" (compmgmt.msc) und gehen zum Abschnitt Datenspeicher / Wechselmedien. Schaut euch die "Medienpools" an - darin befinden sich die Pools "Freie Medien", "Importmedien", "Nicht erkannte Medien" und "Backup". Wichtig dabei zu sehen ist, dass keiner dieser Pools selbst Medien enthält, sie alle haben je einen Unterpool (z.B. "4mm DDS"), in welchem die eigentlichen Medien eingeordnet werden.
