§1 Zweck dieses Dokumentes

Dieses Dokument definiert die allgemeine Leistung des Dienstes "Zentrale Datensicherung für Endbenutzer". Es beschreibt die Leistungen für Backup/Restore und Archive/Retrieve basierend auf Benutzeranforderungen.

§2 Änderungen dieses Dokumentes

IWR bemüht sich den Leistungsumfang dieses Dienstes möglichst lange konstant zu halten. Es ist nicht auszuschließen, dass aufgrund äußerer Randbedingungen, wie etwa funktionale Veränderungen der Software durch den Hersteller oder Betriebssystem-, Software- oder Hardwareunverträglichkeiten einzelne Passagen verändert werden müssen. IWR wird die Änderungen rechtzeitig über die Mailingliste (adsm@listserv.fzk.de) verteilen und im Web bekannt geben. Mit Großkunden (individuell eingerichtete Policies) wird vor der Änderung eine einvernehmliche Regelung getroffen.

§3 Die Serverinfrastruktur

Als zentrales Produkt für Datensicherung wird der IBM Tivoli Storage Manager (ITSM) eingesetzt. Es stehen fünf Tivoli Storage Manager Server in zwei Standorten zur Verfügung. Diese können gemeinsam auf zwei Tape Roboter über ein Speichernetzwerk (Fibre Channel mit 2 Gb/s) zugreifen und verfügen über 8 Laufwerke des Typs LTO Ultrium und 16 Laufwerke des Typs LTO Ultrium 2. Alle Server sind über Gigabit Ethernet an das FZK-LAN angebunden.

Die Server sind in der Funktionalität getrennt in Sicherungs- (Backup) und Archivierungsserver. Die Benennung der Server ist:

Beispiel IA1: I (Standort IWR oder O für OKD), A (Archive oder B für Backup), 1 (laufende Nummer)

Welcher Server für einen Client zuständig ist wird von den Administratoren festgelegt.

§4 Begriffsdefinition

Archivierung

Der Begriff "Archivierung" wird benutzt für eine langfristige Speicherung von Daten. Dies wird durch Speichern einer oder mehrerer Kopien einer Datei auf den Archivierungsservern erreicht. Typischerweise wird diese Funktion benutzt, um eine oder mehrere Kopien von Daten zu einem definierten Zeitpunkt zu erhalten. Sobald diese Kopien existieren, können diese Daten vom Plattenspeicher gelöscht werden um Speicherplatz freizugeben. Diese Dateien können zurückgespeichert (Retrieved) werden, solange diese auf dem Server existieren. Wie lange die Dateien auf dem Server gespeichert bleiben hängt vom Regelwerk ab.
 
 

Backup

Der Begriff "Backup" wird benutzt für eine kurzzeitige Sicherung von Daten, die häufig geändert und online gehalten werden. Dies wird durch Speichern von verschiedenen Versionen auf dem Datensicherungsserver erreicht. Wenn sich eine Datei ändert, wird die neue Version auf den Server übertragen und, je nach Regelwerk, eine veraltete auf dem Server gelöscht. Backup wird als Sicherheitsmaßnahme gegen physikalische oder logische Fehler ausgeführt. Nach einem Fehler oder versehentlichem Ändern oder Löschen kann die Datei vom Sicherungsserver zurückgesichert (Restored) werden. Wie viele verschiedene Versionen dazu zur Verfügung stehen, hängt vom Regelwerk ab.
 
 

§5 Ziele des Dienstes

Das Ziel des Dienstes ist es, dem Endbenutzer ein hochqualitatives Management seiner Daten zur Verfügung zu stellen.

Der Dienst stellt Sicherungen für Dateien, die dezentral am Client-Rechner (dsm.sys/dsm.opt User Option Datei) oder zentral in IWR (zentraler ITSM Scheduler) registriert wurden, zur Verfügung.

Sicherungen (Backups) können sowohl vom User initiiert, als auch über den zentralen ITSM-Scheduler gesteuert werden. Die Attribute des ITSM-Schedulers werden im Standardregelwerk definiert. Archivierungen werden nur vom User initiiert, und unterliegen keinem Automatismus.

