ALIs

kommt noch

FAQ

FAQ - Häufig gestellte Fragen

  • Warum sehe ich keine oder nicht alle in TSM abgelegten Dateien?

    Dafür sind die verschiedensten Ursachen möglich. Die häufigsten sind:

    • Eine archivierte Datei wird als Backup-Datei gesucht oder umgekehrt.
    • Die Datei ist, oft durch Verwendung eines symbolischen Links, unter einem anderen Namen gespeichert worden als dem, unter dem sie gesucht wird.
    • Die Datei liegt in einem anderen "File Space".
    • Die Datei ist durchaus sichtbar, aber nicht in dem kleinen Fenster links in der graphischen Benutzeroberfläche, sondern weiter rechts im verdeckten Teil.
    • Wenn auf dem Rechner mehrere Nodes installiert sind, kann es auch sein, dass man eine Verbindung unter dem falschen Node aufgebaut hat. Dieser Fall tritt vor allem dann auf, wenn von einer Maschine aus mehrere Nodes verwendet werden. An institutseigenen Rechnern ist diese Konfiguration relativ selten, so dass man erst andere Fehlermöglichkeiten auszuschließen sollte, bevor man in dieser Richtung sucht.
    • Der schlimmste Fall: alles hat seine Richtigkeit. Die Datei wurde nie gesichert oder archiviert oder die Dateikopie wurde gelöscht.
  • Wie groß sollten die Dateien sein, die ich nach TSM stecke?

    Prinzipiell erlaubt TSM beliebige Dateigrößen. In der Praxis ist eine gewisse Mindestgröße zumindest für die Archivierung (beim Backup hat man auf die Dateigrößen kaum Einfluss) empfehlenswert. Idealerweise sollten die Dateien hier größer als einige hundert Kilobyte sein. Die Archivierung von wenigen hundert Dateien, die kleiner als 100 KB sind, ist auch kein Problem. Nur bei größeren Mengen kleiner Dateien sollte man diese vorher im tar-Format bzw. als ZIP-Datei packen.

  • Wie lange werden meine Daten aufbewahrt?

    Die hier angegebenen Werte sind die vom LRZ gesetzten Voreinstellungen. Mit dem Kommando "dsmc q mgmt -det" kann man sich die entsprechenden Parameter selbst anzeigen lassen. Grundsätzlich muß man zwischen archivierten und gesicherten Daten unterscheiden. Die Aufbewahrungsdauer ist auch in den TSM-Richtlinien beschrieben.

    Bei Archiv-Daten ist die Regel einfach: sie werden am LRZ per Voreinstellung 10 Jahre aufbewahrt (Parameter: Retain Version).

    Bei Backup-Daten ist die Sache komplizierter: Insgesamt werden am LRZ von jeder Datei bis zu 3 Versionen aufbewahrt (Parameter: Versions Data Exists). Die inaktiven Versionen einer Datei werden nach 6 Monaten gelöscht (Parameter: Retain Extra Versions, Retain Only Version), aktive Versionen werden nie gelöscht.

    Wenn Sie andere Anforderungen haben, wenden Sie sich an die Ansprechpartner am LRZ, indem Sie Ihr Anliegen in einem Incident im LRZ-Servicedesk-Portal formulieren.

  • Woher kommen alle diese Dateien "dsmerror.log" in vielen meiner Verzeichnisse?

    Der TSM-Unix-Client gibt Fehlermeldungen auf "stderr" aus und schreibt sie gleichzeitig in eine Datei namens "dsmerror.log" im aktuellen Directory geschrieben. Um zu erreichen, dass dieses File immer am gleichen Ort abgelegt wird, setzt man die Variable "DSM_LOG", z.B.

       DSM_LOG=$HOME; export DSM_LOG
    (Bourne-Shell)

    bzw.

       setenv DSM_LOG $HOME
    (C-Shell)
  • Was bedeutet diese Fehlermeldung: "ANS4503E Valid password not available for server ..."?

    Der Zugriff auf einen TSM-Server ist stets passwortgeschützt, in manchen Fällen aber so, dass es dem Endbenutzer gar nicht bewusst wird, weil das Passwort an seinem Rechner verschlüsselt in einer Datei liegt. Die obige Fehlermeldung tritt nun auf, wenn diese Datei fehlt oder ein falsches Passwort enthält. Als Endbenutzer kann man in diesem Fall gar nichts tun; man informiert seinen lokalen Administrator über den Fehler. Dieser kann das Passwort neu ablegen. Dies geschieht durch einen simplen Verbindungsaufbau zum Server, z.B. durch ein

     dsmc q mgmt
  • Wer sind die Ansprechpartner für TSM am LRZ?/

    Richten Sie Anfragen bitte an den zentralen LRZ-Servicedesk. Dort stehen auch Vorlagen zur Verfügung, mit denen Sie häufig auftauchende Anfragen einfach stellen können (z.B. Nodes löschen, Passwort zurücksetzen, Löschberechtigung erteilen).

  • Wie kann ich als Administrator steuern, wo das Schedulelogfile angelegt wird?

    Unter Unix durch einen Eintrag in "dsm.sys", unter Windows in "dsm.opt", z.B:

       schedlogname /tmp/dsmsched.log

    Der Scheduler muss neu gestartet werden, um die Änderung mitzubekommen.

  • Wie kann ich die Größe des Schedulelogfiles beschränken?

    Unter Unix durch einen Eintrag in "dsm.sys", unter Windows in "dsm.opt", z.B:

       schedlogretention 14 [S]

    Durch diese Zeile werden die Einträge im Schedlog auf die letzten 14 Tage beschränkt. Durch die zusätzliche Angabe "S" in der Zeile werden die gelöschten Einträge nach "dsmsched.pru" geschrieben.

  • Wie kann ich als Administrator steuern, wer TSM benutzen darf?

    Unter Unix durch einen Eintrag in "dsm.sys", unter Windows in "dsm.opt", z.B:

       users maier mueller schneider

    wird der Zugriff auf TSM auf die Benutzer "maier", "mueller" und "schneider" beschränkt. Analog dazu kann man auch Gruppen eintragen, siehe Manual.

    Fehlt solch ein Eintrag, so kann jeder Benutzer der Workstation TSM für seine Dateien verwenden.

  • Wie kann ich die Filesysteme/Laufwerke bestimmen, die gesichert werden sollen?

    Durch die explizite Angabe der Mountpoints/Laufwerke beim Aufruf, also z.B.

       dsmc incr -domain="/ /usr /home"

    oder besser durch einen Eintrag in "dsm.opt":

       domain / /usr /home

    Ohne diese Angaben werden alle lokalen Filesysteme ohne "/tmp" gesichert. Analoges gilt für die Laufwerke und Verzeichnisse unter Windows.

  • Wie kann ich einzelne Files oder Subdirectories von der Sicherung ausschließen?

    Durch einen Eintrag in die Datei "inclexcl", z.B.

       exclude /unix

    In der Datei "dsm.sys" wird festgelegt, wo die Datei "inclexcl" steht.

    Unter Windows stehen die Einträge direkt in der Datei "dsm.opt". Siehe auch Online-Manual.

  • Wie kann ich sicherstellen, dass der Scheduler immer läuft?

    Unter Unix durch den automatischen Start beim Booten der Workstation entweder durch die Aufnahme des Startbefehls (s.o.) in ein rc-File oder den Eintrag in der Datei "/etc/inittab":

       TSM::once:/usr/TSM/dsmc sched > /dev/null 2>&1

    Unter Windows wird der entsprechende Dienst so konfiguriert, dass er beim Reboot des Rechners automatisch gestartet wird.

  • Was tun bei "ANS4219E NODENAME cannot be the same as HostName"?

    Diese Meldung erscheint, wenn man in der Datei "dsm.opt" einen Eintrag der Art "nodename xyz" hat, wobei "xyz" der Rechnername ist. Wenn der Nodename gleich dem Rechnernamen ist, ist ein solcher Eintrag in "dsm.opt" nicht nur nicht notwendig, er führt auch zu der obigen Fehlermeldung und muss daher entfernt werden.

  • Muss meine IP-Adresse am LRZ registriert werden?

    Da ein Verbindungsaufbau zum TSM-Server immer vom Client ausgeht, muss der Server, sprich das LRZ, für die Registrierung auch keine IP-Adresse wissen.

  • Wozu braucht man die Kommandos "dsmadm" und "dsmadmc"?

    Als normaler Anwender gar nicht. Mit ihrer Hilfe wird der Server administriert. Wer wenig Platz auf seinem Rechner hat, kann diese Kommandos auch löschen bzw. die entsprechenden Pakete (TSM Administrative Client) erst gar nicht installieren.

  • Ist Archivierung das gleiche wie Backup?

    TSM behandelt gesicherte und archivierte Datein völlig getrennt. Es ist also sinnlos, eine gesicherte Datei mit "dsmc retrieve" oder eine archivierte Datei mit "dsmc restore" zurückbekommen zu wollen, und es ist nicht möglich, sich mit nur einem Kommando eine Liste aller seiner Dateien ausgeben zu lassen, die sowohl die archivierten wie die gesicherten Dateien enthält.

    Neben den zahlreichen Ähnlichkeiten gibt es auch deutliche funktionale Unterschiede zwischen Sicherung und Archivierung:

    • Von einer Version einer gesicherten Datei hebt ADSM in aller Regel nur ein Exemplar auf, möglicherweise aus Sicherheitsgründen in mehreren physischen Kopien (was aber für den Benutzer nicht sichtbar ist). Eine archivierte Datei wird so oft getrennt aufbewahrt, wie sie archiviert wurde.

    • Die Archivkopie einer Datei kann einzeln gelöscht werden; ein Kommando zum Löschen einzelner Backup-Dateien gibt es nicht.

    • Den Begriff einer "aktiven" Version einer Datei gibt es nur beim Backup, und nur dort hat das Verändern oder Löschen der Ausgangsdatei einen Einfluss; auf die Lebensdauer der Konserve. Archivierte Dateien führen dagegen ein Eigenleben unabhängig von dem der Ausgangsdateien.

  • Was geschieht mit symbolischen Links?

    Symbolische Links, wie sie in Unix-Dateisystemen verwendet werden, werden bei Backup und Archivierung verschieden behandelt:

    Beim Backup werden symbolische Links nicht aufgelöst. Wird die Datei restauriert, so entsteht wieder ein symbolischer Link, der auf denselben Dateipfad verweist wie vorher. Es ist nicht möglich, einem symbolischen Link auf ein Verzeichnis zu folgen, um innerhalb von TSM eine Datei aufzusuchen.

    Bei der Archivierung werden symbolische Links aufgelöst. Es entsteht also eine Archivdatei mit dem Pfadnamen, den der symbolische Link hatte und dem Inhalt, den zum Zeitpunkt der Archivierung die Datei hatte, auf den der Link zeigt. Man kann das positiv nutzen, um der Archivdatei einen bestimmten Namen zu geben, es kann sich aber auch als lästig erweisen, wenn eine Datei mehrere Namen hatte und nicht mehr bekannt ist, unter welchem sie archiviert wurde. In dem Sonderfall, dass ein ungültiger Link (Ziel nicht (mehr) vorhanden) archiviert wird, sichert TSM nur den entsprechenden Link.

    In beiden Fällen kann diese Behandlung symbolischer Links dazu führen, dass Dateien spurlos verschwunden zu sein scheinen, wenn sie unter einem anderen Namen gesucht werden als sie angelegt wurden. Beim Backup, der ja in der Regel automatisch und regelmäßig erfolgt, ist der "richtige" Name immer der, der keinen Link enthält; bei der Archivierung hingegen der, der beim Archivierungsvorgang tatsächlich verwendet wurde.

  • Ist ein File Space das gleiche wie ein Filesystem?

    Meistens, aber nicht immer. TSM unterteilt die Menge der für einen Node gespeicherten Dateien in File Spaces, die völlig getrennt voneinander verwaltet werden. Die Option "subdir=yes" bedeutet also genauso genommen nicht die Hinzunahme aller Unterverzeichnisse, sondern nur derjenigen, die im gleichen File Space liegen. Die Grenzen der File Spaces werden dabei zunächst durch die Konfiguration der Dateisysteme auf den Ausgangsrechnern bestimmt (auf Unix-Systemen etwa durch die Grenzen der Filesysteme, unter Windows durch die Laufwerke). Jeder Client-Administrator kann aber auch die Definition so genannter virtueller Mountpoints neue Grenzen und damit neue Filespaces schaffen.

    Man muss sich daher darüber im klaren ist, dass für TSM die Welt an der File-Space-Grenze zu Ende ist. Man kann sich daher in aller Regel nicht über alle seine Dateien informieren, indem man unter Angabe von "-subdir=yes" nach "/*" sucht; vielmehr muss diese Suche für jeden File Space gesondert durchgeführt werden.

    Ein exotisches, aber dafür umso heimtückischeres Problem tritt auf, wenn Dateien im falschen File Space gelandet sind, etwa wie folgt:

    1. Der File Space "/a" wird eingerichtet.
    2. Die Datei "/a/b/c" wird archiviert und landet im File Space "/a".
    3. Der File Space "/a/b" wird eingerichtet.
    4. Die Datei "/a/b/c" wird gesucht, und zwar im File Space "/a/b", und folgerichtigerweise nicht gefunden. In diesem Fall hätte man explizit nach "{/a/}b/c" suchen müssen.

    Für die Verfolgung solcher Probleme braucht man eine Liste der File Spaces, die man mit dem Kommando "dsmc q filespace" erhält.

  • Wie werden AFS-Dateien gesichert?

    Für die Sicherung und Restauration von Dateien auf institutseigenen Rechnern hat dieser Abschnitt nur dann Bedeutung, wenn dort ein AFS-Dateisystem betrieben wird, was eher selten der Fall ist.

    Das verteilte Dateisystem AFS hat seine eigenen Mechanismen zur Dateisicherung. Dadurch wird einerseits erreicht, dass über die Dateiinhalte hinaus Informationen wie Zugriffsrechte und Kontingente gesichert und restauriert werden können, und andererseits, dass der Lesezugriff bei der Sicherung nicht unkontrolliert mit gleichzeitigen Schreibzugriffen kollidiert. Im Zusammenhang mit TSM gibt es nun die folgenden Möglichkeiten:

    • Man sichert mit TSM und verzichtet auf die AFS-Sicherung. Die Verwaltungsinformationen des Dateisystems müssen dann durch zusätzliche Maßnahmen gesichert werden.
    • Man sichert mit Hilfe der AFS-Sicherung und benutzt TSM lediglich zur Aufbewahrung der so entstehenden Kopien. Da diese nicht mehr im Einflussbereich des einzelnen Benutzers liegen, hat dieser keine Möglichkeit, selbst eine Restauration anzustoßen.
    • Man betreibt beide Sicherungen parallel. Damit sind die Daten selbst zweimal gesichert.

    Am LRZ ist anfangs der dritte Weg beschritten worden. Da die einzeln gesicherten Dateien spürbar zum Volumen und drastisch zur Anzahl gesicherter Dateien (Datenbankgröße) beitragen, aber nur sehr selten vom Endbenutzer zur Restauration verwendet wurden, werden jetzt die Dateien auf den LRZ-eigenen Rechnern nur noch der AFS- bzw. DFS-Sicherung unterzogen. Der Benutzer kann also diese Dateien nicht selbst restaurieren, sondern mus sich gegebenenfalls an das LRZ wenden, um eine Datei wiederzuerlangen.

  • Wie müssen unter Unix die Zugriffsrechte gesetzt sein?

    Sofern die Installationsprozedur nicht schon selbst für korrekte Zugriffsrechte sorgt, werden folgende Einstellungen empfohlen: 755 oder rwxr-xr-x für Verzeichnisse und ausführbare Dateien, 644 oder rw-r--r-- sonst). Eine Ausnahme bildet lediglich die Datei dsmtca. Sie muss root gehören und mit einem s-Bit versehen sein (etwa durch die Maske 4755 bzw. rwsr-xr-x).

  • Kann ich unter Unix die Konfigurationsdateien in ein eigenes Verzeichnis legen?

    Um die Übersichtlichkeit zu erhöhen kann der Unix-Administrator alle Konfigurationsdateien in ein eigenes Verzeichnis legen, etwa /usr/local/adsm/etc. Im Installationsverzeichnis bleiben dann nur noch entsprechende symbolische Links, also etwa so:

       # mkdir -p /usr/local/adsm/etc
   # cd "Inst-dir"
   # ln -s /usr/local/adsm/etc .etc
   # mv dsm.sys /usr/local/adsm/etc
   # mv dsm.opt /usr/local/adsm/etc
   # ln -s .etc/dsm.sys dsm.sys
   # ln -s .etc/dsm.opt dsm.opt


  • Was bedeutet die Meldung client is down level?

    In älteren TSM-Releases konnten Nodes im Prinzip von mehreren Klienten verschiedener Plattformen aus als sog. virtuelle Nodes genutzt werden. Dies galt als bedenkenlos, solange jede Klientel (z.B. Unix, Windows, ...) nur auf die zu ihrer Plattform kompatiblen Filespaces zugriff, andernfalls verweigerte der Client den Zugriff oder machte auf eine Inkompatibilität aufmerksam.

    Diese Art der Nutzung von Sammlungen von Filespaces unterschiedlicher Typen unter dem Dach eines virtuellen Nodes funktioniert nicht mehr, sobald ein Windows NT TSM Client der Version 4.2 oder 5.1 so einen gemeinsam genutzten Node anfasst. In diesem Fall ist es Clients anderer Plattformen nicht mehr möglich, auf diesen Node zuzugreifen, sie werden vom Server wegen angeblicher Inkompatibilität abgewiesen werden.

    Als einzige Reparaturmethode hat sich bislang erwiesen, die gesamten Datenbestände eines betroffenen Nodes umzukopieren. Falls solche Nodes fortan von verschiedenen Clients aus benutzt werden sollen, kann dabei gleich eine geeignete Separierung der Daten erfolgen. Dieses Vorgehen kann jedoch nur bei nicht zu großen Nodes angewendet werden.

    Bislang noch nicht betroffenen gemeinsam von verschiedenen Plattformen genutzten Nodes sei dringend empfohlen, nicht mit Windows NT TSM Clients der Version 4.2 oder neuer zuzugreifen. Das gilt besonders dann, wenn neue Filespaces angelegt werden. Ältere Windows NT TSM und ADSM Clients sowie Clients anderer Plattformen als Windows NT gelten diesbezüglich als unbedenklich. Ferner soll der Fehler ab Release 5.1.5 behoben sein.

  • Wie kann ich das Passwort für meinen Node ändern?

    Mit dem Kommando "dsmc set password" kann das Node Passwort geändert werden.

  • Wie kann ich auf einen anderen Node als den default Node zugreifen?

    Um auf einen anderen Node zuzugreifen, sollte die Datei dsm.sys um die folgenden Zeilen ergänzt werden: 

    defaultserver        < Servername des default Nodes >   # Sollte in der ersten Zeile der dsm.sys stehen.
