Backup-Technik

Allgemeine Informationen finden sich im Beitrag Datensicherung. Dort erfährt man auch, wo die Software bezogen werden kann. Ein Dateisystem (im Unix-Sinne) oder ein Laufwerk (im Windows-Sinne) wird im Backup-System Dateibereich genannt. Ziel des inkrementellen Backups (der Teilsicherung) ist es, ein getreues Abbild des Dateibereichs im Backup-System vorzuhalten. Ein Backup durchzuführen bedeutet, dieses Abbild zu aktualisieren. Eine Datei-Kopie, die zum aktuellen Abbild gehört, heißt aktive Backup-Kopie. Eine Datei-Kopie, die nicht mehr zum aktuellen Abbild gehört, z.B. weil sie mittlerweile durch eine aktuellere Kopie ersetzt wurde, oder weil die Originaldatei nicht mehr existiert, heißt inaktive Backup-Kopie.

Inaktive Backup-Kopien verfallen nach angemessener Zeit, d.h. sie werden vom Backup-System automatisch gelöscht. Im Standard-Fall wird eine inaktive Backup-Kopie gelöscht,

spätestens nach 100 Tagen (wenn es sich um die letzte Backup-Kopie einer nicht mehr existierenden Datei handelt),
bereits nach 30 Tagen, wenn es aktuellere Backup-Kopien gibt,
sobald es 6 aktuellere Backup-Kopien gibt (und das Original noch existiert),
sobald es 4 aktuellere Backup-Kopien gibt und das Original gelöscht ist.

Clients, die sich mehr als ein Jahr nicht am TSM Server angemeldet haben, werden ohne vorherige Rücksprache gelöscht.

Aktive Backup-Kopien verfallen nie. Die Überführung einer Backup-Kopie vom Zustand aktiv in den Zustand inaktiv, und damit der Verfall obsoleter Backup-Kopien, kann nur durch die Durchführung eines Backups angestoßen werden, da nur auf diesem Wege festgestellt werden kann, dass sie nicht mehr zum aktuellen Abbild gehört.

Sowohl auf der Client-Seite, als auch auf Seiten des TSM-Servers ist es möglich, Dateien vom Backup auszuschließen. Die im TSM-Server installierte, und somit für alle Clients wirkende, Ausschluss-Liste ist im Abschnitt "Ausgeschlossene Dateien" dokumentiert.

Archiv

Archiv-Kopien werden über eine genau festgelegte Dauer aufbewahrt und dann automatisch und ohne Vorwarnung gelöscht. Gibt es von einer Datei mehrere Archiv-Kopien, so gilt diese Frist für jede dieser Kopien, denn im Gegensatz zum Backup bedeutet die Erstellung einer neuen Archivkopie einer Datei nicht, dass ältere Archivkopien dieser Datei verfallen.

Die Aufbewahrungsfrist für Archiv-Kopien beträgt 3660 Tage. Wird beim Archivieren die Managementklasse LOG angegeben, so beträgt sie 30 Tage.

Das ZIV bietet Archivierung nur noch auf einem dedizierten TSM-Server (TSMARCHIV) an.

Anmeldung (Registrierung) des TSM-Clients

Vor der Entscheidung für den TSM klären Sie bitte mit der zuständigen IVV, ob es von ihr ein Angebot zur Sicherstellung der Verfügbarkeit Ihrer Daten gibt (z.B. über Server der IVV).

Der TSM-Client ("Knoten" oder "Node" in TSM-Terminologie) muss im TSM-Server eingetragen (registriert) werden. Dazu sind dem TSM-Administrator formlos (Mail an backup@uni-muenster.de) folgende Angaben zu machen:

