Häufig gestellte Fragen zur Datensicherung

Windows, Mac, (Linux)

IBM-Server: Index of /storage/tivoli-storage-management/maintenance/client:

• Hier sollten Sie stets nach der neuesten Version Ausschau halten: erst in den Unterverzeichnissen wird das Betriebssystem - Windows, Mac, etc. - ausgewählt.
• Hier erhalten Sie prinzipiell auch Linux-Clients; jedoch ist deren korrekte Installation und Konfiguration aufwändig.

Linux

Intern genutzte Linux-Installationsskripte (auf 'good will'-Basis):

• Diese enthalten in komprimierter Form das notwendige Wissen, um den Linux-Client korrekt zu installieren und für Backups zu konfigurieren; daher empfehlen wir diesen Weg. Insbesonders Zeichensatzprobleme - die betroffenen Dateien werden nicht gesichert! - sollten nicht auftreten; siehe auch [Linux] Warum erhalte ich Fehlermeldungen bezüglich falscher Zeichensatzeinstellungen wie '... contains one or more unrecognized characters and is not valid.'?.
  
  • Die Skripte funktionieren bei normalen Backup-Client-Konfigurationen in der Regel (schon existierende Konfigurationsdateien sollten dabei nicht überschrieben werden).
  • Schon existierende Konfigurationen, die den Archiv-Server oder auch mehrere Datensicherungs-Server ansprechen - bspw. Backup-Server und Archiv-Server von demselben Client-Rechner aus angesteuert - werden nicht unterstützt. Hier ist Handarbeit vor und nach der Installation des neuen Clients notwendig.
• Bitte verwenden Sie die neueste Version des für Ihr Linux passenden Skriptes.
  Es wird jedoch nicht notwendigerweise die aktuellste über obigen IBM-Server erhältliche Client-Version installiert: falls Sie dies stört, könnten Sie das Skript auch anpassen.
• Sollte ein Skript nicht funktionieren, erhalten Sie durch Hineinschauen zumindest Hinweise darauf, was alles zu beachten ist.

Sollten nach der Installation eines aktuellen Linux-Clients auf diesem Weg Zeichensatz- oder andere Probleme unter Linux bestehen, wenden Sie sich bitte an backup-support@tik.uni-stuttgart.de (auch für Rückmeldungen über etwaige Anpassungen eines der Skripte sind wir dankbar).

Ein Backup dient der Sicherung Ihrer Daten im aktuellen Zustand; es sichert Sie ab gegen unabsichtliche Veränderung oder Löschung Ihrer Daten, z.B. bei Hardware-Ausfällen. Es ist nicht dafür geeignet, Daten im Zustand zu einem bestimmten Zeitpunkt längerfristig zu sichern, da nur die aktuelle Version langfristig aufbewahrt wird (Versionen überschriebener oder gelöschter Daten verschwinden nach einiger Zeit).
Ein Backup sollte regelmäßig und automatisiert erfolgen.
Bei Änderungen von Dateien werden - in der Regel - nur die geänderten Dateien übertragen (inkrementelles Backup), was die übertragene Datenmenge minimiert.

Eine Archivierung dient der längerfristigen Sicherung Ihrer Daten im Zustand zu einem bestimmten Zeitpunkt.
Eine Archivierung wird in der Regel manuell bei Bedarf durchgeführt.
Jedes Archiv steht für sich selbst: werden dieselben Daten erneut archiviert, werden auch alle erneut übertragen!
Die Verwaltung der Archive erfolgt ausschließlich durch den Kunden: serverseitig passiert hier gar nichts - mit der (einzigen) Ausnahme des Löschens von Archiven nach Erreichen der maximalen Aufbewahrungszeit.

Zur Archiv-Verwaltung gehört auch eine möglichst kluge Benennung der Archive ("Metadatenverwaltung"): damit auch nach einiger Zeit noch klar ist, was sich eigentlich darin befindet...
Dies ist bei Backups unproblematischer, da diese ja eine existierende sowie aktiv genutzte - und damit vertraute - Verzeichnisstruktur abbilden.

