Nutzungsempfehlungen

Computer- und Medienservice | Hinweise für Windows-Server

Nutzungsempfehlungen

Hinweise für Windows-Server bzw. für Nutzer des Active Directory Windowsnetzes

1. Einleitung - Was zeichnet die betrachteten Netzlaufwerke aus und welcher Aspekt ihrer Datensicherheit soll hier betrachtet werden?

Dieser Beitrag betrifft nur Netzlaufwerke des Active Directory Windowsnetzes der HU, die durch die ZE CMS betreut werden. Zur Datensicherung von Netzlaufwerken, die durch andere Einrichtungen im Windowsnetz der HU bereitgestellt werden, sind die entsprechenden Verantwortlichen zu befragen.

Die durch die ZE CMS betreuten Fileserver wurden als hochverfügbare Fileserver-Cluster realisiert. Jeder Cluster besteht aus zwei bzw. drei physischen Servern, die auf die Standorte Adlershof und Mitte verteilt worden sind. Alle Fileserver sind über je zwei Glasfaserpaare redundant mit dem SAN (Storage Area Network) der HU verbunden, das alle Festplatten der Netzlaufwerke bereitstellt. Das SAN der HU realisiert intern eine Spiegelung aller Platten, um weitgehende Ausfallsicherheit zu gewähren. Bei begründetem Bedarf kann auch die Snapshot-Funktionalität des SANs für bestimmte SAN-Platten aktiviert werden.

In diesem Artikel werden hauptsächlich die Möglichkeiten der Wiederherstellung der durch den Tivoli Storage Manager (TSM) gesicherten Daten betrachtet [1]. Die Hochverfügbarkeit wurde im vorigen Absatz nur kurz angedeutet und wird nicht weiter behandelt. Ebenso werden die geeignete Vergabe von Zugriffsrechten zu Daten und die Sicherheit der zugriffsberechtigten Accounts nicht betrachtet, obwohl das elementare Grundlagen für Datensicherheit im Internet sind.

2. Nutzerleitfaden
2.1. Wie stelle ich fest, welche meiner Laufwerke im Netz liegen und vom CMS betreut werden?

In der Laufwerksübersicht des Windows Explorers tauchen Zeilen folgender Struktur auf:

<freigabename> (\\<servername>.<domainname>.hu-berlin.de) (x:)
oder

<freigabename> auf „\\<servername>.<domainname>.hu-berlin.de“ (x:)

z.B.
Projekte (\\huuser11c.user.hu-berlin.de) (P:)
oder

Projekte auf „\\huuser11c.user.hu-berlin.de“ (P:)

Wenn als <domainname> cms, public, user, uva oder uvb steht, wird es sich um ein zentral durch die ZE CMS bereitgestelltes Laufwerk handeln. Die Verantwortlichen der Einrichtungen sollten den eventuell verbleibenden Rest an Unsicherheit durch entsprechende Dokumentationen beseitigen.

2.2. Welche Richtlinien existieren an der HU zum Backup der betrachteten Netzlaufwerke und welche Auswirkungen haben sie?