Name des TSM-Clients.: Er sollte identisch mit dem Namen des Rechners sein.
Anfangspasswort.: Nach der Registrierung sollte es umgehend geändert werden. (s. "Sicherheitsaspekte beim Einsatz von TSM")
Betriebssystem / Plattform.: Windows-Variante, Linux, Solaris, AIX, Mac, ...,
Physik.: Real oder virtuell?
Lizensierungs-Informationen.: Bei einer realen Maschine: Anzahl der PVUs gemäß Tabelle der IBM.; Bei einer VM: Realer Host (ggf. kompletter Server-Cluster) mit Anzahl der PVUs, wenn im ZIV noch nicht bekannt.
Dienste.: Gemäß Backup-Richtlinie sollen den Backup-Dienst nur Server (keine Arbeitsplatz-Rechner) nutzen. Welche Dienste bietet der anzumeldende TSM-Client an?
Kontaktadresse(n) für E-Mail-Benachrichtigungen und, falls davon abweichend, Name(n) der Kontaktperson(en).: Gelegentlich werden an die Kontaktadressen E-Mails, teils administrativen Inhalts, teils Hinweise auf Fehlersituationen verschickt. Die Empfänger sollten darauf reagieren können.
Die Kontaktpersonen sind, neben der Institutsleitung und den laut Rechner-Datenbank für diesen Rechner verantwortlichen Personen, die einzigen Personen, die sicherheitskritische Aktionen, wie etwa die Neusetzung des Passwortes, veranlassen können (s. "Sicherheitsaspekte beim Einsatz von TSM").
Die Kontaktadresse kann die E-Mail-Adresse der Kontaktperson sein, muss es aber nicht.
Fachbereich und Institut.
Umfang der zu sichernden Daten.: Hier geht es nur um eine grobe Einschätzung (in GB), die es erlaubt, eine Klassifizierung in Standard-Clients und sehr große Clients vorzunehmen.
Teilnahme am Scheduler-gesteuerten Backup erwünscht?: Man kann das Backup von Hand anstoßen. Zumeist ist jedoch automatisches, nächtliches Backup durch den TSM-Scheduler sinnvoll. Letzteres muss im TSM-Server eingetragen werden. Das Scheduler-gesteuerte Backup wird durch einen Automatismus überwacht, der eine E-Mail an die Kontaktadressen schickt, wenn es in der Nacht zuvor nicht gelaufen ist.

Installation des TSM-Clients

Nach der Software-Installation, die in den READMEs beschrieben ist, sind die Konfigurationsdateien anzupassen, wenn dies nicht schon bei der Installation durch den Configuration Wizard geschehen ist. Auf jeden Fall müssen folgende Einstellungen vorgenommen werden (in der Datei dsm.sys auf Unix-Systemen, sonst in der Datei dsm.opt):

COMMmethod TCPIP
TCPServeraddress TSM04.UNI-MUENSTER.DE

Die zweite Zeile gibt den Namen des TSM-Servers an. Dieser wird Ihnen vom TSM-Administrator nach Durchführung der Registrierung (s.o.) mitgeteilt. Sinnvoll sind überdies die folgenden Eintragungen:

COMPression ON
PASSWORDAccess generate

Die erste Zeile spezifiziert, dass der TSM-Client die zu übertragenden Daten komprimieren soll. Dies reduziert die Netzlast, erhöht aber die Belastung des Client-Prozessors. Wenn dieser schwach ist, sollte man die Kompression besser ausgeschaltet lassen. Die zweite Zeile sorgt dafür, dass das TSM-Passwort automatisch generiert wird. Nur bei Eröffnung der ersten TSM-Sitzung wird es erfragt und dann in einer lokalen Datei verschlüsselt abgelegt, vorausgesetzt, der Aufrufer hat die nötigen Rechte (im Unix muss er der root-User sein).

Der Name, unter dem sich der TSM-Client beim Server meldet, ist standardgemäß identisch mit dem Rechnernamen. Wenn Rechnername und Client-Name unterschiedlich sind, kann der Client-Name in der Konfigurationsdatei gesetzt werden:

NODEname <Client-Name>

Ein Scheduler-gesteuertes (s. u.) oder mittels des Kommandos dsmc incremental angestoßenes Backup schreibt standardgemäß alle lokalen Dateibereiche ab. Wenn etwas anderes gewünscht ist, sollte man in der Datei dsm.opt (auch auf Unix-Rechnern diese Datei!) die folgende Eintragung vornehmen:

DOMain <Dateibereich1> <Dateibereich2> ... <DateibereichN>

Der TSM-Client kann dazu veranlasst werden, bestimmte Dateien vor dem Transfer zu verschlüsseln. Die dazu benötigten Einstellungen lauten Include.Encrypt und ENCryptkey (s. "Sicherheitsaspekte beim Einsatz von TSM").