InclExcl-Regeln korrekt zu erstellen, ist nicht einfach; ein erster Hinweis: Regeln in einer InclExcl-Datei oder auch direkt in dsm.opt (Windows) oder dsm.sys (Linux), werden von unten nach oben abgearbeitet, wobei exclude.dir-Regeln alle include-Regeln überlagern (also zuerst abgearbeitet werden).

Das Kommando
  dsmc q inclexcl
zeigt die Regeln in der Abarbeitungsreihenfolge - also andersherum - an (und noch ein paar zusätzliche Regeln vom SP-Server).

Leider fehlt jedoch eine include.dir-Regel, mit der man gezielt Verzeichnisbäume sichern könnte, indem man danach alle anderen Verzeichnisse darüber und daneben ausschlösse.

Was ist zu tun, wenn beispielsweise nur
  /home/ (Linux) oder
  c:\Users\ (Windows)
gesichert werden sollen?

Linux

• dsm.sys:

  VirtualMountpoint /home

• dsm.sys (or dsm.opt):
  

  Domain /home

Approach could be extended to more directories.

Windows

There is no SP VirtualMountpoint, but the Windows 'subst' command (see
  subst | Microsoft Learn
) for creating drive letters suited asDomain arguments.

• Map some directory to a fixed drive letter - e.g. 'k:' -;
  in some script:

  subst k: c:\Users

• change domain from (default) 'all-local' to 'k:';
  in dsm.opt:
  

  Domain k:
  

This should backup c:\Usersdirectory tree only.

Approach could be extended to more directories / drive letters.

ManagedServices schedule

ist die typische Einstellung in der Konfiguration des Backup-Clients; 'webclient' sollte hier - schon aus Sicherheitsgründen - nicht auftauchen.

Die Archiv-Funktion von Spectrum Protect (früher TSM genannt) stellt — auch wegen ihrer Plattformgebundenheit — keine Langzeitarchivierung dar, welche gesetzlichen Vorgaben entsprechen würde!

Archive werden ausschließlich vom Kunden verwaltet; dies bedeutet, dass er damit rechnen muss bei etwaigen Änderungen des Datensicherung-Services aktiv werden zu müssen:

• Bei einer - nach Vorankündigung möglichen - Umstellung des Datensicherung-Services auf eine andere Hard- und/oder Software ist prinzipiell der Kunde dafür verantwortlich, Archive vom alten auf das neue System zu migrieren; für diesen Zweck gibt es dann eine Übergangsphase, in der Archive aus dem alten System lokal beim Kunden wiederhergestellt werden müssen, bevor es abgeschaltet wird.
  
  • Damit die Vorankündigung einer solchen Umstellung ankommt, muss die für den Archiv-Knoten verantwortliche Person erreichbar sein.
  • Um von einem alten auf ein neues System zu migrieren, muss der Kunde in der Übergangsphase in der Lage sein, die auf dem alten System gespeicherten Archive lokal (bei sich) temporär wiederherzustellen, um sie dann - sofort oder später - auf dem neuen System erneut zu archivieren. Dies benötigt einen mit dem abzuschaltenden System arbeitenden Client-Archiv-Knoten - Rechner, Software und Konfiguration - beim Kunden! Dies kann problematisch sein, wenn schon lange kein Archiv mehr geschrieben oder wiederhergestellt wurde...
• Es ist nicht völlig auszuschließen, dass der Datensicherung-Service auch einmal eingestellt wird (ganz oder nur für Archive): in diesem Fall wäre der Kunde dafür verantwortlich, Archive aus dem abzuschaltenden System lokal bei sich wiederherzustellen, bevor sie Server-seitig unwiderruflich gelöscht werden.