Wenn zentrale Datensicherungen erfolgen, dann realisiert sie das TSM System.
Platten mit Freigabenamen, die auf „…Temp“ enden (Groß-Kleinschreibung beliebig), werden nicht gesichert.
Die TSM Systeme realisieren ein tägliches inkrementelles Backup aller betrachteten Netzlaufwerke - verteilt auf den Zeitraum von 18:00 bis etwa 4:30 Uhr.
Es werden maximal die letzten 4 Versionen einer existierenden Datei im TSM aufbewahrt.
Genau 4 Versionen existieren, falls an mindestens drei Tagen innerhalb der vergangenen 30 Tage Änderungen an der Datei erfolgten. Die älteste Version stammt dann vom viertletzten Änderungstag! Hat man unbemerkt an einem früheren Änderungstag einen Fehler bei der Veränderung der Daten begangen, so kann dieser nicht mehr durch eine Wiederherstellung aus dem TSM behoben werden! Eine eigene Generationsführung wichtiger Dateien kann das Problem etwas entschärfen. Man könnte beispielsweise nach Änderung über ‚abspeichern unter’ in den Namen der Datei das aktuelle Datum einfügen. Natürlich sollten dann regelmäßig alte Stände gelöscht werden, wenn man sich von der Konsistenz des aktuellen Stands überzeugt hat.
Es existieren zwei bzw. drei Versionen, falls an genau einem bzw. zwei Tagen innerhalb der vergangenen 30 Tage Änderungen an der Datei erfolgten.
Für jede existierende und nicht auf irgendeine Weise ausgeschlossene Datei existiert eine aktuelle Version, es sei denn, es handelt sich um eine Datei, die nach dem letzten erfolgreichen TSM Backup erzeugt wurde. Ein Problem stellt das versehentliche Löschen einer am selben Tag erzeugten Datei dar, da die betrachteten Netzlaufwerke nicht über einen Papierkorb verfügen, wie es bei lokalen Laufwerken der Fall ist.
Bewusste Verfälschungen oder fehlerhafte Änderungen an Daten, die vor mehr als 31 Tagen erfolgten, können nie mittels TSM behoben werden, da nur noch die fehlerhafte Version im TSM existiert. Auch hier wird deutlich, dass Backup keine Archivierung ist.
Wird eine Datei gelöscht, so behält TSM nur die aktuellste Version und markiert sie als inaktiv.
Diese inaktive Kopie wird maximal 62 Tage aufbewahrt.
Wird an Stelle einer gelöschten Datei eine gleichnamige (Groß-Kleinschreibung beliebig) erstellt, so wird die inaktive Kopie beim nächsten Backup wie eine Vorgängerversion der erstellten Datei behandelt, auch wenn sie es nicht ist!
Dadurch werden die Möglichkeiten der Wiederherstellung von Daten aus dem TSM durch den Nutzer eingeschränkt - statt 62 Tagen stehen die Daten der gelöschten Datei nur noch 31 Tage zu Verfügung.
Eine verfälschte oder verstümmelte Datei sollte nie gelöscht werden, falls die defekte Version schon durch TSM gesichert sein könnte. Ansonsten ist am Tag nach der Löschung nur noch die defekte Version im TSM vorhanden.
Wird ein Ordner gelöscht, so wandelt TSM beim nächsten Backup die aktuelle Version in eine inaktive.
Wird an Stelle eines gelöschten Ordners ein gleichnamiger (Groß-Kleinschreibung beliebig) erstellt, so wird die inaktive Kopie beim nächsten Backup gelöscht! Dies bewirkt, dass bei sogenannten ‚Point In Time’ Wiederherstellungen die Ordner, die nach dem ‚Point In Time’ neu angelegt und mit TSM gesichert wurden - natürlich auch alle Unterordner und enthaltene Dateien dieser – nicht mehr auftauchen. Ein Nutzer sollte deshalb nach Datenverlusten, die ganze Ordner betreffen, nicht versuchen, verschwundene Ordner mit gleichem Namen neu anzulegen.
Auf dem TSM System der HU existieren für alle Windows-Klienten (also auch für die Windows Fileserver) zentrale Dateien, die Masken für den Ausschluss bestimmter Daten von der Sicherung enthalten (siehe [2], [3]). Als Beispiel sei die Anweisung EXCLUDE.DIR *:\...\TEMP aufgeführt, die alle Ordner namens „Temp“ (Groß-Kleinschreibung beliebig) komplett vom Backup ausschließt. Die Anweisung EXCLUDE *:\...\pagefile.sys schließt alle Dateien namens Pagefile.sys vom Backup aus. Das letzte Beispiel EXCLUDE ?:\...\*.pqi verhindert die Sicherung aller Dateien mit der Extension .pqi.
Die nächste Quelle für den Ausschluss bestimmter Daten vom TSM-Backup ist in MS Windows Systeme durch den Inhalt des Unterschlüssels der Registrierung „HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup“ gegeben. Backup-Anwendungen sollen diesen Schlüssel auswerten, um zusätzliche - nicht zu sichernde - Daten zu bestimmen. Die TSM Backup/Restore Klienten werten korrekt formatierte Daten dieses Unterschlüssels aus. Ab TSM Version 5.3.4.6 (und höher) wird für inkorrekte Angaben eine Fehlernachricht ANS1009W in die error.log des TSM-Klienten geschrieben.
Auch lokal auf jedem Cluster-Fileserver (Windows TSM-Klienten) können innerhalb der Konfigurationsdatei DSM.OPT zusätzliche EXCLUDE Anweisungen stehen und damit auf das Backup wirken. Diese Möglichkeit wird von uns aber nur zur Unterdrückung von Backup-Fehlern durch ständig im Zugriff befindliche Dateien genutzt.

2.3. Welche Empfehlungen sollten bei der Nutzung der Netzlaufwerke beachtet werden?