Damit der Linux-Client Dateien, deren Namen Umlaute enthalten, beim Backup nicht überspringt, muss das korrekte Locale gesetzt werden. IBM empfiehlt die Setzung von 'en_US'.

Betriebliche Regelungen

Durch den Einsatz des TSM ergeben sich auch Verpflichtungen, die sich grundsätzlich aus dem Gebot, mit den Ressourcen verantwortlich umzugehen, ableiten. So kann man mit Hilfe der Include-Exclude-Liste in der Konfigurationsdatei dafür sorgen, dass nur die sicherungswürdigen Dateien abgeschrieben werden. Ferner sollte man Daten löschen, wenn sie nicht mehr gebraucht werden. Im Archiv-Bereich kann dies mit dem Kommando delete archive (oder über die grafische Oberfläche) geschehen.

Backups wird man in der Regel nicht löschen wollen, es sei denn, es handelt sich um Backups eines nicht mehr existierenden Dateibereichs. Wie bereits erwähnt, kann die letzte Backupkopie einer Datei nämlich nur verfallen, wenn im Zuge eines inkrementellen Backups (Teilsicherung) festgestellt wird, dass die Datei nicht mehr existiert. Gibt es den zugehörigen Dateibereich nicht mehr, kann auch kein inkrementelles Backup dieses Dateibereichs mehr durchgeführt werden und die Backupkopien bleiben prinzipiell für immer erhalten. Dies gilt sowohl bei Auflösung, als auch bei Umbenennung eines Dateibereichs; bei Umbenennung wird unter dem neuen Namen ein neues Backup erstellt, das alte bleibt erhalten.

Zum Löschen aller Backups und Archivdateien eines Dateibereichs bedient man sich des Kommandos delete filespace oder der grafischen Oberfläche. Falls der TSM-Server diese Aktion nicht erlaubt (dies ist die Voreinstellung), sollte der TSM-Administrator um Freigabe gebeten werden.

Weitere Regelungen sind in der TSM-Betriebsregelung nachzulesen.

Ausgeschlossene Dateien

Auf jedem System gibt es eine Reihe von Dateien, die nicht abgeschrieben werden sollten. Cient-seitig kann deren Backup mit Hilfe der Include-/Exclude-Liste unterbunden werden, wovon viele Client-Administratoren auch Gebrauch machen, andere aber eben nicht. Künftig soll nun das Backup bestimmter Dateien durch eine vom TSM-Server erzwungene Exclude-Liste grundsätzlich verhindert werden. Diese Server-seitige Exclude-Liste wirkt zusätzlich zur Client-seitigen Include-/Exclude-Liste. Die durch die Kombination der beiden Listen letztlich wirksame Liste kann auf der Kommandozeilen-Oberfläche mittels query inclexcl erfragt werden.

Die Server-seitig erzwungene Exclude-Liste sieht folgendermaßen aus:

Für Unix-Clients:

      exclude     /.../core
      exclude     /var/log/lastlog
      exclude.dir /.../.netscape/cache
      exclude.dir /.../.mozilla/.../Cache
      exclude.dir /.../.opera/cache4
      exclude.dir /.../.kde/share/cache
      exclude.dir /.../.kde/share/thumbnails

Für Windows-Clients:

exclude "*:\...\EA DATA. SF" exclude "*:\...\pagefile.sys" exclude "*:\IBMDOS.COM" exclude "*:\MSDOS.SYS" exclude "*:\IO.SYS" exclude.dir "*:\microsoft uam volume" exclude.dir "*:\System Volume Information" exclude.dir "*:\...\SYSTEM32\CONFIG" exclude.dir "*:\...\Recycler" exclude.dir "*:\.../Recycled" exclude.dir "*:\...\Papierkorb" exclude.dir "*:\...\Temporary Internet Files" exclude.dir "*:\...\cookies" exclude.dir "*:\...\Netscape\...\Cache" exclude.dir "*:\...\His6" exclude.dir "*:\...\Verlauf"

Sicherheitsaspekte beim Einsatz des TSM

Die Kontaktpersonen