Alle Dateien, die ohne Angabe spezieller Optionen gesichert oder archiviert werden, unterliegen den Definitionen eines Standardregelwerkes (Standard Managementklasse), deren Attribute und Werte im Folgenden erklärt werden:

Die Standard Backup Copygroup ist folgendermaßen definiert:

1. Maximal zwei Backup Versionen eines Files werden auf dem Server gehalten, wenn dieses File auf dem Clientrechner existiert. Backup unterscheidet verschiedene Versionen einer Datei.
2. Wenn das File auf dem Clientrechner gelöscht wird, wird nur noch eine Version gespeichert.
3. Wenn das File auf dem Clientrechner gelöscht wurde, ist diese letzte Version noch für 60 Tage verfügbar.
4. Die Dateien werden einfach auf Bändern gespeichert. Ein Ausfall eines Bandes kann zum Verlust der Backupkopie führen.
5. Die Dateien werden zuerst auf Staging-Platten gespeichert und danach mindestens einmal am Tag auf Bänder verschoben. Diese Staging-Platten sind ohne Redundanz ausgelegt. Ein Ausfall einer Platte kann zum Verlust der Backupkopie führen.
6. Die Summe aller Dateien (auf Staging-Platten oder Tape) ist kostenpflichtig nach der aktuell gültigen IWR Preisliste.

Die Standard Archive Copygroup ist folgendermaßen definiert:

1. Files können jederzeit archiviert werden, unabhängig ob sich die Datei geändert hat oder nicht (im Gegensatz zu Backup), solange die Datei nicht im aktiven Zugriff (geöffnet) eines Benutzers ist.
2. Wenn ein File archiviert wurde, werden zwei Kopien dieses Files für 365 Tage (Managementklasse Arch12) aufgehoben (im Gegensatz zu zwei Versionen beim Backup werden hier identische Dateien zur Sicherheit gegen Bandfehler doppelt gehalten).
3. Die Dateien werden auf zwei unterschiedlichen Bändern, in zwei 700m entfernten Robotersystemen auf zwei unterschiedliche Tapetechnologien gespeichert. Der Ausfall eines Bandes oder eines Standortes oder eines Fehlers in der Tapetechnologie führt nicht zum Verlust der Archivkopie. Ein zeitlich eng zusammen liegender Fehler in zwei Systemen hingegen schon.
4. Die Dateien werden zuerst auf Staging-Platten gespeichert und danach mindestens einmal am Tag auf Bänder verschoben. Diese Staging-Platten sind als RAID5 Arrays ohne Hot Spare ausgelegt. Ein Ausfall einer Platte kann nicht zum Verlust der Archivkopie führen. Ein zeitlich eng zusammen liegender Fehler zweier Platten hingegen schon.
5. Die Summe aller Dateien auf Staging-Platten oder Tape (da doppelt gehalten Summe der archivierten Daten mal zwei) auf dem Sicherungsserver ist kostenpflichtig nach der aktuell gültigen IWR Preisliste.

Alternativ stehen zur Archivierung folgende Optionen zur Verfügung:

• Aufbewahrungszeiten für 3 Monate (Managementklasse Arch03), 5 Jahre (Arch60), 6 Jahre (Arch72) und No Limit (ArchNL).

§6 Abhängigkeiten

Der Dienst baut auf dem Dienst des FZK-LANs auf. Wenn dieser nicht verfügbar ist, kann auch der Dienst Zentrale Datenspeicherung nicht in Anspruch genommen werden.

§7 Betriebszeiten

1. Der Dienst ist von Montag bis Freitag 08:00 h – 17:00 h administrationsseitig besetzt. Eine Betriebsunterbrechung außerhalb dieser Zeit kann, muss aber nicht zwangsläufig erkannt und beseitigt werden.
2. Wartung an den zentralen Datensicherungsservern wird über die Mailingliste adsm@listserv.fzk.de mindestens eine Stunde im Voraus angekündigt und in der Regel innerhalb eines Arbeitstages abgeschlossen. Wenn Sie Mitglied dieser Liste werden wollen schicken Sie eine Mail an adsm@iwr.fzk.de .