Bei der letzten großen Systemumstellung 2014 konnten Archive nichtsdestotrotz Server-seitig vom alten in das neue System migriert werden (was insbesonders bei großen Datenmengen sinnvoll ist); dies wurde damals von Hermann Frasch (inzwischen in Rente) bewerkstelligt.
Dass ein solches Vorgehen auch in Zukunft möglich ist, kann jedoch nicht garantiert werden.

Bei Archiven gibt es diesen zugeordnete unterschiedliche Managementklassen, welche unterschiedlichen Aufbewahrungszeiten entsprechen.

Wird vom Client-Archiv-Knoten keine Management-Klasse ausgewählt, gilt "STANDARD" mit 1 Jahr Speicherzeit; es kann jedoch auch eine andere Management-Klasse gewählt werden.

Nach Erreichen der Speicherzeit einer Management-Klasse werden die dieser zugeordneten Archive automatisch gelöscht.

Wenn die Management-Klasse nicht über das Client-GUI ausgewählt werden soll, gibt es außerdem noch folgende Möglichkeiten:

• 'archmc'-Kommandozeilen-Option (leider nicht setzbar als Option in Konfigurationsdatei):
    Archmc - IBM Documentation
    https://www.ibm.com/docs/en/spectrum-protect/8.1.12?topic=reference-archmc
  Diese Variante ist am wenigsten fehleranfällig.
• 'include.archive' als Teil einer inclexcl-Liste:
    Include options - IBM Documentation
    https://www.ibm.com/docs/en/spectrum-protect/8.1.12?topic=reference-include-options
  Diese Variante birgt die Gefahr, dass bei nicht passenden Mustern die Management-Klasse nicht wie gewünscht eingestellt wird.

Jede dieser Varianten sollte vor einem produktiven Einsatz getestet werden:

• Dazu gehören sinnvollerweise auch Restore-Tests.
• Aufräumen ist dabei unproblematisch: Test- und andere Archivierungen können vom Client aus gelöscht werden.

Ja:
Archiv-Dateien sind zwar - wie Backup-Dateien auch - an den jeweiligen Filespace gebunden, können und sollen (!) jedoch - im Gegensatz zu Backup-Dateien - von dem/der Benutzer/in gezielt gelöscht werden (auf dem Archiv-SP-Server).

Zur Motivation gezielten Löschens:
Da die im Archiv liegenden Dateien vom SP-Server nicht in einen Prozess der Versionierung einbezogen sind und dadurch bei erneuter Erstellung eines Archivs mit - ganz oder teils - denselben Dateien nicht über Expiration älterer Versionen automatisch gelöscht werden, ist der/die Benutzer/in für das Löschen überflüssiger oder veralteter Archiv-Dateien selbst verantwortlich. Tut er/sie das nicht, bleiben alle jemals archivierten Dateien bis zum Erreichen ihrer maximalen Aufbewahrungszeit erhalten (bestimmt durch die Management-Klasse), und werden erst dann automatisch gelöscht. Im Unterschied zu - inkrementellen - Backups können bei ungeschicktem Vorgehen bei Archiven dadurch sehr große Mengen veralteter Daten anfallen.

Das Löschen einzelner Archiv-Dateien kann

1. im Backup-Archive Command Line-Interface (dsmc) durch Eingabe des Befehls
     delete archive
   und der Angabe der Datei-Spezifikation(en); oder
2. im graphischen Interface (dsmj) über
     -> Menü Dienstprogramme/Utilities
     -> Archivierungsdaten löschen/Delete Archive Data
       -> <Auswahl der zu löschenden Dateien>
   durchgeführt werden.
   Filespaces mit archivierten Daten können mit dem Befehl
     delete filespace
   , bzw. im GUI über
     -> Menü Dienstprogramme/Utilities
     -> Dateibereiche löschen/Delete Filespaces
   als Ganzes gelöscht werden.

Zur Syntax und Anwendung des delete archive-Befehls siehe unsere TSM-Einführung (Seite 37.) bzw. eines der plattformspezifischen Online-Handbücher beim IBM Knowledge Center (Kapitel "Using commands").