Bei der Registrierung werden dem TSM-Client eine oder mehrere Kontaktadressen und Kontaktpersonen zugeordnet.

Gelegentlich werden an die Kontaktadressen E-Mails, teils administrativen Inhalts, teils Hinweise auf Fehlersituationen verschickt. Die Empfänger sollten darauf reagieren können.

Die Kontaktpersonen sind, neben der Institutsleitung und den laut Rechner-Datenbank für diesen Rechner verantwortlichen Personen, die einzigen Personen, die sicherheitskritische Aktionen veranlassen können. Hierzu gehören: die Zuteilung eines neuen Passwortes (s. u.), das Löschen von Backups alter Dateibereiche, das Löschen des gesamten Clients, und schließlich die Eintragung einer neuen Kontaktperson.

Bei all diesen Aktionen besteht das Problem des sicheren Kommunikationskanals zwischen der Kontaktperson und dem TSM-Administrator im ZIV. Der TSM-Administrator muss sicherstellen können, dass die Anfrage wirklich von der angegebenen Kontaktperson kommt. Fernmündlich und, zumindest ohne weitere Vorkehrungen, per E-Mail ist dies nicht möglich. Wenn die Kommunikation per E-Mail erfolgen soll, so muss diese signiert werden. Der öffentliche Schlüssel der Kontaktperson muss dazu von einem anerkannten Zertifikatgeber zertifiziert sein. Alternativen zur signierten E-Mail sind ein mit dem Institutsstempel versehener und unterschriebener Brief (kein Fax), oder persönliches Vorsprechen unter Vorlage des Ausweises.

Das TSM-Passwort

Eine zentrale Rolle beim Schutz vor unberechtigtem Zugriff spielt das Passwort des TSM-Clients. Bei der Wahl und Handhabung des Passwortes ist größte Sorgfalt geboten, da jeder, der es kennt, Zugang zu allen Sicherungs- und Archiv-Kopien dieses TSM-Clients erhalten kann.

Das Passwort kann bis zu 64 Zeichen lang sein und aus Buchstaben, Ziffern und den Zeichen +._-& bestehen. Groß- und Kleinschreibung werden nicht unterschieden.

Beim Start einer TSM-Sitzung wird das Passwort nicht übertragen, so dass es nicht durch Abhören der Verbindung zwischen Client und Server ausgespäht werden kann. Da der TSM-Server nicht dazu bewegt werden kann, seine (verschlüsselten) Passwörter herauszugeben, ist ein systematischer Angriff, wie etwa früher mit dem Crack-Programm im Unix-Bereich, nicht möglich. Wenn man ferner mittels der Setzung PASSWORDACCESS GENERATE in der Konfigurationsdatei dafür sorgt, dass das Passwort zu Beginn einer TSM-Sitzung (außer der ersten) automatisch erzeugt wird, besteht die Gefahr, dass es beim Eintippen ausgespäht wird, auch nicht mehr.

Die Setzung PASSWORDACCESS GENERATE hat den weiteren Vorteil, dass man ein sehr langes Passwort wählen kann, da man es ja selten eintippen muss. Sollen außer dem System-Verwalter auch andere Benutzer den TSM, z. B. zum Archivieren oder zum Restaurieren von Dateien, nutzen können, ist PASSWORDACCESS GENERATE ein Muss, da man ihnen das Passwort natürlich nicht mitteilen will.

Die Verwendung von PASSWORDACCESS GENERATE hat allerdings einen Nachteil: Das Passwort wird verschlüsselt in einer Datei auf dem TSM-Client abgelegt, die, z. B. bei einer Neuinstallation, schon mal verloren gehen kann. Außerdem ist die Verschlüsselungsmethode abhängig von der Umgebung; bei Austausch beispielsweise des Rechners funktioniert das verschlüsselte Passwort nicht mehr. Wenn man es dann nicht mehr kennt - man hat es ja lange nicht mehr eingeben müssen - bleibt nur die Setzung eines neuen Passwortes durch den TSM-Administrator (s. o.).

Verschlüsselung der Backup- und Archivdaten