1. Benachrichtigung über neue Clientversionen und Meldungen über End-of-Service werden über die Mailliste verschickt.
2. Der Endbenutzer ist dafür verantwortlich, dass eine mit der aktuellen Serverversion kompatible und noch in Wartung befindliche Version des Sicherungsclients (ITSM-Client) verwendet wird. Wenn Hilfe bei der Installation benötigt wird, steht IWR über die IWR-Hotline (Tel. 6060) oder das ITSM-Team unter adsm@iwr.fzk.de zur Verfügung. Auf Wunsch ist auch eine Installation Vor-Ort gegen Vergütung nach der aktuell gültigen IWR-Preisliste möglich.
3. Der Endbenutzer ist dafür zuständig, dass die gewünschten Dateien gesichert werden.
4. Sind die Dateien während der Sicherung im aktiven Benutzerzugriff (geöffnet), können sie nicht gesichert werden.
5. Der Endbenutzer überprüft die clientseitigen Log Dateien auf korrekte Durchführung der Sicherungsläufe.
6. Eine Sicherung kann den Status COMPLETED (alle Dateien erfolgreich gesichert), FAILED (eine oder mehrere Dateien nicht gesichert) oder MISSED (keine Datei gesichert) haben. Bei den Zuständen FAILED oder MISSED wird von IWR jeden TAG um 09:00 h eine Mail an die vom Nutzer angegebene Mailadresse geschickt. Der Endbenutzer ist dafür verantwortlich, dass diese Mailadresse gültig und aktuell ist. Nach Möglichkeit sollte eine Mailliste angegeben werden, damit bei Urlaub oder Krankheit eines Administrators trotzdem jemand benachrichtigt wird.
7. Der Endbenutzer ist dafür zuständig, dass eventuell installierte Datenbanken (SQL, Oracle, DB2 etc) oder Applikationen (Lotus Notes, Exchange, SAP etc), die verhindern, dass eine Sicherung aufgrund geöffneter Dateien möglich ist, diese IWR mitzuteilen und einen entsprechenden Client (TDP – Tivoli DataProtection Agent) zu installieren. TDPs sind gesondert kostenpflichtig.
8. Der Endbenutzer ist dafür zuständig, dass gewünschte Schedules (automatische Sicherungen) von IWR eingetragen werden.
9. Zentrale Schedules können nur für Rechner eingerichtet werden, die ständig (auch im Urlaub etc) laufen.
10. Der Endbenutzer ist für Restores der Daten selber verantwortlich. Aufgrund der höchst inhomogenen Landschaft im FZK ist die Erarbeitung einer generellen Restoreanleitung nicht möglich. Dies gilt insbesondere für Datenbanken etc. Entsprechende Tests sind unbedingt notwendig, damit im Fall eines Datenverlustes der Administrator vor Ort schnell und sicher reagieren kann.
11. Der Benutzer hat dafür Sorge zu tragen, dass das Passwort seines ITSM-Clients nur den berechtigten Personen bekannt ist. Mit diesem Passwort hat man unbeschränkten Zugang zu den gespeicherten Daten auf dem Sicherungsserver.
12. Es stehen eine Hotline (Tel: 6060) und eine Mailingliste adsm@iwr.fzk.de als Forum für die Problembeseitigung zur Verfügung. IWR hat Zugang zum Herstellersupport und kann Probleme zentral beim Hersteller melden.

Die zentralen Datensicherungsserver in IWR verfügen über eine Datenbank in der alle Informationen über Files und Regelwerke (Policies) verzeichnet sind. Diese Datenbank ist notwendig zum Zurückholen der Dateien. Sie wird deshalb täglich um 12:00 h in einen örtlich vom Server getrennten Bandroboter gesichert. Darüber hinaus verfügt sie über ein Recoverylog, das eine Wiederherstellung der Datenbank auch granularer als die tägliche Vollsicherung erlaubt. Im Betrieb werden zwei Kopien dieser Datenbank und des Recoverylogs gepflegt.
 
 

§10 Anhang

Spezielle Policyinformationen für

SAP

IK

ENVISAT

METEOSAT