Bitte vor dem Löschen einer großen Anzahl von Dateien beachten

Sollen sehr viele Archivdateien innerhalb eines Filespaces oder Filespaces mit vielen Archivdateien als Ganzes gelöscht werden, bitten wir dringend darum,

• dies uns vor dem eigenen Löschen per Email mitzuteilen, sowie
• das Löschen ganzer Filespaces mit vielen Archivdateien uns zu überlassen,

um mögliche schwerwiegende Störungen des laufenden Server-Betriebs zu vermeiden!
Dabei wäre es sehr hilfreich, wenn von uns zu löschende Filespaces zeilenweise in der Form
  NODE_NAME Filespace_Name
, bzw. bei Windows-Systemen im Falle von Unicode-Filespaces (Abfrage in der Befehlszeile "dsmc" mit:
  query filespace -detail
) in der Form
  NODE_NAME Fsid
aufgelistet würden.

Erscheinen in dsmerror.log Fehlermeldungen bezüglich eines ungültigen Zeichensatzes, wie bspw. '... contains one or more unrecognized characters and is not valid.' (o.ä.) werden die betreffenden Dateien nicht gesichert (oder auch restauriert).

Die hiesige Dokumentation hierzu (zu finden in PDF unter "Warum werden auf meinem Rechner Verzeichnisse und Dateien mit Umlauten im Namen nicht gesichert/archiviert/restauriert/abgerufen?") ist leider veraltet.

Linux-Client-Installationsskripte

Es gibt jedoch Linux-Client-Installationsskripte (bei uns intern im Einsatz), welche den aktuellen Linux-Client installieren und dabei funktionierende Zeichensatz- und andere sinnvolle Einstellungen vornehmen. Diese erhalten Sie für unterschiedliche Linuxe über
  Wo erhalte ich den aktuellen Client?
.

1. Bitte überprüfen Sie die Datei  dsmwebcl.log: dort sollten sich Hinweise auf das Problem finden lassen. Bitte beachten Sie dabei auch die Zeitstempel (läuft der Service überhaupt?).
2. Finden Sie in dsmwebcl.log eine Meldung wie "(dsmcad) Dsmcad is working in Webclient mode", ersetzen Sie in Ihrer Konfigurationsdatei ManagedServices WebClient durch ManagedServices Schedule (nur diese eine Option sollte gesetzt sein), und starten Sie danach Ihren Scheduler-Service neu.
   
   IBM-Doku: 'You can set this option on the Web Client tab of the Preferences editor.'
   
   Überprüfen Sie das Resultat bitte in dsmwebcl.log; dort müssten sich nach Restart des Scheduler-Service aktuelle Einträge finden.

1. Bei Verwaltung "Persönlich" hat nur der/die Antragstellende Zugriff auf den entsprechenden Datensicherungs-Knoten: sicherheitsrelevante Anfragen  - beispielsweise eine Passwort-Zurücksetzung  - werden nur bearbeitet, wenn sie nachvollziehbar von ihm/ihr kommen (beispielsweise von einer dienstlichen Email-Adresse aus).
2. Bei Verwaltung "Backup-Administratoren-Gruppe (nach UniAdmin-Portal)" ist die Gruppe der verantwortlichen Personen über die Rolle Backup-Administrator im UniAdmin-Portal definiert. Jede/r Admin mit dieser Rolle kann sicherheitsrelevante Änderungen bewirken.
   Die antragstellende Person ist dann typischerweise der/die Haupt-Ansprechpartner/in, die vorzugsweise von uns kontaktiert werden kann, falls technische Probleme auftreten (alle als Backup-Admins Definierten haben jedoch gleichermaßen *dieselben* Rechte).
   
   Diese Variante eignet sich gut für eine vom jeweiligen Institut vorgenommene selbständige Verwaltung von Zugriffsrechten, um beispielsweise Urlaubsvertretungen einfach zu ermöglichen.
   Voraussetzung dafür ist eine Funktions-Emailadresse, über die alle Backup-Administratoren (Rolle nach UniAdmin-Portal) erreicht werden können.