Ab der Version 4.1 für Windows, und ab 4.2 für Unix kann die TSM-Client-Software die Daten vor dem Transfer zum TSM-Server verschlüsseln. Die Art der Verschlüsselung (DES 56 Bit oder AES 128 Bit) kann mittels der Option ENCRYPTIONType eingestellt werden.

Zur Steuerung der Verschlüsselung dienen im Wesentlichen zwei Optionen:

Mittels include.encrypt <Muster> wird festgelegt, dass die Dateien, deren Namen dem angegebenen Muster entsprechen, verschlüsselt werden sollen. Diese Option bedeutet nicht, dass die betroffenen Dateien damit auch automatisch ins Backup eingeschlossen werden; dies müsste ggf. durch andere Include-Anweisungen sichergestellt werden. Bei Unix-Clients erfolgt diese Setzung in der Datei dsm.sys.

Die zweite Option steuert, ob der Schlüssel lokal abgespeichert wird (encryptkey save, die Voreinstellung), oder bei Bedarf vom Benutzer erfragt wird (encryptkey prompt).

Beispiel: Der folgende Auszug aus der Konfigurationsdatei (dsm.op) eines Windows-Clients würde dafür sorgen, dass von der C-Platte nur das Verzeichnis \Daten mit allen Unterverzeichnissen beim Backup abgeschrieben wird, und dass davon die Dateien im Unterverzeichnis geheim verschlüsselt werden. Der Schlüssel wird lokal abgespeichert; da dies die Voreinstellung ist, könnte diese Zeile auch fehlen.

encryptkey save
exclude c:\...\*
include c:\Daten\...\*
include.encrypt c:\Daten\geheim\...\*

Ein Wort zur Warnung: Da die Daten im TSM-Server verschlüsselt abgelegt werden und der Schlüssel dem TSM-Server nicht bekannt ist, bedeutet der Verlust des Schlüssels den unwiederbringlichen Verlust der verschlüsselten Daten!

Verlust von Daten im TSM-Server

Datenverluste im TSM-Server selbst, etwa durch defekte Platten oder Magnetbandkassetten, sind nicht völlig auszuschließen, und in der Vergangenheit auch schon vorgekommen, obwohl bei der Wahl der Bandperipherie auf eine zuverlässige Technologie geachtet wurde.

Im Archiv-Bereich wird diesem Risiko dadurch Rechnung getragen, dass von der Archivkopie einer Datei eine zweite Kopie auf einem separaten Band, und eine dritte Kopie auf dem TSM-Server der RWTH Aachen erstellt wird. Das Erstellen der beiden Kopien geschieht nicht sofort, sondern in der folgenden Nacht. Wenn man also das Original nach dem Archivieren löschen will, sollte man dies erst am nächsten Tag tun, wenn man auf der sicheren Seite sein will.

Im Backup-Bereich ist die doppelte Speicherung der Daten zwar auch möglich, sie wird bei uns aber nicht betrieben. Dies hat natürlich Kostengründe, ist darüber hinaus aber auch Ergebnis der Überlegung, dass zwischen Originaldatei und Backupkopie eine symmetrische Beziehung herrscht: Ist das Original zerstört, kann es aus der Backupkopie wiederhergestellt werden, und umgekehrt genauso.

Bei einem Verlust von Backupkopien schickt der TSM-Administrator eine Mail an die Kontaktadressen der betroffenen TSM-Clients. Darin werden die betroffenen Dateibereiche und, wenn es nicht zu viele sind, auch die betroffenen Dateien genannt. Wenn eine regelmäßige Sicherung dieser Dateibereiche über den Scheduler erfolgt, ist keine Aktion seitens der Kontaktpersonen erforderlich, andernfalls sollte umgehend ein inkrementelles Backup (Teilsicherung) angestoßen werden, das automatisch alles Erforderliche unternimmt.

Wem diese Maßnahmen nicht reichen, wer also beispielsweise für die Backups ausgewählter Dateien doppelte Speicherung benötigt, möge sich an den TSM-Administrator wenden. Der TSM verfügt über sehr feine Steuerungsmöglichkeiten, so dass Sonderbehandlungen bis hinunter auf Dateiebene definiert werden können. Wenn Sonderwünsche im Rahmen unser Möglichkeiten liegen, werden wir ihnen gerne nachkommen.