servername           < Frei wählbarer aber eindeutiger Name >
tcpserveraddress     < Name des TSM servers, von dem der Node verwaltet wird >
tcpport              < TSM server port >
nodename             < Name des Nodes >
    Auf Systemen mit einer dsm.opt Datei sollte diese noch um die folgende Zeile ergänzt werden: 
    servername           < Servername des default Nodes >
    Mit dem Kommando "dsmc -se=< Servername des nicht default Nodes >" können Sie dann auf den anderen Node zugreifen.

  • Wie kann ich auf einem UNIX-System einen TSM-Client betreiben, der nicht in das Default-Verzeichnis installiert wurde?

    Falls Sie ihren TSM-Client aus irgendwelchen Gründen nicht im default Verzeichnis installieren können gehen Sie wie folgt vor um den Client zu benutzen: Angenommen der TSM-Client wurde unter /usr/slocal/tsmclient/ installiert so müssen die nachfolgenden Umgebungsvariablen folgendermaßen gesetzt werden. 

    DSM_CONFIG=/usr/slocal/tsmclient/ba/bin/dsm.opt
BIN_DIR=/usr/slocal/tsmclient/ba/bin/
DSM_DIR=/usr/slocal/tsmclient/ba/bin/
LD_LIBRARY_PATH=/usr/slocal/tsmclient/ba/bin/:/usr/slocal/tsmclient/lib/:$LD_LIBRARY_PATH
    Alternativ zum exportieren der LD_LIBRARY_PATH Variable können Sie ihr System natürlich auch so Konfigurieren, dass in den entsprechenden Pfaden automatisch nach shared libraries gesucht wird (z.B. ld.so.conf unter Linux). Falls die LD_LIBRARY_PATH Variable nicht automatisch beim Starten einer Shell gesetzt wird, kann es sein dass die TSM Programme nicht richtig funktionieren (Besonders wenn Sie von einem unpriviligierten User aufgerufen werden). In diesem Fall muss entweder das System so konfiguriert werden, dass die LD_LIBRARY_PATH Variable automatisch beim starten einer neuen Shell gesetzt wird oder mindestens der Pfad /usr/slocal/tsmclient/lib/ als shared library Verzeichnis konfiguriert werden (ld.so.conf oder entspr. Mechanismen).

  • Was muss ich tun damit unter Unix/Linux Files mit Umlauten im Namen richtig gebackupt werden können?

    Damit TSM Dateien mit Umlauten im Dateinamen sichern kann, müssen diese Dateinamen im Zeichenstaz ISO-8859-15 angelegt worden sein. Dazu müssen mindestens die Umgebungsvariablen LANG und LC_CTYPE per default auf den Wert de_DE@euro gesetzt werden. Falls Sie File Sharing über Samba oder ähnliches betreiben müssen Sie auch dort über die entspechenden Konfigurationsmechanismen den Zeichensatz auf ISO-8859-15 einschränken. Bitte beachten Sie dass in der derzeitigen TSM Client Version (5.3.4) noch keinerlei Unterstützung für Unicode Zeichensätze (UTF-8) enthalten ist und somit die Konfiguration aller Linux Installationen, welche standardmäßig UTF-8 als Zeichensatz verwenden, wie oben beschrieben angepasst werden muss.

  • Warum läuft der TSM Client für MAC OS nicht auf meinem Intel basierten Apple Computer?

    Sie verwenden wahrscheinlich eine zu alte TSM Version. Intel Mac's werden erst ab TSM Version 5.4.1.2 korrekt unterstützt.

  • Ich habe vergessen auf welchem TSM Server mein Node registriert wurde. Was mache ich jetzt?

    Loggen Sie sich mit Ihrer TSM Administratorkennung hier ein.
    Wählen Sie anschließend das Icon "Nodes" aus und klicken daraufhin auf den entsprechenden Nodenamen. Auf der rechten Seite sehen Sie nun den Namen des TSM Servers auf dem Ihr Node registriert ist.

  • Ich habe vergessen an welchem TCP Port der TSM Server, auf dem mein Node registriert wurde, lauscht. Was mache ich jetzt?

    Loggen Sie sich mit Ihrer TSM Administratorkennung hier ein.
    Wählen Sie nun das Icon "Configuration" aus. Nun sehen Sie eine Liste aller TSM Server mit den entsprechenden Informationen für TCP Server Address und TCP Port.

  • Kann ich auf einen TSM-Node von verschiedenen Betriebssystemen aus zugreifen?

    Nein. Falls man zum Beispiel mit einem Rechner unter Windows auf einen Knoten zugreift, der normalerweise von einem Unix-Rechner benutzt wird, wird der nächste Zugriff des Unix-Rechners mit einer Fehlermeldung fehlschlagen. Dies gilt in allen möglichen Kombinationen wie zum Beispiel: Windows - MacOS, MacOS - Windows, Unix - MacOS, etc..

  • Ist es möglich, die Dateien mit TSM verschlüsselt abzulegen oder zu übertragen?

    Eine verschlüsselte Übertragung der Dateien mit SSL bietet das LRZ derzeit nicht an.

    Es ist allerdings möglich, Dateien verschlüsselt abzulegen. Für welche Dateien dies passieren soll, können Sie mit der Option include.encrypt in der Datei dsm.sys (für Unix/Linux) bzw. dsm.opt (Windows) festlegen. Mit der Option encryptkey save|prompt|generate kann festgelegt werden, ob das Passwort auf dem Client gespeichert wird, bei jedem Vorgang abgefragt, oder automatisch erzeugt und auf dem Server abgelegt wird. Weitere Optionen finden Sie in den Hersteller-Manualen.