• Ein Low-level-Restore von Backup-Server auf lokale Festplatte/n unter Umgehung der Filesystem-Struktur ist nicht möglich.
• Ein 'bare-metal restore' ist mit Spectrum Protect (SP)-"Bordmitteln" ebenfalls nicht möglich.

Das Vorgehen in etwa:

1. Installation eines Betriebssystems auf der neuen Hardware: hierbei ist zu beachten, dass es mit dem Betriebssystem, von dem aus das Backup vorgenommen wurde, kompatibel sein muss; beispielsweise geht ein Restore von unter Windows gesicherten Dateien unter Linux nicht!
2. Ticket mit Anforderung der Zurücksetzung des Passworts nebst Bemerkung, dass es sich um eine Neuinstallation handelt (dann muss nämlich auch eine einmalige (!) erneute Zertifikatsübertragung von Spectrum Protect-Server zu -Client zugelassen werden).
3. Installation eines aktuellen SP-Clients nebst Konfiguration (Backup-Servername, PW): die Abwärtskompatibilität ist in der Regel gegeben; daher sollte ein aktueller Client installiert werden.
4. Restore mit großer Vorsicht, damit nicht aus Versehen das (neue) BS oder andere Dinge überschrieben wird/werden: dabei sollte die Wiederherstellung von Nutzerdaten im Vordergrund stehen.
   Bei einem Restore Betriebssystem-naher Dateien ist besondere Vorsicht geboten: es sollte vor einem solchen Versuch unbedingt die Frage "Ist das wirklich sinnvoll?" gestellt werden.
5. Wenn die verlorenen Daten wieder da sind (vermutlich Nutzerdaten), gegebenenfalls Herstellen der gewünschten Verzeichnisstruktur.
6. Konfiguration der inclexcl-Regeln des Backup-Clients. Hier kann "dsmc q inclexcl" helfen.
7. Manuell angestoßenes Backup; gegebenenfalls Ticket zum Löschen von Filespace-Artefakten aus Tests (beispielsweise mit Testverzeichnissen) davor bzw. nicht korrekt verlaufenden Versuchen manueller Backups.
   Anmerkung: Das erste "richtige" Backup kann mehr oder weniger zu einem Full-Backup führen (insbesonders bei Änderungen der Verzeichnisstruktur).
8. Überprüfen, welche Filespaces nun Artefakte aus dem alten System sind, nebst Ticket zur Löschung derselben.
9. Starten des dsmcad Services.

Die Nichtnutzung des Schedulings hat Konsequenzen:

• Sie bekommen keine Nachrichten bezüglich nicht eingehaltener Schedules: läuft also gar kein Backup, bekommen Sie dies nicht vom Backup-Server mitgeteilt.
• Bei Wartungen findet eine Betriebsunterbrechung möglichst außerhalb der Schedule-Zeiten statt. Abweichende Zeiten von durch Client-Skripte angestoßenen Backups können hier nicht berücksichtigt werden (daher wäre es schonmal sinnvoll, ein derartiges Skript nachts laufen zu lassen).
• Bei Schedules verteilt der Backup-Server den Start der Backups (im Zusammenspiel mit dem Scheduler-Service) so, dass die Last möglichst ausgeglichen verteilt wird; von Backup-startenden Skripten beim Client-Rechner "weiß" er jedoch nichts: hier könnten Performanz-Probleme dann auftauchen, wenn zuviele Backups (für mehrere Backup-Knoten/Clients) skriptgesteuert auf einmal gestartet werden.
  Zur Zeit gibt es nur wenige Kunden mit skriptgesteuerten Backups; bei Zunahme wir können diesbezügliche Schwierigkeiten jedoch nicht ausschließen.