Es sollten nur Daten gespeichert werden, die unwiederbringlich sind – wie eigene Entwicklungen und eigene Dokumentationen.
Es sollten keine zentral oder öffentlich ständig und langfristig verfügbaren Software- und Dokumentensammlungen als Kopien vorgehalten werden. Es sollte reichen, sich Quelle und Version auf geeignete Weise zu merken sowie bei Installationen zusätzlich die damit versorgten Rechner – z. B. im einfachsten Fall als ‚Link-Sammlung’.
Wenn bestimmte Daten einer eigenen Generationsführung unterliegen, so sollte die Anzahl der Generationen geeignet beschränkt sein.
Imagedateien ganzer Rechner oder Platten sollten nicht auf Netzlaufwerken gespeichert werden. Dafür bieten sich Wechselplatten, DVDs oder Externe Platten an.
Archive sollten auf speziellen Netzwerkplatten zur Auswertung bereitgestellt werden, die nicht durch TSM gesichert werden. Solche Daten sollten vorab geeignet archiviert werden.
Abgeschlossene Projekte sollten geeignet archiviert/publiziert (z. B. DissOnline, Open Access, nestor, edoc) und von den Netzlaufwerken entfernen werden.
An den Einrichtungen sollten Regelungen existieren, die den Umgang mit den Datenbeständen ausscheidender oder ausgeschiedener Mitarbeiter betreffen.

Wenn Daten zerstört oder durch andere gelöscht wurden, stellt sich als erstes die Frage, wo diese Daten eigentlich gespeichert waren. Um diese Frage möglichst genau beantworten zu können, sollten Sie monatlich ein Script, das beispielsweise folgende Kommandofolge enthält

del /f c:\scripts\baum\p_ordnername_old_old.txt

rename c:\scripts\baum\p_ordnername_old.txt p_ordnername_old_old.txt

rename c:\scripts\baum\p_ordnername.txt p_ordnername_old.txt

p:

cd \...\ordnername

dir /s > c:\scripts\baum\p_ordnername.txt

automatisch abarbeiten lassen.
Für \...\ordnername muss der vollständige Pfad eingesetzt werden. Es erzeugt einen aktuellen vollständigen Überblick über die Lage aller Ordner und Dateien des Ordnerbaums ab p:\...\ordnername und sichert die Strukturen der zwei Vormonate. Der Weg zur Automatisierung der Script-Abarbeitung ist vom Betriebssystem des Arbeitsplatzrechners abhängig.

2.4. Wie verhalte ich mich, wenn ich Dateien/Ordner versehentlich gelöscht oder verstümmelt habe?

Sofort reagieren! Habe ich lokal eine aktuelle Kopie der Daten?
Falls nicht, ist zu klären ob die Dateien/Ordner im TSM gesichert sein könnten (siehe 2.1. und 2.2.).
Wenn ja: Einen neuen Ordner anlegen (z. B. \Restore), in dem die entsprechenden Daten aus dem TSM wiederhergestellt werden können – darauf achten, dass genug freier Speicherplatz für die Wiederherstellung vorhanden ist (eventuell das Speicherlimit zeitweilig erhöhen lassen). Danach ist eine Mail an die Netzwerkverantwortlichen der Einrichtung (bei hoher Dringlichkeit auch an wintech@cms.hu-berlin.de) zu schicken, die Folgendes beinhalten sollte:
Problemursache und genauen Zeitpunkt kurz andeuten
möglichst genaue Quellpfad-Namen der wiederherzustellenden Daten bereitstellen
genauer Zeitraum, in dem der gewünschte Datenzustand verfügbar war
Zielpfad und -ordner der Wiederherstellung (darf nur im Zugriff der betroffenen Benutzergruppe liegen – Datenschutz; leerer Ordner …\Restore wird empfohlen)
eventuelle Speicherplatzprobleme – Erhöhung des Speicherlimits

(Also mindestens: Was ist mit welchem Stand und an welchem Speicherort wiederherzustellen.)

2.5. Wie verhalte ich mich, wenn ich Daten vermisse?

Über Suchfunktionen nach ihnen suchen.
Wenn das erfolglos war, sollten schreibberechtigte Kollegen befragt werden.
Die Dateien, die die Struktur des Ordnerbaums (siehe 2.3.) enthalten, nach den Namen durchsuchen.
Wenn Namen in der Strukturdatei gefunden wurden, analog zu 2.4. verfahren.

2.6. Wie verhalte ich mich, wenn Daten offensichtlich verstümmelt sind?

Die möglichen Ursachen eingrenzen, um Wiederholungen zu vermeiden und den ungefähren Zeitpunkt der Verstümmelung zu ermitteln. Die verstümmelten Daten frühestens löschen, wenn die Wiederherstellung der gewünschten Vorgängerversionen erfolgreich war!
Analog zu 2.4. verfahren

2.7. Wer ist für die Sicherung und Wiederherstellung zuständig?

Die Sicherung wird durch die Gruppen Wintech und TSM der ZE CMS organisiert.
Die Wiederherstellung von Daten erfordert einen Auftrag an lokale Windowsnetzverantwortliche der Einrichtung.
Diese Verantwortlichen klären den Sachverhalt und schicken einen entsprechenden Auftrag zur Wiederherstellung als Mail an wintech@cms.hu-berlin.de (was ist mit welchem Stand an welchem Speicherort wiederherzustellen).

Humboldt-Universität zu Berlin - Computer- und Medienservice