Troubleshooting Guide

Einleitung

Dieser Ratgeber soll Ihnen helfen, Probleme und Fehler während des Setups, der Installation und während des normalen Betriebs Ihres SEP sesam Systems schnell zu erkennen und zu beheben. SEP sesam dient oft als Indikator dafür, dass es eine Änderung oder ein Ereignis gegeben hat, das die gesamte Systemleistung beeinflusst. Änderungen in der SEP sesam Sicherungsleistung werden oft durch Systemänderungen oder -ausfälle verursacht.

Erste Schritte

Um Probleme schnell und effizient zu lösen, machen Sie sich mit den allgemeinen Informationen zur Fehlerbehebung vertraut. Versuchen Sie, das Problem selbst zu identifizieren und zu beheben. Wenn Sie keine Lösung für Ihr Problem finden, melden Sie es an SEP sesam Support. Das Support-Team wird Ihnen dann weitere Anweisungen geben.

Identifizierung des Problems

Es ist wichtig, ein Problem so genau wie möglich zu bestimmen, damit die beste Lösung für das Problem gefunden werden kann. Beantworten Sie die folgenden Fragen, um das Problem, das bei Ihnen auftritt, zu identifizieren:

1. Wie lautete die Meldung oder der Fehler?
2. Wann ist der Fehler zum ersten Mal aufgetreten?
3. Tritt der Fehler immer nach einer bestimmten Aktion auf?
4. Tritt der Fehler immer zu einer bestimmten Zeit auf, z. B. morgens, abends usw.?
5. Welche Schritte sind erforderlich, um den Fehler zu reproduzieren?
6. Haben Sie irgendwelche Änderungen an Ihrer SEP sesam Umgebung vorgenommen, bevor der Fehler auftrat?

Übliche Probleme, die Sie selbst lösen können

Im Folgenden finden Sie eine Liste der häufigsten Probleme, die Sie selbst lösen können. Die meisten Fehler, auf die Sie wahrscheinlich stoßen werden, können durch Befolgen dieser Anweisungen gelöst werden.

• Prüfen Sie mit sm_main status, ob alle Prozesse laufen. Starten Sie ggf. den fehlenden Prozess mit sm_main reload neu.
• Sehen Sie sich das Tagesprotokoll an und suchen Sie nach Fehlern.
• Prüfen Sie, ob der Fehler durch einen Tageswechseltermin verursacht wurde. Sie können verhindern, dass der Tageswechsel laufende Aktivitäten abbricht, wie unter Tageswechseltermin beschrieben.
• Prüfen Sie, ob im Zeitplan ein Zeitrahmen festgelegt ist, nach dem das geplante Ereignis abgebrochen wird (Option Ausführung abbrechen nach...). Siehe Erstellen eines Zeitplans.
• Prüfen Sie die Protokolle für Sicherungen und Rücksicherungen.

Bevor Sie den Support kontaktieren

Bevor Sie sich an SEP sesam Support wenden, stellen Sie sicher, dass Sie alle Möglichkeiten ausgeschöpft haben, um das Problem selbst zu lösen. Führen Sie diese allgemeinen Überprüfungen durch:

1. Prüfen Sie, ob Ihr Problem im Leitfaden für Fehlermeldungen oder Leitfaden zur Fehlersuche beschrieben ist.
2. Stöbern Sie in den FAQ und schauen Sie im Forum.
3. Gehen Sie die obige Übliche Probleme, die Sie selbst lösen können Checkliste durch.
4. Sammeln Sie alle relevanten Daten über das Problem und senden Sie diese an SEP sesam support:
   • Fehlerausgabe
   • Nachrichten-ID
   • SEP sesam Version (Server, RDS und Client)
   • Betriebssystemumgebung
   • LOGs (wenn es ein Problem mit einem Sicherungsjob gibt, wählen Sie in der GUI Job Status -> Sicherungen -> Rechtsklick auf das betroffene Ergebnis und wählen Sie den untersten Menüpunkt Archiv mit allen Log-Dateien herunterladen -> Bitte senden Sie das erstellte Protokoll-Archiv mit). Bei Rücksicherung, Migration oder Replikation verfahren Sie analog.

Wie interpretiert man die Fehlermeldungen des Backup-Moduls von SEP sesam?

SEP sesam Sicherungsmodule sind so konzipiert, dass sie erweiterte Fehlermeldungen erzeugen, die Informationen aus 5 Schichten zurückgeben können: SBC - XBSA - FTP - SMS - Betriebssystem. SEP sesam scannt die Protokolldateien nach der Sicherung und Rücksicherung auf Warnungen und Fehler. Im Falle einer Warnung oder eines Fehlers wird die erste identifizierte Meldung in der Zusammenfassung am Ende des Protokolls ausgegeben.

Jedes Backupmodul nutzt die X/Open Backup Services API (XBSA) Standard. SEP sesam XBSA basiert auf einer FTP Implementierung. Das Backupmodul verbindet sich mit der FTPD Daemon Implementierung von SEP sesam - Sesam Transfer Protocol Daemon (STPD). Der Sesam Transfer Protocol Daemon (STPD) ist ein Dienst, der die Sicherungsdaten vom oder zum SMS Server anfordert und liefert und den Datenfluss zwischen dem SEP sesam Server und einem Client verwaltet. Während einer Rücksicherung empfängt der STPD die Daten vom SMS Server und sendet sie an den Client, der dann die Daten auf dem Zielsystem wiederherstellt. Der Sesam Multiplex Stream (SMS) ist ein Dienst, der die Sicherungsdaten vom STPD empfängt und die Daten auf die Sicherungsmedien schreibt. Während einer Rücksicherung liest er die Daten von den Sicherungsmedien und sendet sie an den STPD. Zusätzlich führt das Modul SEP sesam backup client (SBC) Sicherungs-, Migrations- und Rücksicherungsaufgaben aus. Der SBC sammelt und konsolidiert Sicherungsdaten auf dem Client-System und liefert sie an den STPD. Eine Liste aller SBC Meldungen (C Header Datei) ist hier zu finden: SBC Messages.

Eine Fehlermeldung setzt sich aus den Meldungen von der auslösenden Schicht bis zu den oberen Schichten zusammen. Wenn ein Betriebssystem einen Fehler meldet, werden der Fehlercode und die Betriebssystemmeldung zur SEP sesam Fehlermeldung hinzugefügt. Dadurch können Fehlermeldungen auch bei Problemen helfen, die nicht durch SEP sesam verursacht werden (z.B. Betriebssystemprobleme).

Typisches Sicherungsprotokoll

Das folgende Beispiel zeigt ein typisches Sicherungsprotokoll. Das Protokoll enthält 4 Bereiche: Über das Modul, Operations Parameter, Verarbeitung und eine Zusammenfassung.

2009-06-26 10:28:16: sbc-3036: Info:    # SESAM BACKUP CLIENT FOR Windows NT FILE SYSTEMS, VERSION: 3.2A17 Build
Revision: 1.257 (x64), Released: Jun 25 2009 #
2009-06-26 10:28:16: sbc-3063: Info:    -------------------- Operation Parameters --------------------
2009-06-26 10:28:16: sbc-3019: Info:    OS info:          Microsoft Windows Server 2008, Build: 6001 Service Pack 1 (x64)
2009-06-26 10:28:16: sbc-3100: Info:    Program PID:      42900
2009-06-26 10:28:16: sbc-3030: Info:    Operation:        BACKUP, Level: COPY
2009-06-26 10:28:16: sbc-3031: Info:    Storage Host:     qsbox3:11001,0-0:SESAM_SECURE_AUTHENTICATION:****
2009-06-26 10:28:16: sbc-3032: Info:    Control Host:     qsbox3:11001:SESAM_SECURE_AUTHENTICATION:*
2009-06-26 10:28:16: sbc-3040: Info:    Device:           SMS:disk1:SHARE:64
2009-06-26 10:28:16: sbc-3064: Info:    --------------------- Operation Messages ---------------------
2009-06-26 10:28:16: sbc-3002: Info:    Building file list from: [C:\SEPsesam\var\ini]
2009-06-26 10:28:16: sbc-3022: Info:    Command line ["sbc" "-b" "-C" "qsbox3:11001" "-S" "qsbox3:11001" "-l" "copy" "-s"
"SF20090626102812" "-d" "SMS:disk1" "-t" "weekly00001:1" "-j" "TEST_BACKUP" "-i" "job=TEST_BACKUP,nod=qsbox3,cmd=sbc,src=C/ /SEPsesam
/var/ini,ptf=WNT,typ=Path,exc=" "C:/SEPsesam/var/ini" ]
2009-06-26 10:28:16: sbc-3003: Info:    Opening saveset: SF20090626102812
2009-06-26 10:28:18: sbc-3104: Info:    Saveset info: [SEGMENT=3]
2009-06-26 10:28:18: sbc-3004: Info:    Begin writing to saveset...
2009-06-26 10:28:18: sbc-3074: Info:    Backup start time [20090626102818]
2009-06-26 10:28:18: sbc-3143: Info:    Starting with drive C:
2009-06-26 10:28:18: sbc-3006: Info:    Saveset size: 98304 bytes. Throughput: 189.820 MB/Hour.
2009-06-26 10:28:18: sbc-3005: Info:    Closing saveset.
2009-06-26 10:28:18: sbc-3052: Info:    Items processed correctly: [25]. Not processed or incorrectly processed items: [0].
2009-06-26 10:28:18: sbc-3007: Info:    Operation successful.
2009-06-26 10:28:19: sbc-3001: Info:    Exiting.

Zusammenfassung der Sicherungsfehler

Der Zusammenfassung der Fehlermeldung ist ein kurzer Informationsstring vorangestellt. Die vollständige Fehlermeldung setzt sich wie folgt zusammen:

{Status}/{Menge}/{Sicherungssatz ID}/{SBCStart}/{Meldung}

Die Bestandteile dieser Zeichenkette haben die folgenden Bedeutungen:

{Status}	{Menge}	{Sicherungssatz ID}	{SBCStart}	{Meldung}
0 - erfolgreich 1 - mit Warnungen 2 - leere LIS 3 - abgebrochen während der Sicherung C - abgebrochen vor der Datenübertragung X - misslungen	Datenmenge auf dem Medium	Automatisch generierte Sicherungssatz ID	Startzeit auf dem Client	Meldung über den Fehler

Das folgende Beispiel zeigt eine Zusammenfassung mit allen 5 Ebenen angeführt mit der gekürzten Informationskette.

X/0/SF20060629233007/20060629232907/Error: XBSA Call BSAEndData (closing saveset) failed:
System detected error, operation aborted. TRANSIENT or PERMANENT NEGATIVE reply:
553 STOR Failed. 1037: Writing data block on tape failed (23): Data error (cyclic redundancy check).
1039: Writing of Saveset Trailer failed.

Die Anzahl der Details, die für die Sicherung oder Rücksicherung zur Verfügung stehen, wird durch die Protokollebene definiert.

Einstellen der Protokollstufe

Sie können die Ausführlichkeit der Protokollierung mit der Protokollstufe (Log Level) ändern um die Detaillierung der Nachrichten auszuwählen, die SEP sesam in verschiedene Fehlerprotokolle schreibt. Die Ausführung von SEP sesam mit einer höheren Protokollstufe als dem Standard (0 für Sicherung und Rücksicherung) kann nützlich sein, wenn Sie mehr Informationen über bestimmte Ereignisse oder Module erhalten möchten oder wenn Sie vom Support im Rahmen der Diagnose Ihres spezifischen Problems gefragt werden.

Beachten Sie, dass die Erhöhung der Protokollstufe die Menge der protokollierten Informationen erhöht und die Leistung von SEP sesam negativ beeinflussen kann. Daher sollten Sie nur für Ihre eigene Analyse eines bestimmten Problems bei einer Sicherung oder Rücksicherung oder auf Anfrage des Supports eine höhere Protokollstufe festlegen, um im Falle einer Fehlerbehebung Debugginginformationen bereitzustellen. Nachdem Sie das Problem reproduziert haben, setzen Sie die Protokollstufe wieder auf den Standardwert zurück, besonders falls Sie die Datei debug.ini geändert haben.

Im SEP sesam können Sie die Protokollstufe auf verschiedenen Ebenen einstellen:

• Für bestimmte Sicherungs- oder Rücksicherungsaufträge in der GUI: Auswahl -> Aufträge -> Nach Clients -> Doppelklicken Sie auf den Sicherungs- oder Rücksicherungsauftrag, um die Eigenschaften zu öffnen. Die Protokollstufe wird unter dem Reiter Optionen für die Sicherung und unter Expertenoptionen für den Rücksicherungsauftrag eingestellt. Details finden Sie im Abschnitt Einstellung der Protokollstufe pro Auftrag in der GUI.
• Global für SEP sesam Kernel-Module durch Ändern der Datei <SESAM_VAR>/ini/debug.ini auf dem SEP sesam Server. Details finden Sie im Abschnitt Globales Festlegen der Protokollstufe für SEP sesam Kernel-Module in debug.ini.

Das Standard SEP sesam Verzeichnis für Protokolle ist <SESAM_VAR> (/var/opt/sesam/var). Weitere Informationen finden Sie unter Verzeichnisstruktur.

SEP sesam Protokollstufe

SEP sesam verwendet für verschiedene Module unterschiedliche Protokollstufen. Die folgende Liste stellt die Berichtsebene des Sicherungs- und Rücksicherungsprotokolls dar, die in der GUI auf Auftragsbasis festgelegt ist. Die Protokollstufen werden in der Reihenfolge der zunehmenden Menge der protokollierten Informationen aufgelistet, von niedrigsten bis höchsten:

Einstellung	Protokollstufendetails
0	nur Standard- und Fehlermeldungen zusammen mit einer Zusammenfassung drucken
1	Hinzufügen einer Zeile für jedes Element, wenn die Verarbeitung beginnt: sbc-3008: Info: Processing item: [xxx]...
2	Hinzufügen einer Zeile, wenn ein Element verarbeitet ist: sbc-3108: Info: Item processed successfully: [xxx]
3	Hinzufügen von Verarbeitungsinformation des Sicherungsmoduls (mit DB_API Modulen)
4	Hinzufügen darunterliegender Modul-Verarbeitung: XBSA und DB_API Module
5	Hinzufügen der Packungsdaten (mtf, cpio, sidf) Trace Meldungen

Details zum Setzen eines Loglevels für bestimmte Sicherungs- oder Rücksicherungsaufgaben in der GUI oder global für SEP sesam Kernelmodule finden Sie unter Protokoll Level einstellen.

Installations- und Konfigurationsprobleme

Installations Probleme

SEP sesam Server Installation unter Windows fehlgeschlagen

Problem

• Die SEP sesam Server Installation unter Windows ist mit einem Fehler fehlgeschlagen.

Ursache

• Für die SEP sesam Server Installation wurde ein Domänenadministrator Konto verwendet.

⇒ Lösung

• Bevor Sie die SEP sesam Installation unter Windows starten, stellen Sie sicher, dass Sie als lokaler Administrator (nicht Domänenadministrator) angemeldet sind.

SEP sesam Datenbankprobleme

PostgreSQL Startfehler nach Wechsel des SEP sesam Service Benutzers (nur Windows)

Problem Standardmäßig startet der SEP sesam Dienst unter dem Benutzerkonto SYSTEM. Bei der Installation wird die PostgreSQL Datenbank so eingestellt, dass sie unter diesem Konto gestartet wird. Wenn jedoch der Benutzername des SEP sesam Dienstes nach der Installation von SYSTEM (z.B. auf Administrator) geändert wird, hat PostgreSQL Startprobleme und kann nicht gestartet werden.

Ursache

Das Ändern des Benutzernamens des SEP sesam Dienstes beeinflusst die Eigentümerschaft und die Rechte des PostgreSQL Datenverzeichnisses, typischerweise den db_pg Ordner. Infolgedessen ist PostgreSQL nicht in der Lage, auf die notwendigen Dateien und Ressourcen zuzugreifen, was dazu führt, dass der Startvorgang fehlschlägt.

⇒ Lösung

Sie können zum vorherigen SEP sesam Service Konto (SYSTEM) zurückkehren, oder die Eigentümerschaft und Berechtigungen des PostgreSQL Datenverzeichnisses (db_pg Ordner) auf den verwendeten SEP sesam Service Konto Benutzer ändern. Stellen Sie in diesem Fall sicher, dass Sie auch die Eigentümer und Berechtigungen für Unterordner und Dateien ändern (verwenden Sie die Windows Explorer Option Replace owner on subcontainers and objects). PostgreSQL erhält die erforderlichen Zugriffsrechte zurück, so dass es erfolgreich gestartet werden kann. Beachten Sie, dass dieser Workaround die Eigentümerschaft und Berechtigungen des Ordners ändert. Stellen Sie daher sicher, dass das verwendete Benutzerkonto die entsprechenden Rechte für die Verwaltung der SEP sesam Datenbank hat.

Falsche Zeitzoneneinstellung in PostgreSQL

Problem

Das Exportieren der systemweiten Umgebungsvariablen TZ in der systemweiten /etc/profile Datei kann die Standardeingabeprofile überschreiben, was zu einer falschen Zeitzoneneinstellung in der Datei postgresql.conf führt. Infolgedessen können die Zeitwerte in der grafischen Benutzeroberfläche falsch sein. Eine Nichtübereinstimmung zwischen der Standardzeitzone des Systems und der TZ-Variable führt zu inkonsistenten Zeitwerten, die in der grafischen Benutzeroberfläche angezeigt werden.

⇒ Lösung

Aktualisieren Sie in der /etc/profile Datei die Umgebungsvariable TZ und stellen Sie die Zeitzone ein, die mit der gewünschten Standardzeitzone des Systems übereinstimmt. Dadurch wird sichergestellt, dass die Zeitzoneneinstellung in der postgresql.conf Datei mit der Standardzeitzone des Systems übereinstimmt.

Lizenz Probleme

SEP sesam Server Lizenzimport schlägt fehl

Problem

• Lizenzprobleme nach Einspielen einer neu ausgestellten Lizenz

Ursache

• Die Lizenz wird nicht korrekt importiert

⇒ Lösung

• Sollten nach dem Einspielen einer neu ausgestellten Lizenz Probleme auftreten (eigenartige Fehlermeldungen; Ablaufmeldung der Lizenz, obwohl die Lizenzdatei eigentlich gültige Werte aufweist; 'Gültig bis' zeigt einen anderen Wert in der Lizenzinfo, als in der Lizenz, usw. ), dann bitte einmal die Folgenden Schritte durchführen:

1 - In der GUI unter HILFE - LIZENZ INFO ganz unten NEUE LIZENZ IMPORTIEREN auswählen.
2 - Mit dem Dateimanager dann aus <SEPsesam>/skel die Demo-LIC-Datei (sm_lic.ini) als Lizenz einspielen.
3 - Nun wieder in der GUI unter HILFE - LIZENZ INFO ganz unten im Fenster NEUE LIZENZ IMPORTIEREN auswählen.
4 - Mit dem Dateimanager nun abschließend wieder die neu ausgestellte Lizenz einspielen.

-> Nun sollte bei einer abschließenden Prüfung (wieder in der GUI unter HILFE - LIZENZ INFO) zu sehen sein, dass die neu erstellte Lizenz korrekt eingespielt wurde und alle Fehler verschwunden sind.

Aktualisierungsprobleme

Das Client/RDS Update funktioniert nicht über die GUI

Problem

• Das direkte Update von Client/RDS über die GUI startet nicht.

Grund

• Es gibt noch Client-Informationen in der Datenbank, die den Updateprozess behindern.

⇒ Lösung

1. In der GUI unter Clients einen Rechtsklick auf den Client durchführen und den Kontextmenüpunkt Versionsinformationen zurücksetzen anklicken.
2. Klicke nun zusätzlich in den Eigenschaften des Clients auf den Mülleimer neben Letzte SEP sesam Meldung.

Nun sollte das Update problemlos an- und durchlaufen.

SEP sesam Server Update fehlgeschlagen

Problem

• Das SEP sesam Server Update ist mit einem Fehler fehlgeschlagen.

Ursache

• SEP sesam Dienste auf dem zu aktualisierenden System konnten nicht gestartet werden, wodurch das SEP sesam Server Update fehlgeschlagen ist.

⇒ Lösung

• Prüfen Sie, ob die SEP sesam Server Dienste laufen. Falls nicht, starten Sie die SEP sesam Dienste manuell und verwenden Sie dann das gleiche Update für die Reparaturinstallation. Details finden Sie unter So Starten und Stoppen Sie SEP sesam.

SEP sesam Windows Client Update von Version 4.4.3.64 schlägt mit Fehler fehl

Problem

• Das SEP sesam Windows Client Update von SEP sesam Version 4.4.3.64 Grolar auf eine neuere Version kann mit dem folgenden MSI Installer Fehler fehlschlagen:

Unable to create a temp copy of transform

Ursache

• Dieses Problem tritt auf, wenn der in der Registrierung angegebene Transformationspfad auf einen falschen Ordner verweist.

⇒ Lösung

• Um dieses Problem zu beheben, müssen Sie den Transformationsschlüssel im Registrierungseditor umbenennen.

	Hinweis
	Dieser Vorgang verändert die Windows-Registrierung; eine falsche Änderung der Windows-Registrierung kann Ihr Betriebssystem zum Absturz bringen und zu Datenverlust führen. Stellen Sie sicher, dass Sie eine gültiges SEP sesam- und Betriebssystemsicherung haben, bevor Sie fortfahren!

Gehen Sie wie folgt vor:

1. Öffnen Sie den Registrierungs-Editor: Verwenden Sie Start und geben Sie regedit ein.
2. Navigieren Sie zum Produktordner:

 HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products

3. Suchen Sie den folgenden Ordner und klicken Sie ihn an:

 7737007073521AA4885C03C7AEE4954D

4. Klicken Sie im rechten Fenster mit den Registrierungsschlüsseln mit der rechten Maustaste auf den Schlüssel Transforms und benennen Sie ihn in Transforms_ um.

Automatische Remote-Aktualisierung von der GUI schlägt fehl

Problem

• Unter Windows schlug die automatische Remote-Aktualisierung mit dem folgenden Fehler fehl:

Windows error: (0x800703FA) Illegal operation attempted on a registry key that has been marked for deletion

• Die Protokolldatei sm_msi.log auf dem Client-System zeigt Folgendes an:

InstallShield 11:08:04: Initializing Engine
InstallShield 11:08:04: Marshalling the , error = 0x800703fa
InstallShield 11:08:04: Open Script operation failed, error is 0x800703fa
InstallShield 11:08:04: Failed to invoke __ISWIUnInit, error is 0x80070057
InstallShield 11:08:04: Failed to shutdown script engine for script C:\Users\sepshare\AppData\Local\Temp\{A2C12F7B-F8D3-4D99-8E34-61600D67DBCC}\setup.inx, error is 0x80070057
InstallShield 11:08:04: Initialize() Failure, Failed to Initialize script support, Error = 0x800703fa

Ursache

• Typischerweise tritt dieser Fehler auf, wenn der Sesam-Dienst unter einem bestimmten Benutzerkonto anstelle des Standard-Systemkontos läuft. Ein Administrator verwendet dieses Service-Benutzerkonto, um sich am Server (SEP sesam RDS oder Client) für die Sitzung anzumelden und meldet sich dann ab. Dies erzwingt ein Entfernen der Registrierungsschlüssel im Kontoprofil, so dass die Schlüssel für die zukünftige Verwendung nicht mehr verfügbar sind.

⇒ Lösung

Sie müssen den Windows User Profile Service aktivieren, der die Registrierungsschlüssel nach der Abmeldung nicht entfernt:

1. Öffnen Sie den Gruppenrichtlinien-Editor (Gpedit.msc) auf dem jeweiligen Server.
2. Öffnen Sie den Ordner Benutzerkonten: Gehen Sie zu Computerkonfiguration -> Administrative Vorlagen -> System -> Benutzerkonten.
3. Suchen Sie nach der Einstellung Die Registrierung der Benutzer bei der Benutzerabmeldung nicht zwangsweise entladen und wählen Sie die Option Aktiviert. Weitere Informationen finden Sie im Microsoft Support-Artikel "800703fa Illegal operation attempted on a registry key" error .

Probleme mit Interfaces

Fehler beim Senden von E-Mails der Alarm Schnittstelle

Die Alarm-Schnittstelle ist so konzipiert, dass die im LIS-Dateiverzeichnis gespeicherten Sicherungsprotokolle an bestimmte E-Mail Empfänger gesendet werden. In Apollon wurden Änderungen an der Verzeichnisstruktur der LIS-Dateien vorgenommen, um die Dateiverwaltung zu verbessern und die Dateisystemoperationen zu optimieren. Die LIS-Dateien werden jetzt in dem <SESAM_ROOT>/var/lis Verzeichnis gespeichert, wobei für jeden Sesam-Tag ein neues Unterverzeichnis angelegt wird, was eine Ansammlung von Dateien in einem einzigen Verzeichnis verhindert.

Diese Änderung hat versehentlich dazu geführt, dass die Alarm Schnittstelle den Überblick über die erforderlichen Protokolldateien verloren hat. Das sm_alarm Skript ist nicht in der Lage, die .not Datei zu finden, was zu dem NullPointerException Fehler führt, und die Alarm Schnittstelle kann keine E-Mails senden.

⇒Lösung

Um dieses Problem zu lösen, müssen Sie das sm_alarm Skript manuell ändern. Dadurch wird sichergestellt, dass die richtigen Variablen verwendet werden und das Skript die erforderlichen Dateien finden kann. Beachten Sie, dass sich das Verfahren zur Änderung des sm_alarm Skripts unter Linux und Windows leicht unterscheidet. Detaillierte Anweisungen finden Sie in den folgenden Abschnitten.

Unter Linux

Öffnen Sie das sm_alarm.sh Skript und suchen Sie die folgende Zeile:

sm_smtp -A "sesam" -s "$mail_subject" -M "$( ls -tr ${gv_rw_lis}/$f*not|tail -1 )" ""

Ersetzen Sie diese Zeile durch:

sm_smtp -A "sesam" -s "$mail_subject" -M "$3" ""

Unter Windows

1. Öffnen Sie das sm_alarm.ps1 Skript in einem Texteditor und suchen Sie die Funktion send_backup_mail:

    function send_backup_mail($type,$msg,$task)
    {
      ## Set mail subject
      $mail_subject = (write "Sesam ALARM: $type $task failed")
      ## Send Sesam not file as mail body
      $filename = ((Get-ChildItem  "$env:lis\*$task*.not" | sort-object -property LastWriteTime | select-object -last 1).FullName)
      sm_smtp -A "sesam" -s "$mail_subject" -m "$msg" -a "$filename"
    }

   Ersetzen Sie die Funktion durch:

    function send_backup_mail($type,$message,$filename)
    {
      $task = ($message -replace ":.*","")
      ## Set mail subject
      $mail_subject = (write "Sesam ALARM: $type $task failed")
      ## Send Sesam not file as mail body
      sm_smtp -A "sesam" -s "$mail_subject" -m "$message" -a "$filename"
    }

2. Suchen Sie die folgende Zeile:

    {send_backup_mail $args[0] $args[1] $task

   Ersetzen Sie diese Zeile durch:

    {send_backup_mail $args[0] $args[1] $args[2]

Alarm-Schnittstelle funktioniert nicht wie erwartet

Das Skript, das die Funktionen der Alarm-Schnittstelle definiert, kann modifiziert werden, um das Verhalten der Alarm-Schnittstelle anzupassen. In Version 5.1.0.7 wurde das Skript neu geschrieben, um ein Problem zu beheben (siehe Alarm-Schnittstelle sendet keine E-Mails). Infolgedessen wurden alle Änderungen, die vor dieser Version am Skript vorgenommen wurden, überschrieben und das Standardverhalten der Schnittstelle ist wiederhergestellt.

⇒Lösung

Um dieses Problem zu beheben und das gewünschte Verhalten der Alarm-Schnittstelle wiederherzustellen, ist es erforderlich, die Anpassungen im Skript erneut vorzunehmen, die das Verhalten wie gewünscht verändern. Benutzer sollten ihre früheren Änderungen sorgfältig überprüfen und sie erneut auf das aktualisierte Skript anwenden.

Deinstallationsprobleme

Für Probleme bei der Deinstallation siehe Deinstallation von SEP sesam.

Problem bei der Einstellung der System-Grenzwerte

Problem

• SEP sesam Grenzwerte auf dem System müssen angepasst werden, die Einstellungen sollten aber nicht durch Aktualisierungen überschrieben werden.

⇒Lösung

Der beste Weg, SEP sesam Grenzwerte auf dem System anzupassen, ist die Erstellung der Systemd Überschreibungsdatei. Durch Verwendung dieser Datei werden die Einstellungen beim Aktualisieren nicht überschrieben.

Um die Grenzwerte des Systems einzustellen, gehen Sie wie folgt vor:

Beispiel

>
> root@cefix:~# systemctl show sepsesam.service | grep ^LimitCORE=
> LimitCORE=2147483648

1. Erstellen Sie die Überschreibungsdatei und passen Sie den Wert an:

 > mkdir -p /etc/systemd/system/sepsesam.service.d/
 > echo "[Service]" >
 > /etc/systemd/system/sepsesam.service.d/override.conf echo 
 > "LimitCORE=infinity" >> 
 > /etc/systemd/system/sepsesam.service.d/override.conf

2. Laden Sie das System neu, indem Sie den Befehl verwenden:

 > root@cefix:~# systemctl daemon-reload

3. Geben Sie dann an:

 > root@cefix:~# systemctl show sepsesam.service | grep ^LimitCORE= 
 > LimitCORE=infinity

Windows Installer (MSI) Installationsfehler

Problem 1

• Sie erhalten die folgende Warnung: "Während der Installation der Assemblykomponente ist ein Fehler aufgetreten ... HRESULT 0x80070bc9."

Mögliche Ursachen

• Die von MSI verwaltete Datenbank ist blockiert, nachdem Windows Updates installiert wurden.

⇒ Lösung

• Den betroffenen Rechner neustarten, damit Datenbank freigegeben wird.

	Anmerkung
	In der msi log Datei ist die Zeile 'Transforming table Error' sehr oft zu finden. Dies bedeutet nicht dass ein Fehler aufgetreten ist, sondern nur dass die Tabelle Error transformiert wurde. Es handelt sich also nur um eine Information keine Fehlermeldung.

Problem 2

• Die Installation ist nach der Deinstallation fehlgeschlagen - Sie erhalten das folgende Popup:
  • Englisch: "The SEP sesam server was installed using a server installation package. Please retry the update using a server installation package instead of the server package you are using. Update will be aborted."
  • Deutsch: "Der SEP sesam server wurde mit einem server Installationspaket installiert. Bitte wiederholen Sie den Update mit einem server Installationspaket statt des verwendeten server Pakets. Das Update wurde abgebrochen."

Mögliche Ursachen

• Die Deinstallation hat den Registrierungsschlüssel HKLM\SOFTWARE\SEP Elektronik GmbH nicht entfernt.

⇒ Lösung

• Öffnen Sie die MS Windows-Registrierung (z.B. mit regedit) und entfernen Sie HKLM\SOFTWARE\SEP Elektronik GmbH.

Red Hat Enterprise Linux

Problem

• Die folgende Warnung tritt auf einem Windows-Betriebssystem auf: "ERROR: SMS0004: The specified device does not exist." (Das angegebene Gerät ist nicht vorhanden.)

⇒ Lösung

• Neuinstallation des Softwarepakets CBMR x.x SEP Sesam Version.

Powershell-Skript wird auf einem Zielcomputer nicht ausgeführt

Problem

• Warum wird das Powershell-Skript nicht auf dem Zielcomputer ausgeführt?

Mögliche Ursachen

• Microsoft installiert Windows Powershell standardmäßig mit der Berechtigung Eingeschränkt. Diese Einstellung erlaubt nur die Ausführung von Befehlen in Powershell, aber keine Skripte.

⇒ Lösung

Mit folgendem Befehl lässt sich dies in der PowerShell abändern:

Set-ExecutionPolicy RemoteSigned

Weitere Informationen finden Sie unter About Execution Policies.

IBM DB2

Problem

• Es gibt Probleme mit SEP sesam Operationen.

⇒ Lösung

• Prüfen Sie den Inhalt der Protokolldatei $HOME/sqllib/db2dump/db2diag.log des DB-Benutzers.
• Überprüfen Sie die Meldungen auf dem SEP sesam Server.
• Weitere Informationen finden Sie im sdb2 Protokoll. Der Dateiname des Protokolls wird mit XBSA LOGFILE=<Full pathname of sdb2.log> und die Protokollstufe mit XBSA TRACE=1festgelegt.

	Anmerkung
	Alle XBSA-Meldungen von SEP sesam haben das Präfix XBSA. Sie können XBSA TRACE auf 2 setzen, um mehr Details anzuzeigen, aber dann können die Protokolldateien ziemlich groß werden.

MacOS

Problem

• Es gibt Probleme mit SEP sesam Operationen.

⇒ Lösung

Das Mac-Installationsprogramm verfügt über ein eigenes Meldesystem. Um die Protokolldateien einzusehen, gehen Sie wie folgt vor:

1. Führen Sie die Installation/Aktualisierung des Client- oder GUI-Pakets Schritt für Schritt aus, bis Sie zum letzten Installationsschritt Zusammenfassung gelangen.
2. Gehen Sie zum Installationsmenü und klicken Sie auf Fenster -> Installationsprotokoll.
3. Wählen Sie eine der folgenden Optionen: Nur Fehler anzeigen, Fehler und Fortschritt anzeigen oder Alle Protokolle anzeigen.

AIX

Problem

• Nach der SEP sesam Installation tritt der Fehler STATUS=ERROR MSG=Some daemons offline auf

⇒ Lösung

Standardmäßig ist der SEP sesam sshd-Daemon nicht im AIX-Paket enthalten. Daher meldet der Befehl:

/opt/sesam/bin/sesam/sm_main status

den sshd als offline:

2016-08-27 16:20:05: sshd               : offline

• Derzeit kann dieser Fehler ignoriert werden, da nur der CTRL-Zugriffsmodus für AIX-Systeme unterstützt wird.

• Um den Daemon sshd zu deaktivieren, bearbeiten Sie die Datei:

/opt/sesam/var/ini/sm.ini

und ändern Sie die Option:

sshd=on

in

sshd=off

• Wenn andere Dienste nicht starten, wenden Sie sich an SEP sesam Support.

Debian repository

Problem 1

• Nach der Ausführung von apt-get update wird der folgende GPG-Fehler angezeigt:

W: GPG error: https://download.sep.de/ jessie InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 68111EBBD273917B

Ursache

• Der SEP GPG-Schlüssel fehlt im Systemschlüsselbund.

⇒ Lösung

• Installieren Sie den Schlüssel, wie im Debian Repository gezeigt.

Problem 2

• Während der Paketinstallation tritt die folgende Warnung (Verifizierungsfehler) auf:

 WARNING: The following packages cannot be authenticated!
 sesam-<package>
Install these packages without verification? [y/N]

Ursache

• Der SEP GPG-Schlüssel fehlt im Systemschlüsselbund.

⇒ Lösung

• Installieren Sie den Schlüssel, wie im Debian Repository gezeigt.

Problem 3

• Während der Ausführung von apt-get update erscheint die folgende Meldung:

N: Das Laden der konfigurierten Datei »main/binary-i386/Packages« wird übersprungen, da das Depot [...] die Architektur »i386« nicht unterstützt.

⇒ Lösung

• Fügen Sie [arch=amd64] zwischen dem Wort deb und der URL des Repositorys ein, wie folgt:

deb [arch=amd64] https://download.sep.de/linux/repositories/debian/ stretch main

Problem 4

• Beim Ausführen des Befehls apt-key add erscheint die folgende Meldung:

E: gnupg, gnupg2 and gnupg1 do not seem to be installed, but one of them is required for this operation

⇒ Lösung

• Installieren Sie das Paket gnupg, um die Abhängigkeit über den Paketmanager zu erfüllen:

apt-get install gnupg

Problem 5

• SEP sesam bietet signierte Debian Repositories für eine einfachere Paketinstallation, Überprüfung und Aktualisierung der SEP sesam Software. Bei der Installation von SEP sesam Server über das Debian-Repository erscheint die folgende Meldung:

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
sesam-srv : Depends: postgresql-9.5 but it is not installable or
                     postgresql-9.6 but it is not installable or
                     postgresql-10 but it is not installable
E: Unable to correct problems, you have held broken packages.

Ursache

• Dieses Problem tritt typischerweise auf, wenn Sie die falsche Version der Debian-Distribution in /etc/apt/sources.list verwendet haben.

⇒ Lösung

• Korrigieren Sie die Version Ihrer Debian-Distribution, z.B. von stretch auf buster, und führen Sie dann apt-get update aus, um die Repository-Informationen zu aktualisieren. Für weitere Details zur Installation, siehe Debian Repository.

Troubleshooting zur SEP sesam Authentifizierung

Nach der Aktualisierung auf SEP sesam Version 5.0.0.x wird kein anderer Benutzer als der spezielle Benutzer Administrator (Windows) oder root (Linux) zum Superuser erhoben

Problem

• Nach einer Aktualisierung von SEP sesam auf Version ≥ 5.0.0 Jaglion meldet die GUI, dass Superuser-Rechte benötigt werden, aber nur Administrator-Rechte für diesen GUI-Benutzer aufgeführt sind. Der Administrator-Benutzer wird nicht zum Superuser erhoben und der Zugriff auf die GUI ist ohne Authentifizierung nicht möglich.

Ursache

• Dies ist das normale Verhalten für die Java-Policy-Authentifizierung. Nach der Erstinstallation von SEP sesam wird kein anderer Benutzer als der Standard Superuser konfiguriert. Wie der Name schon sagt, sind die Berechtigungen des Superuser-Kontos uneingeschränkt. Ab 5.0.0 Jaglion ist der Superuser der einzige Benutzertyp mit voller Kontrolle über die SEP sesam Umgebung. Er wird automatisch ausschließlich dem Benutzer Administrator zugewiesen, wenn die datenbankbasierte Authentifizierung aktiviert ist. Ist die Policy-basierte Authentifizierung aktiviert, wird dieser Benutzertyp mit Superuser-Rechten dem Administrator- (unter Windows und Linux), dem root- (nur Linux) und dem sesam-Benutzer zugewiesen. Weitere Einzelheiten finden Sie unter Benutzerrollen und -berechtigungen und Über Authentifizierung und Autorisierung.

⇒ Lösung
Wenn Sie Policy-basierte Authentifizierung verwenden und sich von localhost aus anmelden, können Sie Superuser-Rechte erhalten, wenn Ihr Benutzername nicht in sm_java.policy aufgeführt wird. Dies ist möglich, wenn der Parameter localFullAccess aktiviert ist (in der <SESAM_ROOT>/var/ini/sm.ini-Datei auf true gesetzt). Für die datenbankbasierte Authentifizierung gibt es keine solche Abhilfe, da nur Administrator (unter Windows und Linux) und root (nur Linux) zum Superuser werden können.

Tipps zur Fehlerbehebung bei Backups

Im Falle einer erfolglosen Sicherung sollten Sie die folgenden Tipps beachten:

• Ermitteln Sie anhand des Tagesprotokolls (.prt) und des Statusprotokolls (.status), wann das Problem aufgetreten ist. Das Tagesprotokoll zeigt den kausalen Verlauf aller SEP sesam Aktivitäten des Sicherungstages. Die Dateien mit der Endung .prt.err enthalten nur die Fehlermeldungen als Teilmenge des Tagesprotokolls.
• Zeigen Sie die Verzeichnisdateien chronologisch an (mit ls -lart unter Linux).
• Generell sollten die Protokoll-Dateien von unten gelesen werden. Wenn eine Sicherung fehlgeschlagen ist, finden Sie mögliche Hinweise auf Fehler und deren Ursachen in der Regel am Ende der entsprechenden Protokolldatei.
• Vergleichen Sie nicht funktionierende und funktionierende Backups:
• Prüfen Sie, wann die letzte erfolgreiche Sicherung dieser Tasks durchgeführt wurde.
• Finden Sie die Unterschiede zwischen not- und bck-Protokollen in den beiden verschiedenen Sicherungen.
• Finden Sie heraus, ob Änderungen im Netzwerk oder auf dem Client vorgenommen wurden.
• Die Werte der Datenbankaufrufe in DB_ACCESS (in den LOG-Files) werden im folgenden erläutert:
1. result = 1: Der Datenbankzugriff ist OK.
2. msg > 0: Betrag des Ergebnisses > 0.
• Wenn der Datendurchsatz sehr gering ist und das Backup immer noch nicht läuft, kann es sein, dass die Kommunikation zwischen Hardware und RDS gestört ist. Prüfen Sie mit netstat, ob die Verbindung über die STP-Ports (11001, 11002, etc.) noch besteht oder ob der RDS noch erreichbar ist.
• Wenn ein Prozess versucht, auf die Hardware zu schreiben und hängt, hilft der Befehl kill -9 unter Linux nicht weiter. Die einzige Lösung ist ein Neustart des Servers. Der Grund dafür ist die Tatsache, dass I/O-Requests nicht zurückkommen. Diese Prozesse dauern in der Regel nur Sekundenbruchteile, hängen aber bei einem Hardwarefehler.
• SEP sesam verwendet keine Kernelfunktionen und greift während der Verarbeitung nicht auf den Kernel zu. Alle Aufrufe erfolgen ausschließlich über GLIBC (GNU C Library). Das Kommando, das am tiefsten ins System eingreift, ist das SLU (SCSI Lader Utility). Es greift direkt auf die SCSI-Schnittstelle zu. Nur Lader- und Band-Transport-Befehle sind davon betroffen. Wenn ein Backup läuft, dann gibt es keinen direkten Zugriff auf den Kernel oder die Hardware mit SEP sesam. Einzelheiten zum Befehl finden Sie unter Verwendung von slu-Topologie für die Erkennung von Geräten.

Sicherungsprobleme

Fehler bei der Client-Sicherung

Problem 1

Die Sicherung eines Windows- oder Linux-Clients schlägt mit dem folgenden Fehler fehl:

"E020-HOSTS   [..] : Error:   Network communication problem: SOCKET error: 10060

Mögliche Ursachen

Die Ursache für dieses Problem ist sehr wahrscheinlich:

• Die aktive Firewall auf dem SEP sesam Sicherungs-Client. Prüfen Sie in diesem Fall die Firewall-Einstellungen und ob die Ports 11322 oder 11301 blockiert sind.

Prüfen Sie unter Linux auch, ob der Sesam SSHD Daemon läuft

ps axw | grep sm_sshd

und ob der Port 11322 offen und im Zustand LISTEN (hören) ist

lsof -i TCP | grep 11322

• Ein aktives Antivirenprogramm blockiert den Zugriff oder führt seine eigene Firewall aus und blockiert den Zugriff.
• Die Firewall eines Drittanbieters zwischen dem Sicherungsserver und dem Sicherungs-Client blockiert den Zugriff.
• Der SEP sesam Client Agent läuft nicht auf dem System.**Andere netzwerkbezogene Fehler.

Problem 2

Die Sicherung von einem Client funktioniert nicht, wie kann ich testen wo das Problem liegt?

⇒ Lösung
Führen Sie die folgenden Befehle aus, um den Fehler zu ermitteln:

	Achtung
	Alle folgenden Befehle erzeugen eine hohe Netzbelastung.

BACKUP SERVER UNIX, CLIENT WINDOWS

 sm_ctrlc -l system  {client name} sbc -b -s -  f:/test  >/dev/null

Daten aus dem Verzeichnis F:/ unter Windows werden über das Netzwerk in das Verzeichnis /dev/null unter Unix geschrieben. Um sie anzuzeigen, hängen Sie -v 1 an den obigen Befehl an. Alles, was in /dev/null geschrieben wird, wird angezeigt.

 sm_ctrlc -l system  {client name}   sbc  -b -s  -  -v 1      f:/test  >/dev/null

BACKUP SERVER UNIX, CLIENT UNIX

 sm_ctrlc -l root  {client name}   sbc  -b -s -  /usr  >/dev/null

Anzeigen der gelesenen Daten:

 sm_ctrlc -l root  {client name}   sbc  -b -s -  -v  1   /usr  >/dev/null

BACKUP SERVER WINDOWS, CLIENT UNIX

 sm_ctrlc -l root  {client name}   sbc  -b -s -             /usr    > NUL

Mit Protokollierung der Sicherungsdaten:

 sm_ctrlc -l root  {client name}   sbc  -b -s -  -v  1   /usr    > NUL

Wenn die Testsicherung nur auf dem Ziel-Sicherungs-Client durchgeführt werden soll, führen Sie folgenden Befehl aus:

Im Unix-Verzeichnis <sesam>/bin/sesam/:

 sbc -b -s  -  /usr   >/dev/null

Im Windows-Verzeichnis <SESAM_ROOT>\bin\sesam\:

 sbc  -b -s  -  f:/test    > NUL

Geben Sie -v 1 ein, um die gesicherten Daten auf Ihrem Monitor anzuzeigen.

Fehlgeschlagene Sicherungen werden automatisch gelöscht.

Problem

Standardmäßig löscht SEP sesam alle fehlgeschlagenen Sicherungen nach 3 Tagen automatisch, um den Speicherplatz freizugeben. Wie kann ich solche Sicherungen länger aufbewahren? (< Version 4.3.3)

⇒ Lösung

Wenn Sie Ihre fehlgeschlagenen Sicherungen länger als 3 Tage aufbewahren möchten, können Sie das EOL (Verfallsdatum) dieses bestimmten Sicherungssatzes manuell verlängern. Für Details, siehe Manuelles Verlängern der EOL. Beachten Sie, dass SEP sesam automatisch den letzte erfolgreiche Sicherungssatz einer Sicherung beibehält, wenn die nächste Sicherung fehlschlägt. Das bedeutet, dass SEP sesam die EOL der vorherigen 'erfolgreichen' oder 'mit Warnungen' Sicherung verlängert und somit sicherstellt, dass mindestens eine erfolgreiche Sicherung erhalten bleibt.

Während der Sicherung konnten die Daten nicht auf das Medium geschrieben werden

Problem

Während der Sicherung wird der Betriebssystemfehler "23 (ERROR_CRC)" angezeigt.

Mögliche Ursache

Das Bandlaufwerk kann keine korrekten Blöcke auf das Sicherungsmedium schreiben.

⇒ Lösung

Überprüfen Sie das Bandlaufwerk und die Sicherungsmedien.

Sicherung auf einen Datenspeicher schlägt fehl

Problem

Die Sicherung (oder Migration) auf einen Datenspeicher schlägt mit der Fehlermeldung All available space of media is used, stop writing to media (Der gesamte verfügbare Speicherplatz auf dem Medium ist belegt, Schreiben auf das Medium gestoppt) fehl.

Mögliche Ursache

SEP sesam bricht den Datentransfer ab, weil weniger als 1 GB auf dem Datenspeicher (Plattenspeicher) verfügbar ist. Auch ein Plattenfehler kann dieses Problem verursachen.

⇒ Lösung Die folgenden Punkte können helfen, eine Lösung zu finden:

• Überprüfen Sie die Systemmeldungen unter Linux bzw. das Ereignisprotokoll unter Windows auf eventuelle Hardwareprobleme.
• Entfernen Sie verwaiste Sicherungssätze aus den Datenspeichern mit der Option Aufräumen, siehe Datenspeicher.**Löschen Sie einige Sicherungssätze oder Sicherungen auf dem Datenspeicher und/oder starten Sie den Bereinigungsprozess für den Datenspeicher, um die veralteten (EOL-freien) Sicherungssätze zu löschen und genügend freien Speicherplatz zu schaffen. Für Details siehe Datenspeicher bereinigen.
• Vergrößern Sie den Speicherplatz.
• Führen Sie FSCK (Dateisystemüberprüfung) auf dem Plattenspeicher aus.

Wenn Sie trotz allem keine Lösung finden, berichten Sie Ihr Anliegen dem SEP sesam Support. Das Support-Team wird Ihnen dann weitere Anweisungen geben.

Falsche Anmeldung oder Passwort

Problem

Während der Sicherung wird die Meldung "Login incorrect. Password incorrect" angezeigt.

⇒ Lösung

Überprüfen Sie Ihre Namensauflösung (DNS oder etc/hosts Datei). Der SEP sesam Server und der SEP sesam Client müssen mit oder ohne FQDN erreichbar sein und sollten sich gegenseitig korrekt auflösen können, einschließlich des Reverse Lookup. Wenn die Auflösung korrekt ist, gehen Sie wie folgt vor:

1. In der SEP sesam GUI gehen Sie auf Auswahl -> Aufträge -> Nach Clients und wählen den Client mit dem Sicherungsproblem aus.
2. Öffnen Sie die Sicherungseigenschaften und klicken Sie auf den Reiter Optionen.
3. Geben Sie -v 4 bei Sicherungsoptionen ein.
4. Starten Sie die Sicherung erneut, gehen Sie dann zu Auswahl -> Jobstatus -> Sicherungen und doppelklicken Sie auf den Sicherungsauftrag, um dessen Eigenschaften zu öffnen.
5. Gehen Sie zu Protokollierung -> Tagesprotokoll und suchen Sie nach der Zeile Login incorrect. Password incorrect und korrigieren Sie die Namensauflösung.

Datenübertragung über FTP schlägt mit XBSA Initialisation error fehl

Problem

Zu Beginn einer Sicherungsdatenübertragung per FTP erscheint folgende Fehlermeldung:

- XBSA Initialisation error. Access to the requested object is not possible. NEGATIVE reply: 425 Can't open data connection. WINSOCK: Connection timed out. (0x274c,10060)

Mögliche Ursachen

Dieses Problem kann folgende Ursachen haben:

• Aktive Firewall auf dem System, das die Sicherungsdaten zwischen SEP sesam Server und Client übertragen soll.
• Routing oder Network Address Translation (NAT) zwischen den beteiligten Systemen.

⇒ Lösung

Die folgenden Punkte können helfen, eine Lösung zu finden:

• Im Falle eines Firewall-Problems:
  • Deaktivieren Sie die Firewall.
  • Passen Sie die Firewall anwendungsbezogen an. Dies muss auf dem System geschehen, das die Daten übertragen soll. SEP sesam verwendet aktives FTP. Wenn Sie regelmäßige Dateisicherungen unter Windows starten, fügen Sie die Binärdatei sbc.exe zur Ausschlussliste der Firewall hinzu. Im Falle von BSR unter Windows fügen Sie auch die Binärdatei oodiag.exe zur Firewall-Ausschlussliste hinzu.
  • Passen Sie die Firewall portbasiert an. Stellen Sie sicher, dass alle erforderlichen Ports auf dem System verfügbar sind und nicht durch eine Firewall blockiert werden. Wenn ein Portbereich offen ist, ist es wichtig, dass Sie diesen Portbereich in den STPD-Optionen für den Client konfigurieren. Details finden Sie unter Portnummern für SEP sesam Client.
• Im Falle eines Routers/NAT passen Sie die Regeln an, damit SEP sesam RDS und Client Daten übertragen können.

Ausfall der Netzwerkverbindung auf physischen oder virtuellen Systemen

Problem

Sicherungen physikalischer oder virtueller Systeme mit SEP sesam schlagen fehl (Netzwerkverbindungsfehlers fehl 10054). Die Protokolldateien enthalten eine der folgenden Fehlermeldungen:

10054 An existing connection was forcibly closed by the remote host

oder

Error : Network communication problem: SOCKET error: 10054 - The virtual circuit which reset by the 
remote side . recv () call failed.

Weitere Details zu Windows-Fehlercodes finden Sie unter Microsoft Developer Network Dokumentation.

Mögliche Ursachen

Ursache 1: Virtualisierungslösungen

Citrix XenTools sowie VMware Tools installieren unter Umständen auch eigene Netzwerkkartentreiber in die Virtuelle Maschine, die dann anstatt der regulären Windows Systemtreiber genutzt werden.

Die paravirtuellen Netzwerktreiber können einige Probleme verursachen:

• Generelle CPU Last von ca. 30% innerhalb einer VM ohne irgendwelche Aktionen
• Sehr schlechte Durchsätze, selbst in getrunkten Netzwerken oder Gigabit LAN
• Verbindungsabbrüche

Die oben genannte Fehlermeldung sagt laut Microsoft Dokumentation aus, dass die Verbindung vom Client, also dem zu sichernden System, zurückgesetzt wurde.

Auf dem SEP sesam Server spiegelt sich das Problem nach wie vor:

• Die Sicherung bleibt im Status aktiv mit einer Performance von 0 GB/h.
• Es sind sm_sms_backup Prozesse aktiv.
• Es sind sm_stpd Prozesse aktiv

Der SEP sesam hat also definitiv keine Rückmeldung vom Client, dass die Sicherung abgebrochen wurde. Die Verbindung wurde hart zurückgesetzt.

Ursache 2: Netzwerk/Port Trunking

In mehreren Kundenumgebungen wurde das Port-trunking entweder an Seite des zu sichernden Systems oder auf Sicherungsserver-Seite deaktiviert. Nachdem die Trunks aufgelöst wurden, konnten die Sicherungen ohne Probleme durchgeführt werden.

Um Trunking-Probleme zu beheben, siehe Trunking-Konfigurationsanleitung.

Ursache 3: Firewall

Wenn die Netzwerkverbindung in weniger als 5 Minuten unterbrochen wird, handelt es sich höchstwahrscheinlich um ein oben beschriebenes TSO/Trunking-Problem. Wenn die Netzwerkverbindung nach 5, 60 oder 120 Minuten getrennt wird, liegt ein KeepAlive-Problem mit dem NAT/PAT-Router oder einer Firewall vor.

Ursache 4: Virenscanner

Manche Virenscanner greifen aktiv in die Datenübertragung sowie in die beteiligten Prozesse ein und können somit eine Ursache des Problems darstellen. Es wird empfohlen, die Antiviren-Ausschlüsse für SEP sesam zu verwenden, da diese negative Auswirkungen auf die Sicherungs- und Rücksicherungsvorgänge haben können, wie in Virenscanner Exclude Empfehlung für SEP sesam beschrieben.

Ursache 5: Fehler auf SEP sesam Server Seite

Tritt zum Zeitpunkt des Abbruchs der Sicherung in der Ereignisanzeige oder der dmesg Ausgabe eines SEP sesam Server ein Problem bezüglich des Prozesses sm_stpd.exe bzw. sm_stpd auf, so ist das Problem von SEP sesam Server Seite zu analysieren. Beachten Sie, dass auch fehlerhaftes Routing die Ursache für dieses Problem sein kann.

Zum Beispiel befinden sich der SEP sesam Server und der SEP sesam Client in zwei unterschiedlichen Netzwerken. Das Routing wird nicht über einen zentralen Router geregelt, sondern über statische Routen in das jeweils andere Netz. Ein Ping vom SEP sesam Server zum Client funktioniert, anders herum jedoch nicht. Im beschriebenen Fall war auf dem SEP sesam Server die Ständige Route in das Netzwerk des Clients gesetzt, jedoch war sie nicht Teil der Aktiven Routen.

Löschen und neu hinzufügen der Route hat das Problem behoben:

route delete <Netzwerk_des_Clients>
route add -p <Netzwerk_des_Clients> mask <Netzmaske_des_Clientnetzwerkes> <SEP_sesam_Server_IP>

Ursache 6: Task Offloading abschalten

Für VMs

In der VM das Feature TSO (TCP Segment Offloading) abschalten.

Sowohl Citrix XenServer wie auch VMware ESXi nutzen in den Netzwerkkarten das vorhandene TSO. Dieses Feature ermöglicht es, verschiedene Operationen, die während der Fragmentierung von Netzwerkpaketen vorgenommen werden müssen, auf die Netzwerkkarte auszulagern (checksum Berechnung). Sinn ist es die CPU Last dadurch zu verringern, da die eigentliche Berechnung dann auf der Netzwerkkarte durchgeführt wird. (Die XenServer Netzwerkkartentreiber sind von diesem Problem stärker betroffen.)

Auf Windows

Um diese Funktion unter Windows zu deaktivieren, muss in der Registry der Schlüssel DisableTaskOffload gesetzt werden, um das Offloading auf die Netzwerkkarte zu verhindern, siehe Microsoft Dokumentation. Nach setzen dieser Option auf dem Sicherungs-Client und anschließendem Neustart sind weitere Sicherungen problemlos gelaufen.

Auf Linux

Unter Linux kann man die TSO Einstellungen mittels des Programms ethtool während der Laufzeit aktivieren oder deaktivieren:

ethtool -K eth0 tso off

TCP Retransmission

Das beheben von TCP Retransmission Fehlern auf Netzwerkebene behebt die eigentliche Ursache des Problems. Um TCP Retransmission Fehler zu finden, wird das Netzwerk Analyse Tool Wireshark benötigt.

Starten Sie mit Wireshark eine Netzwerkanalyse auf dem betroffenen System (Capture -> Interfaces).

	Anmerkung
	Retransmission Fehler erscheinen als schwarze Linien im Wireshark Log.

AUF WINDOWS

Anmerkung

SEP sesam verwendet Microsofts Volume Shadow Copy Service (VSS), um Sicherungen für verschiedene Auftragstypen durchzuführen. VSS-Fehler werden typischerweise durch die Systemkonfiguration und nicht durch SEP sesam verursacht. Dieser Abschnitt kann einige Anweisungen zur Fehlerbehebung solcher Probleme liefern. Wenn Sie Ihr Problem hier nicht finden können, überprüfen Sie auch VSS Troubleshooting oder lesen Sie Microsofts Artikel Volume Shadow Copy Service für weitere detaillierte Informationen über VSS.

Pfadsicherung auf Windows funktioniert nicht

Problem

SEP sesam Server konnte eine Pfadsicherung eines Windows Clients nicht ausführen (eine Pfadsicherung ohne VSS funktioniert jedoch). Der folgende Fehler wird angezeigt:

Problem while loading dynamic link library: [WIN32 API error: 1114 - A dynamic link library (DLL) 
initialization routine failed. LoadLibrary() call failed for: [vss.dll]].

Mögliche Ursachen

• Wenn die dll nicht initialisiert werden kann, wird dies in der Regel durch eine laufende Antivirenlösung verhindert.
• Die VSS-Konfiguration des Clients ist falsch.

⇒ Lösung

• Deaktivieren Sie die Antiviren-Software während der Sicherung.
• Überprüfen Sie die VSS-Konfiguration des Clients, indem Sie die folgenden Befehle ausführen:
  • vssadmin list writers - Überprüfen des Status aller Writers auf täglicher Basis
  • vssadmin list shadows - Prüfen von vorhandenen VSS-Kopien
  • vssadmin list shadowstorage - Prüfen, wie viel Speicherplatz für VSS reserviert und verfügbar ist.
  • vssadmin resize shadowstorage - Setzen des reservierten Speicherplatz für VSS-Snapshots auf unbegrenzt

WIN32 API error: "1450"

Problem

• Clientsicherung scheitert mit WIN32 API error: "1450 - Nicht genügend Systemressourcen, um den angeforderten Dienst auszuführen".
• Die Sicherung eines Clients endet mit der folgenden Fehlermeldung im Sicherungsprotokoll:

sbc-1148: Error:   W2KSS Error: [WIN32 API error: 1450 - Not enough system resources to execute 
the requested service.
Cannot store registry key: [SOFTWARE]. RegSaveKey() call failed in BackupRegistry().].

Mögliche Ursache

Unzureichende Größe des Registry-/Auslagerungsspeicherbereichs. Dieses Problem betrifft sowohl SEP sesam als auch andere Sicherungstools, wie z.B. NTBackup.

⇒ Lösung

Der Microsoft-Artikel Backup program is unsuccessful when you back up a large system volume erläutert Ansätze für verschiedene Versionen von Microsoft Windows.

Unsuccessful backup of OneDrive files

Problem

SEP sesam is unable to access files in OneDrive remote storage. When attempting to back up files stored in OneDrive, SEP sesam log file displays the following warning:

Warning: Unable to open item - Access to the cloud file is denied.

Ursache

OneDrive is a cloud-based service provided by Microsoft for storing, synchronizing, and sharing files. It has some unique characteristics that are specific to Microsoft's ecosystem and access to files is implemented differently than standard cloud solutions. SEP sesam may encounter difficulties in accessing and backing up the files that are stored in OneDrive cloud-like remote storage.

⇒ Lösung

To resolve this issue, consider using the "offline mode" and syncing the files from OneDrive to local storage on the client device. This enables SEP sesam to bypass the issues with access and files are backed up from the local storage rather than the cloud. Ensure that you regularly update the local copy to reflect the changes in the cloud storage.

System State Sicherung enthält aufgrund von DFS große Datenmengen

Problem

Bei der Durchführung einer Windows Systemstatussicherung (Auftragstyp System State) auf einem Server, auf dem DFS (Distributed File System) ausgeführt wird, werden große Datenmengen gesichert, und die Sicherung ist langsam.

Mögliche Ursachen

Wenn die DFS-Replikation aktiviert ist, kann die Sicherung des Systemstatus auch alle Daten des DFS-Replikationsdienstes enthalten.

⇒ Lösung

	Anmerkung
	Auf einem Domänencontroller (DC) wird das DFS zur Replikation des SYSVOL verwendet und sollte daher in die Systemstatussicherung einbezogen werden. Verwenden Sie das folgende Verfahren nur als Abhilfe, wenn Ihre Systemstatussicherung aufgrund der großen Menge an DFSR-Daten langsam sind.

Schließen Sie den DFS-Writer von dem System State-Sicherungsauftrags in der SEP sesam GUI aus: Wählen Sie in der Auswahl -> Aufträge -> Nach Clients Ihren Windows-Client aus und klicken Sie auf Ihren System State Sicherungsauftrag. In den Sicherungsauftragseigenschaften wechseln Sie auf den Reiter Optionen und schließen unter Zusätzliche Aufrufargumente -> Sicherungsoptionen den DFS Writer wie folgt aus:

-x "VSS:/DFS Replication service writer"

Als Nächstes müssen Sie die Dateisystemdaten, die vom DFS bereitgestellt werden, separat sichern, indem Sie eine reguläre Pfad-Sicherung durchführen (Erstellen Sie einen Pfad-Auftragstyp anstelle eines System State-Sicherungsauftrags). Details dazu finden Sie unter Windows System State Sicherung.

System State-Sicherungfehler (RegLoadKey)

Problem

• Warnung bei einer System State-Sicherung "Das System kann den angegebenen Pfad nicht finden. RegLoadKey()..."
• Folgende Fehlerausgabe ist im NOT-Protokoll ersichtlich::

C:\Program Files\SEPsesam\var\tmp\usr_wf_S-1-5-21-220523388-1123561945-839522115-1003].
2020-04-13 02:04:20: sbc-2074: Warning: W2KSS Warning: [WIN32 API error: 3 -
The system cannot find path. RegLoadKey() call failed for
file: [C:\Documents and Settings\nn\ntuser.dat] in BackupUserProfiles().].

Mögliche Ursache

Es gibt Inkonsistenzen in der Systemkonfiguration des Betriebssystems. Die Ursache ist, dass das Profil eines Benutzers gelöscht wurde, der Benutzer aber immer noch existiert. Die System State-Sicherung sucht im Dateisystem nach Dateien, die dem Benutzer entsprechen, aber die Dateien existieren nicht mehr.

⇒ Lösung

• Löschen Sie den betreffenden Benutzer oder stellen Sie das Profildatum im Dateisystem wieder her.
• Überprüfen Sie Folgendes in Ihrer Registry, um festzustellen, ob sie noch Referenzen auf Benutzernamen enthält, die nicht mehr existieren:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Zugriff verweigert bei einer Microsoft Windows-Sicherung über VSS

Problem

Die Microsoft Windows Sicherung über VSS bricht ab mit "[CVssBaseObject::CreateVssBackupComponents] - Access denied"

Mögliche Ursache

SEP sesam darf keinen Snapshot mit dem aktuellen Benutzer erstellen.

⇒ Lösung

Überprüfen Sie den Benutzer, der den SEP sesam Daemon ausführt und stellen Sie sicher, dass der Benutzer alle Berechtigungen hat, um auf das/die Volume(s) zuzugreifen.

Länge der Streamdaten übersteigt die Pufferkapazität

Problem

Folgende Warnung wird angezeigt: "Stream data length bigger than buffer can accept. Input buffer length = [65536], Stream data size = (High part)[0] (Low part)[65564]"

Mögliche Ursache

SEP sesam verwendet 64 kB für die Sicherung von Windows ACL Dateien und Ordnern und ein Objekt überschreitet diesen Puffer. Sie können den Windows-Befehl icacls verwenden, um die ACL einer Datei oder eines Ordners anzuzeigen. Die Ausgabe sieht wie folgt aus:

C:\>icacls "C:\Documents and Settings\LocalService\Local Settings\Temp"

C:\Documents and Settings\LocalService\Local Settings\Temp NT AUTHORITY\LOCAL SERVICE:(I)(F)
                                                           NT AUTHORITY\LOCAL SERVICE:(I)(OI)(CI)(IO)(F)
                                                           NT AUTHORITY\SYSTEM:(I)(F)
                                                           NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
                                                           BUILTIN\Administrators:(I)(F)
                                                           BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files

Wenn Sie mehrere hundert oder tausend Zeilen erhalten, ist etwas mit der ACL nicht in Ordnung.

⇒ Lösung

Setzen Sie die Berechtigungen des jeweiligen Ordners der Datei mit dem Befehl zurück:

C:\>icacls "C:\Documents and Settings\LocalService\Local Settings\Temp" /reset

Dieser Befehl übergibt die Berechtigungen des übergeordneten Objekts. Möglicherweise müssen Sie die Berechtigungen nach Ausführung dieses Befehls anpassen, wenn manuelle Einstellungen für dieses Objekt vorgenommen wurden.

Sicherung unter Windows 7 wurde nicht erfolgreich abgeschlossen

Problem

Wenn Sie eine Windows 7-Sicherung durchführen, kann die Sicherung mit einem der folgenden Fehler fehlschlagen.

sbc-1146: Error:   DB Module: [WIN32 API error: 55 - The specified network resource or device is no longer available.
sbc-2040: Warning: Cannot read item [\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy730\Windows\winsxs\x86_microsoft-windows-sort_31bf3856ad364e35_6.1.7600.16385_none_ab9479767ad67fd7\sort.exe: (2) WIN32 API error]:[ 2 - The system cannot find the file specified. ]. Padding remaining bytes...
smk-3506: Info:     Backup finished. Status: ERROR Error: Item generator returns [WIN32 API error: 2 - The system cannot find the file specified. ] for item [\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy136\Windows\winsxs\FileMaps\]
smk-3506: Info:     Backup finished. Status: ERROR Error:   DB Module: [Not all items have been processed]

Um einen detaillierteren Fehler zu sehen, schauen Sie sich das Ereignisprotokoll auf Ihrem Windows-Client an: Ereignisanzeige -> Windows-Protokolle -> System. Die Event Id 33, volsnap zeigt die folgende Meldung:

The oldest shadow copy of volume C: was deleted to keep disk space usage for shadow copies of volume C: below the user defined limit.

Mögliche Ursachen

• Der Speicherplatz hat nicht ausgereicht, um einen Snapshot zu erstellen. Das Betriebssystem löscht den Snapshot automatisch, wenn der Speicherplatz nicht ausreicht.
• Dieser Fehler tritt auf, wenn die Größe des Snapshots die für das Volume konfigurierte Maximum size (Maximaler Speicherplatz):Use limit (Nutzbarkeitsgrenzwert) überschreitet.

⇒ Lösung

Prüfen Sie Maximaler Speicherplatz: Nutzbarkeitsgrenzwert auf Ihrem Windows 7-Client: Öffnen Sie den Windows Explorer auf dem Client und klicken Sie mit der rechten Maustaste auf den Laufwerksbuchstaben, um die Laufwerkseigenschaften zu öffnen. Wählen Sie den Reiter Schattenkopien -> Einstellungen -> überprüfen Sie Maximaler Speicherplatz: Nutzbarkeitsgrenzwert:

• Wenn Sie Keine Begrenzung wählen, wird Windows den Snapshot nicht löschen, unabhängig davon, wie viel Speicherplatz er verbraucht. Beachten Sie jedoch, dass bei einem großen Snapshot die Erstellung des Snapshots fehlschlagen kann, weil auf dem betreffenden Laufwerk nicht genügend Speicherplatz vorhanden ist.
• Wenn Sie einen Nutzbarkeitsgrenzwert angeben, ändern Sie den maximalen Speicherplatz auf einen Wert, der groß genug ist, um den Snapshot mit genügend Spielraum zu enthalten. Nach Angaben von Microsoft wird empfohlen, den maximalen Speicherplatz auf einen Wert festzulegen, der 10 % der Volume-Größe entspricht. Wenn das Laufwerk C:\ beispielsweise 100 GB an Daten enthält, sollte der Grenzwert auf 10 GB festgelegt werden. Sie können die Daten des Snapshot auch auf einem anderen Datenträger speichern. Weitere Informationen finden Sie unter Microsoft forum answers Shadow Copy.

AUF LINUX

SEP sesam Linux Client Fehler beim Sichern

Problem

Ein SEP sesam Linux Client (SBC) gibt einen Fehler oder eine Warnung während der Sicherung aus.

Mögliche Ursachen

Die Sicherung unter Linux kann mit einem Fehler oder einer Warnung beendet werden, wenn:

• sich die Größe einer Datei während der Sicherung geändert hat
• eine Datei während der Sicherung gelöscht wird (zwischen 'Find' und der Datenverarbeitung)
• die Funktion 'Find' auf einen Fehler gestoßen ist

⇒ Lösung

• Um diese Warnungen zu vermeiden und die oben genannten Fehler zu beheben, doppelklicken Sie auf den Sicherungsauftrag, um seine Eigenschaften zu öffnen, und geben Sie unter dem Reiter Optionen im Feld Sicherungsoptionen den folgenden Befehl ein:

-o ignore_finderr=<regex>|ALL

• Wenn Sie alle derartigen Fehler/Warnungen vermeiden möchten, geben Sie dies an:

-o ignore_finderr=ALL

GVFS Fehler beim Sichern von Linux

Problem

• Wenn ein Benutzer in der gnome oder kde Sitzung angemeldet ist und die GVFS-Schicht verwendet, wird das Verzeichnis ~/.gvfs erstellt. Dieses Verzeichnis kann von keinem anderen Benutzer (auch nicht von root) geöffnet werden werden.
• Außerdem schlägt auch der Systemaufruf "stat" für dieses Verzeichnis fehl. Das Verzeichnis kann nicht ausgeschlossen werden, da sbc_find bei der Erstellung der Dateiliste und der Überprüfung der Ausschlüsse einmal einen "stat()"-Aufruf für das Verzeichnis durchführt und einen Fehler erhält.

⇒ Lösung

• Erstellen Sie eine neue Datei namens /etc/profile.local mit dem folgenden Inhalt:

GVFS_DISABLE_FUSE=1 
export GVFS_DISABLE_FUSE

• Führen Sie die folgenden Befehle für jeden betroffenen Ordner aus:
  • fusermount -u /home/$USER/.gvfs
  • test with stat /home/$USER/.gvfs

Rücksicherungsprobleme

Fehler beim Mounten eines Savesets auf SLES 15 SP4

Problem

• Wenn unter SLES 15 SP4 das guestfs-Tool zum Einhängen eines Savesets ausgeführt wird, schlägt das Einhängen mit der folgenden Fehlermeldung fehl:

error while loading shared libraries: libgcrypt.so.20: cannot open shared object file: No such file or directory

⇒ Lösung

• Führen Sie die folgenden Befehle auf dem betroffenen SEP sesam Server aus:
  • echo '/usr/lib64/libgcrypt.so*' > /usr/lib64/guestfs/supermin.d/zz-libgcrypt
  • echo '/usr/lib64/libgpg-error.so*' > /usr/lib64/guestfs/supermin.d/zz-libgpg-error

Disaster Recovery auf Linux

Fehler beim Ausführen einer ReaR-Sicherung

Problem

• Das SEP sesam Client Paket wurde erfolgreich installiert und die Pfadsicherungen funktionieren. Wenn Sie dann Probleme beim Ausführen einer ReaR Sicherung haben, überprüfen Sie das Sicherungsprotokoll auf fehlende Abhängigkeiten.
Beispiel:

There are binaries or libraries in the ReaR recovery system that need additional libraries
/opt/sesam/bin/sesam/libvirtmod.so requires additional libraries (fatal error)
	libvirt.so.0 => not found

Ursache

• In diesem Fall fehlt das libvirt-client Paket.

⇒ Lösung

• Abhängig von Ihrer Distribution installieren Sie libvirt-client wie folgt:
  • Unter RHEL/CentOS 7 verwenden Sie den Befehl: yum install libvirt-client
  • Unter SLES 12/15 verwenden Sie: zypper install libvirt-client

mkrescue wird im ReaR-System nicht unterstützt

Problem

• Der Arbeitsablauf mkrescue wird im ReaR Rettungs-/Wiederherstellungssystem nicht unterstützt.

⇒ Lösung

• Löschen Sie die Datei /etc/rear-release.

ReaR-Image bleibt beim Hochfahren hängen

Problem

• Das System bleibt während des Bootvorgangs hängen, wie in der folgenden Abbildung gezeigt:

⇒ Lösung

• Booten Sie das System mit der Option ACPI=OFF (diese Option kann auf der Befehlszeile im Boot-Menü-Prompt angegeben werden, nach den Optionen BACKUP=SESAM OUTPUT=ISO).

Das wiederhergestellte System bootet nicht

Problem 1

• Das System bootet nicht, weil /root/dev/console nicht gefunden werden kann.

Mögliche Ursachen

• Einige Distributionen verlassen sich auf die Existenz des Verzeichnisses /dev/ während sie hochfahren
• Bestimmte statische Geräte müssen vorhanden sein, bevor der udev Daemon sie erstellt.

⇒ Lösung

• Nehmen Sie das Dateisystem /dev/ in Ihre Sicherung auf.
• Wenn die Rücksicherung von /dev/ nicht möglich ist:

1. Booten Sie von der SEP sesam LIVE CD.
2. Erstellen Sie einen Mount auf die ROOT-Partition des rückgesicherten Systems.
3. Erstellen Sie manuell das /dev/ Verzeichnis.
4. Erstellen Sie manuell den /dev/console Eintrag mit:

mknod /path/to/target/mount//dev/console c 0 0

Problem 2

• Das System bootet nicht wegen fehlender libblkid.so.1.

Mögliche Ursachen

• Dies wird höchstwahrscheinlich durch SELinux verursacht, das standardmäßig aktiviert ist.

⇒ Lösung

• Insbesondere auf RHEL6- oder CentOS6-Systemen sollten Sie nach dem Neustart aus der ReaR-Wiederherstellung die folgenden Schritte ausführen:
1. Drücken Sie eine Taste, wenn Sie vom Bootloader (GRUB) dazu aufgefordert werden:

2. Wählen Sie den entsprechenden Bootloader-Eintrag:

3. Drücken Sie e, um die Befehle für den ausgewählten Eintrag zu ändern:

4. Fügen Sie selinux=0 zu den Befehlen hinzu:

5. Drücken Sie Enter, um die Änderungen zu bestätigen und b, um den Rechner mit deaktiviertem SELinux zu starten.
6. Wenn Sie Zugriff auf das System haben, ändern Sie die Option SELinux in /etc/selinux/config wie folgt:
SELINUX=permissive

Starten Sie anschließend das System neu und setzen Sie den Wert für SELinux bei Bedarf wieder auf erzwingen.

Es kann kein bootfähiges Betriebssystem gefunden werden

Problem

• Das System ist nicht in der Lage, nach der Rücksicherung eine bootfähige Betriebssysteminstanz zu finden.

Mögliche Ursache

• Evtl. gab es Probleme bei der Installation des GRUB-Bootloaders.

⇒ Lösung

• Das Rücksicherungsprotokoll enthält eine Aussage darüber, ob die Installation des Bootloaders erfolgreich war oder nicht:

2009-12-14 14:48:27: sbc-3500: Info:     Reinstall boot manager
[/sesam/bin/sesam//sbc_grub_auto /mnt/disk/ AUTO]

• Es ist auch möglich, das System erneut von der Live-CD zu booten, die Zielpartitionen einzuhängen und grub-install zu verwenden, um den Bootloader korrekt zu installieren.

Das Gerät verfügt nicht über ein entsprechendes BIOS-Laufwerk

Problem

• Während der Rücksicherung wird folgender Fehler angezeigt:

/dev/sda1 does not have any corresponding BIOS drive

Mögliche Ursachen

• Überprüfen Sie die /boot/grub/device.map Datei auf dem Zielsystem. Wenn es Einträge gibt, die auf die Festplatte über /dev/by-disk/... verweisen, wie im folgenden Beispiel gezeigt, ist der Eintrag höchstwahrscheinlich der Verweis auf die Festplattenpartition des defekten Systems. GRUB wird das richtige Gerät nicht finden:

hd(0) /dev/disk/by-id/ata-SAMSUNG_SP2504C_S09QJ1GLA14263-part1

⇒ Lösung

• Reboot von der Live-CD
• Mount auf die Root- und Boot-Partitionen nach /mnt/disk (und /mnt/disk/boot, wenn nötig)
• Neustart von grub-install mit folgenden Optionen:

grub-install --root-directory=/mnt/disk --recheck hd0

Ausgabe:

grub-probe: error: Cannot open `/boot/grub/device.map'
/usr/sbin/grub-install: line 374: [: =: unary operator expected
Installation finished. No error reported.
This is the contents of the device map /mnt/disk/boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.

(hd0)   /dev/hda
(hd1)   /dev/hdb

Sie können den Fehler line 374: [: =: unary operator expected ignorieren.
Wichtiger ist das Ergebnis Installation finished. No error reported.

Kein entsprechendes BIOS-Laufwerk für /dev/cciss/c0d0p2

Problem

• Sie bekommen die Meldung: /dev/cciss/c0d0p2 does not have any corresponding BIOS drive im Rücksicherungsprotokoll.

⇒ Lösung

• Siehe dazu: Novell Support

fsck.ext3: Dateisystem hat nicht unterstützte Funktionen

Problem

• Bei der Rücksicherung eines Systems mit Kernelversion 2.4 kann es vorkommen, dass das System nicht bootet, weil die Live-CD ein Dateisystem mit Funktionen erstellt, die von Kernel 2.4 nicht unterstützt werden.

Mögliche Ursachen

• Wahrscheinlich verursachen die Dateisystemoptionen resize_inode,dir_index,large_file,ext_attr das Problem und machen das System unbootbar.

⇒ Lösung

• Reboot aus dem Live-CD-Image, das das Werkzeug debugfs enthält.
• Anzeigen der Dateisystemfunktionen mit debugfs:

root@recover#: debugfs -w /dev/sda2
debugfs 1.41.1 (01-Sep-2008)
debugfs:  features
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
quit

Ersetzen Sie /dev/sda2 durch die entsprechenden Partitionsnamen auf Ihrem System.

• Um Dateisystemfunktionen zu entfernen:

root@recover#: debugfs -w /dev/sda2
debugfs:  features -resize_inode -ext_attr -dir_index -large_file -needs_recovery -sparse_super
Filesystem features: has_journal filetype
quit

Nachdem Sie die Optionen entfernt haben, sollte das System korrekt starten.

Falsche Inode-Größe (256)

Problem

• Nach einer erfolgreichen Rücksicherung bricht der Bootvorgang mit der Meldung incorrect inode size (256) ab.

Mögliche Ursachen

• Ältere Kernel-Versionen (2.4) verwenden möglicherweise eine andere Inode-Größe als das Dateisystem, das mit der Live-CD (die Kernel 2.6 enthält) erstellt wurde. Dies geschieht zum Beispiel bei der Rücksicherung von SLES8-basierten Systemen, die eine Inode-Größe von 128k verwenden.

⇒ Lösung

• Dies kann nur gelöst werden, indem man die Geräte manuell von der Live-CD aus formatiert, indem man die richtigen mkfs Optionen verwendet:

mkfs.ext3 -I 128 /dev/sda1

Hängen Sie danach die Partition wieder in /mnt/disk ein und wiederholen Sie die Rücksicherungsvorgänge. Das Ändern der Inode-Größe ist nur durch eine Neuformatierung der Geräte möglich.

Fehlendes Root-Dateisystem

Problem

• Das rückgesicherte System kann kein Root-Dateisystem finden und schlägt bei der Wiederaufnahme fehl.

Mögliche Ursache

• Die /etc/fstab Datei wurde mit dem Root-Dateisystem als UUID konfiguriert.

⇒ Lösung

• Geben Sie den Gerätenamen des Root-Dateisystems in konventionellen Gerätenamen an, wenn Sie eine andere physische Festplatte verwenden. Verwenden Sie nach dem Booten YAST, um Ihren Bootloader neu zu konfigurieren, oder bearbeiten Sie Ihre /boot/grub/menu.lst manuell:

root=/dev/sda2

Fehlende Netzwerkkarten

Problem

• Das rückgesicherte System findet keine Netzwerkkarten.

Mögliche Ursache

• Wenn die Rücksicherung auf einer anderen Hardware durchgeführt wurde, konfigurieren SLES-basierte Distributionen die Netzwerkgeräte möglicherweise nicht korrekt. SLES-basierte Systeme speichern ihre Netzwerkkonfiguration unter Verwendung der MAC-Adresse des Systems. Höchstwahrscheinlich wird das System nicht eht0 als Gerätename verwenden, sondern eth1, da es eine andere MAC-Adresse hat.

⇒ Lösung

• Verwenden Sie YaST und konfigurieren Sie Ihre Netzwerkschnittstellen neu.

Client startet nicht mit dem RHEL6/Debian9-Wiederherstellungsimage

Problem

• Der SEP sesam Client startet nicht automatisch auf RHEL6 und Debian9 basierten Wiederherstellungsimages.

Ursache

• Die Datei /etc/init.d/functions fehlt im Wiederherstellungsimage.

⇒ Lösung

• Der Client kann manuell gestartet werden mit:

/opt/sesam/bin/sesam/sm_main start

RHEL7-bezogene Probleme

RHEL7 Sicherung schlägt fehl

Fehler 1

• Die RHEL-Sicherung schlägt mit folgendem Fehler fehl:

ERROR: The LSB package is not installed.

⇒ Lösung

• Installieren Sie das Paket lsb wie folgt:

yum install redhat-lsb-core mkisofs syslinux

Fehler 2

• Die RHEL Sicherung schlägt fehl mit:

ERROR: Cannot find required programs: mingetty

Weitere Einzelheiten siehe Rear dependencies on RHEL7.

⇒ Lösung

Um dieses Problem zu lösen, gehen Sie wie folgt vor:

1. Editieren Sie

 /var/opt/sesam/var/lib/rear/usr/share/rear/conf/default.conf

und ab Zeile:

# required programs. Same as above, but if they are missing, we abort.
 REQUIRED_PROGS=(
 "$SCRIPT_FILE"

Entfernen Sie die Zeile:

 mingetty

2. Führen Sie die Sicherung erneut aus.

ReaR-Fehler während grub2-mkimage von bootx64.efi aufgetreten

	Anmerkung
	Um ein UEFI/EFI-bootfähiges ISO-Image erstellen zu können, muss das zusätzliche Tool ebiso auf dem Client-System installiert werden, wie im Abschnitt Installation von ebiso zur Erstellung von UEFI-fähigen ISO-Images beschrieben.

Problem

• Der ReaR Fehler tritt während grub2-mkimage von bootx64.efi auf.

⇒ Lösung

• Um das Problem zu lösen, installieren Sie das grub2-efi-x64-modules Paket.

SLES-bezogene Probleme

SM_SSH funktioniert nicht auf dem SLES11 Wiederherstellungsimage

⇒ Lösung

• In diesem Fall, führen Sie

mount -t tmpfs none /dev/shm/ -o rw,nosuid,nodev,noexec

aus, bevor Sie den Wiederherstellungsprozess starten.

Client ist nicht erreichbar nach dem Booten des Wiederherstellungsimages

Problem

• Nach dem Booten des Wiederherstellungsimages ist der Client nicht erreichbar.

⇒ Lösung

• Starten Sie den Client manuell mit dem folgenden Befehl in der Rescue-Kommandozeile:

sh /etc/scripts/system-setup.d/59-start-sesam-client.sh

EFI-Boot-Image kann unter SLES11 nicht erstellt werden

Problem

• EFI bootfähiges Image von GRUB2 kann unter SLES11 nicht erstellt werden.

Ursache

• SEP sesam V. 4.4.3.64 Grolar ist die letzte Version, die SLES11 mit UEFI unterstützt.

⇒ Lösung

• Um SLES weiterhin mit UEFI zu verwenden, sollten Sie nicht auf eine spätere Version von SEP sesam upgraden.

Installation von ebiso zur Erstellung von UEFI-fähigen ISO-Images

Um ein bootfähiges UEFI/EFI-ISO-Image erstellen zu können, muss das Zusatztool ebiso auf dem Client-System installiert sein. Dieses Paket ist nicht Teil einer regulären SLES12/SLES15-Installation und kann unter der folgenden URL heruntergeladen werden:

http://download.opensuse.org/repositories/Archiving:/Backup:/Rear/SLE_12/x86_64/

oder

http://download.sep.de/utils/bsr-linux/

Für andere Linux-Distributionen wenden Sie sich an den SEP-Support unter support@sep.de, um Unterstützung zu erhalten.

Installieren Sie ebiso wie folgt:

rpm -i ebiso-<version>.rpm

Beachten Sie, dass in ReaR V. < 1.19 der erzeugte ISO-Image-Mount möglicherweise zu klein ist, um alle benötigten Informationen zu speichern und angepasst werden muss.

In diesem Fall ändern Sie

/var/opt/sesam/var/lib/rear/usr/share/rear/lib/uefi-functions.sh (line 64)

Zeile

(shim.efi|elilo.efi) size=128000 ;;

zu

(shim.efi|elilo.efi) size=228000 ;;

Probleme mit der grafischen Benutzeroberfläche (GUI - Graphical User Interface)

Nach dem Aktualisieren von SEP sesam unter Windows kann die GUI nicht geöffnet werden

Problem

Nach einer Aktualisierung von SEP sesam auf Version ≥ 4.4.3.82 Beefalo V2 unter Windows kann die GUI nicht geöffnet werden, wenn die Gruppenrichtlinienoption Zugriff auf Programme zum Bearbeiten der Registrierung verhindern angewendet wird.

Mögliche Ursachen

Dieses Problem scheint mit der Einstellung für die Gruppenrichtlinie (GPO) zusammenzuhängen: Wenn für einen bestimmten Benutzer oder eine bestimmte Gruppe die Option Zugriff auf Programme zum Bearbeiten der Registrierung verhindern angewendet wird, funktioniert das Öffnen der grafischen Benutzeroberfläche für die Benutzer, die am Zugriff auf die Registrierung gehindert werden, nicht. In den meisten Fällen können Benutzer mit Administratorrechten die grafische Benutzeroberfläche dennoch ausführen, da sie in der Regel von einem GPO ausgenommen sind (und auf die Registrierung zugreifen können). Wenn diese Richtlinie deaktiviert (oder nicht konfiguriert) ist, können die Benutzer unabhängig von ihren Rechten auf die grafische Benutzeroberfläche zugreifen.

⇒ Lösung

Um den betroffenen Benutzern (in der Regel Nicht-Admin-Benutzern) den Zugriff auf die grafische Benutzeroberfläche zu ermöglichen, deaktivieren Sie die Gruppenrichtlinienoption Zugriff auf Programme zum Bearbeiten der Registrierung verhindern.

	Achtung
	Die Registrierung sollte nur von Experten bearbeitet werden; eine unsachgemäße Änderung der Windows-Registrierung kann Ihr Windows-Betriebssystem zum Absturz bringen und Datenverluste verursachen.

1. Drücken Sie die Windows-Taste + R, um das Fenster Ausführen zu öffnen.
2. Geben Sie gpedit.msc ein und drücken Sie Enter.
3. Doppelklicken Sie im Gruppenrichtlinien-Editor -> Benutzerkonfiguration -> Administrative Vorlagen -> System auf die Einstellung Zugriff auf Programme zum Bearbeiten der Registrierung verhindern im rechten Bereich und wählen Sie Deaktivieren. Klicken Sie dann auf Übernehmen.

GUI Server nicht erreichbar

Problem

SEP sesam kann nicht auf den GUI Server zugreifen.

Mögliche Ursachen

• Die Netzwerkverbindung zu SEP sesam ist abgebrochen.
• GUI-Server Prozess läuft nicht.

⇒ Lösung

• Stellen Sie sicher, dass der Computer läuft.
• Starten Sie den GUI-Server Prozess mit dem Befehl sm main reload rmi.

Verbindung zur Datenbank gescheitert

Problem

SEP sesam kann sich nicht mit der Datenbank verbinden.

Mögliche Ursache

DB- oder RMI-Server laufen nicht.

⇒ Lösung

Führen Sie die Befehle sm main reload db oder sm main reload rmi aus, um die Server neu zu starten.

GUI startet nicht

Problem

Die GUI (grafische Benutzeroberfläche) startet nicht.

Mögliche Ursachen

• Probleme mit Java-Rechten.
• Ein Problem mit der Bildschirmauflösung.

⇒ Lösung

Im Falle des Bildschirmauflösungsproblems stellen Sie eine Auflösung von mindestens 1920x1080 (Full HD) ein.

Falsche Zeitwerte in der GUI

Problem

In der GUI stimmen die angezeigten Zeitwerte nicht mit der Standardzeitzone des Systems überein.

Mögliche Ursachen

• Dies kann durch den Export der systemweiten Umgebungsvariablen TZ in der systemweiten Datei /etc/profile verursacht werden, die die Standard-Systemlokalisierungen überschreiben kann, was zu einer falschen Zeitzoneneinstellung in der Datei postgresql.conf führt.
• Unter Debian werden die Zeitzoneneinstellungen in der Datei /etc/timezone gespeichert. Wenn die Zeitzone auf dem System mit dem Befehl timedatectl set-timezone geändert wird, wird nur die Datei /etc/localtime aktualisiert. Die Datei /etc/timezone bleibt unverändert.

⇒ Lösung

• Aktualisieren Sie in der Datei /etc/profile die Umgebungsvariable TZ und stellen Sie die Zeitzone ein, die der gewünschten Standardzeitzone des Systems entspricht. Dadurch wird sichergestellt, dass die Zeitzoneneinstellung in der Datei postgresql.conf mit der Standardzeitzone des Systems übereinstimmt.
• Unter Debian aktualisieren Sie die Einstellungen in der Datei /etc/timezone, um die richtige Zeitzone einzustellen.

Online-Guide erscheint nicht

Problem

Auf den Online-Guide kann nicht zugegriffen werden.

Mögliche Ursachen

• Adobe Acrobat Reader ist nicht installiert.
• Adobe Acrobat Reader ist installiert, aber nicht in der GUI konfiguriert.
• Die PDF-Datei ist nicht im GUI konfiguriert.

⇒ Lösung

Laden Sie den Adobe Acrobat Reader von http://www.adobe.com herunter.

Online-Hilfe nicht verfügbar

Problem

Auf die Online-Hilfe kann nicht zugegriffen werden.

Mögliche Ursachen

• Auf dem System ist kein Browser installiert.
• Der Browser ist installiert, aber nicht in der GUI konfiguriert.

⇒ Lösung

Installieren Sie einen Browser.

Netzwerkprobleme

Netzwerk Check

Problem

• Die Netzwerkverbindung funktioniert nicht.

⇒ Lösung

• Führen Sie den Netzwerk Check (NW-Check) durch. Verwenden Sie die Befehle ping, nslookup, Adressauflösung etc. Zusätzlich müssen die Verbindungen mit dem korrespondierenden SEP sesam Programm (CTRL/SSH) überprüft werden. Die Adressauflösung muss beständig sein, d.h. wenn die Auflösung für einen TCP/IP Namen eine IP-Adresse zurück meldet, muss die Auflösung für diese IP-Adresse den gleichen TCP/IP Namen ergeben!

Beispiel

  # nslookup decunix
  Server: seplinux2.sep.de
  Address: 193.28.59.40

  Name: decunix.sep.de
  Address: 193.28.59.94

  # nslookup 193.28.59.94
  Server: seplinux2.sep.de
  Address: 193.28.59.40

  Name: decunix.sep.de
  Address: 193.28.59.94

Microsoft SQL Server

Anmeldung falsch

Problem

• Wenn eine Sicherung oder Rücksicherung fehlerhaft beendet wird und Sie die folgenden Informationen in den Protokolldateien finden, wurde versucht, eine SQL-Server-Instanz auf einem Client anzusprechen, die nicht lokal auf diesem System vorhanden ist. Die ausgewählte Trusteed Connection erlaubt nur die Registrierung auf einem SQL-Server, auf dem die Instanz lokal aktiv ist:

DB Module: [DB-Library: Login failed for user '(null)'. 
Reason: Not associated with a trusted SQL Server connection.]
DB Module: [DB-Library message: Login incorrect.]

⇒ Solution

• In dem Fall muss der Sicherungs-Client oder der Zielknoten auf den aktiven SQL Server geändert werden.

Sicherungsfehler bei Microsoft SQL Server

Problem

• Sicherung schlägt fehl mit "The server principal "NT AUTHORITY\SYSTEM" is not able to access the database "<database>" under the current security context."

Mögliche Ursachen

• Der Benutzer SYSTEM darf sich nicht am MS-SQL server anmelden, weil der SEP sesam Dienst standardmäßig als Benutzer SYSTEM läuft.

⇒ Lösung

• In diesem Fall muss man einfach den SEP sesam Dienst auf einen Benutzer ändern, der auf die MS-SQL Datenbank(en) zugreifen darf. Dazu die Windows Diensteverwaltung öffnen, die Eigenschaften des SEP sesam Dienstes bearbeiten und im Reiter Anmeldung autorisierte Benutzerdaten eingeben und anschließend den Dienst neu starten.

Eine MS SQL Server-Sicherung bringt die Meldung "The Transaction Log For Database Is Full"

Problem

• Während einer MicroSoft SQL Server Sicherung kann das Sicherungsprotokoll die Meldung anzeigen: "The transaction log for database '<DATABASE>' is full due to 'LOG_BACKUP'".

Mögliche Ursachen

• Diese Fehlermeldung zeigt an, dass der LOG-Bereich voll ist. Das kann passieren, wenn keine INC-Backups gemacht werden, sondern nur FULL-Backups.

⇒ Lösung

• Vergrößern Sie den LOG-Bereich und führen Sie ein FULL- und INC-Backup durch, damit die LOGs korrekt abgeschnitten werden können. Richten Sie dann regelmäßige INC-Backups ein, damit der LOG-Bereich nicht wieder voll läuft.

Für weitere Informationen zur Behebung dieses Fehlers siehe hier.

Rücksicherung einer Datenbank aus der AlwaysOn Availability Group misslingt mit RESTORE cannot operate on database 'Test1' because it is configured for database mirroring or has joined an availability group

	Anmerkung
	Für die Verwendung von MS AlwaysOn im SEP sesam ist die Hilfe des SEP sesam Supports nötig.

Problem

• Die Rücksicherung der MS SQL AlwaysOn Availability Group-Datenbank schlägt fehl:

DB Module: [UNKNOWN error: 4294967295 -. Got error: [SQL Server]RESTORE cannot operate on database 'Test1' because it is configured for database mirroring or has joined an availability group. If you intend to restore the database, use ALTER DATABASE to remove mirroring or to remove the database from its availability group.]

Ursache

• Es ist nicht möglich, die MS SQL-Datenbank, die Teil der AlwaysOn Availability Group ist, rückzusichern.

⇒Lösung

Um eine Datenbank, die Teil einer AlwaysOn Availability Group ist, erfolgreich rückzusichern, gehen Sie wie folgt vor:

1. Entfernen Sie die Datenbank aus der AlwaysOn Availability Group.
2. Rücksichern Sie die Datenbank auf dem primären Replikat in der AlwaysOn-Verfügbarkeitsgruppe.
3. Fügen Sie die rückgesicherte Datenbank erneut zur AlwaysOn-Verfügbarkeitsgruppe hinzu, indem Sie Full als Datensynchronisationsoption verwenden.

Anschließend wird die Datenbank auf die sekundären Replikate repliziert.

Rücksicherung misslingt mit The system cannot find the path specified

Problem

• Wenn die ursprüngliche Datenbank entfernt wurde oder die Datenbank an einem anderen Ort rückgesichert werden soll, muss der Pfad für die Datenbank vor der Rücksicherung erstellt werden. Wenn der Pfad für die Datenbank nicht vorhanden ist, erscheint die folgende Meldung:

Directory lookup for the file "C:\Programme\Microsoft SQL 
Server\MSSQL$ZWEITE_DB\data\sesamdb_Data.MDF" 
failed with the operating system error 3(The system cannot find the path specified.).
File 'sesamdb_Data' cannot be restored to 'C:\Programme\Microsoft SQL 
Server\MSSQL$ZWEITE_DB\data\sesamdb_Data.MDF'. 
Use WITH MOVE to identify a valid location for the file.

Ursache

• Das System kann den Datenbankpfad nicht finden, wenn die ursprüngliche Datenbank entfernt wurde oder der Datenbankpfad vor der Rücksicherung an einem anderen Ort nicht erstellt wurde.

⇒Lösung

• In diesem Fall müssen Sie die Datenbank an einem neuen Ort rücksichern, wie in Rücksichern einer Datenbank an einem neuen Ort mit Hilfe der GUI Optionen Relokation oder Move beschrieben.

Rücksicherung misslingt mit Directory lookup for the file '...' failed...

Problem

• Sie erhalten die folgende Warnung:

DB Module: [DB-Library: Directory lookup for the file "e:\Database\SQL Server 2000 SE
\MSSQL\Data\sesam.mdf"failed with the operating system error 21(The device is not ready.).]
DB Module: [DB-Library: File 'sesam_db' cannot be restored to 'e:\Database\SQL Server 2000 SE
\MSSQL\Data\sesam.mdf'.
  Use WITH MOVE to identify a valid location for the file.]

Mögliche Ursachen

• Der vorhandene Pfad, in dem sich die Datenbankdateien ursprünglich befanden nicht auf dem Zielsystem oder mit der "Move"-Option wurde ein nicht existierender Pfad angegeben.

⇒ Lösung

• Es muss der Pfad angelegt oder ein korrekter Pfad mit der Move-Option angegeben werden. Das Anlegen des Pfades ist i.allg. die einfachere Lösungsmöglichkeit. Außerdem kann es bei langen Pfaden zu Problemen mit der Move-Option kommen, die Eingabe wird dann verkürzt.

Rücksicherung von Fehlern aufgrund einer SQL Server Verbindung

Problem

• Die Rücksicherung schlägt mit folgendem Fehler fehl:

DB Module: [DB-Library message: Unable to connect: SQL Server is unavailable or does not exist.  
  Unable to connect: SQL Server does not exist or network access denied.; Net-Library message: ConnectionOpen (Connect()).; ]

Mögliche Ursachen

• Der ausgewählte Server existiert nicht. Es ist möglich, dass eine Instanz ohne Servername falsch eingegeben wurde.

⇒ Lösung

• Überprüfen Sie den Servernamen. Geben Sie bei Bedarf das vollständig qualifizierte Rücksicherungsziel wie folgt ein:

<HOSTNAME>/<Instance>/<DB Name>

Rücksicherung mit Move Option misslingt

Problem 1

• Rücksicherung mit Move Option misslingt mit The physical file name '...' may be incorrect. Der folgende Fehler erscheint:

DB Module: [DB-Library: A file activation error occurred. The physical file name 
'c:/temp/sesam_log.ldf' may be incorrect.
  Diagnose and correct additional errors, and retry the operation.]
DB Module: [DB-Library: File 'sesam_db_log' cannot be restored to 'c:/temp/sesam_log.ldf'.
  Use WITH MOVE to identify a valid location for the file.]

Mögliche Ursachen

• Die falsche Syntax wurde im Dateinamen verwendet, z.B. / statt \.

⇒ Lösung

• Pfad mit richtiger Syntax angeben.

	Anmerkung
	Falls der SEP sesam Server mit einer Postgres Datenbank arbeitet, z.B. auf Linux x64, dann müssen die '\' Zeichen doppelt eingegeben werden, ansonsten verschwinden diese in den Pfaden. Zum Beispiel: -a move=Mgmt_data:"e:\\SQL Server 2000 SE\\MSSQL\\Data\\Mgmt.mdf" -a move=Mgmt_log:"e:\\SQL Server 2000 SE\\MSSQL\\Data\\Mgmt_log.ldf"

Problem 2

• Rücksicherung mit Move Option misslingt mit Logical file '...' is not part of database. Der folgende Fehler erscheint:

DB Module: [DB-Library: Logical file 'Mgmt_data' is not part of database 'sesam_db2'.
  Use RESTORE FILELISTONLY to list the logical file names.]

Mögliche Ursachen

• In der Option Move wurde ein falscher logischer Name angegeben.

⇒ Lösung

Logischen File Namen richtig angeben, er kann aus dem Sicherungsprotokoll (NOT-File) entnommen werden. In der Sicherungsprotokolldatei sehen Sie beispielsweise die folgenden Zeilen:

DB Module: [DB-Library: Processed 256 pages for database 'sesam_db', file 'sesam_db' on file 1.]
DB Module: [DB-Library: Processed 1 pages for database 'sesam_db', file 'sesam_db_log' on file 1.]

Die logischen File Namen lauten hier sesam_db und sesam_db_log. Diese sollten in der Option Move eingetragen werden.

Zurückgesicherte Datenbank bleibt im Zustand Restoring

Problem

Nach der Rücksicherung einer MS SQLServer Datenbank verbleibt diese im Zustand (Restoring...).

Mögliche Ursachen

• Dieser Zustand tritt auf, wenn die Option Auto Recover in der Rücksicherungsauswahl nicht gewählt wurde

⇒ Lösung

• Rücksicherung mit Option Auto Recover ausführen. Oder nachträglich durch manuellen Aufruf von sbc mit Option -a recover für die entsprechende Datenbank. Zum Beispiel:

• Aufruf des sbc in der Kommandozeile mit:

sbc -r -a recover sbcmsql:"/MIRACULIX/SECOND/msdb"

	Anmerkung
	Auch bei der Rücksicherung einer Datenbank und zusätzlicher Transaktionsprotokolldateien (Generationsrücksicherung) verbleiben die Datenbanken solange im Zustand "Restoring..." bis die letzte Rücksicherung (mit -a recover) abgeschlossen wird.

Disaster Recovery misslingt mit ODBC SQL Server Driver][DBMSLPCN]SQL Server does not exist or access denied.

Problem

• MS SQL Disaster Recovery misslingt mit dem Fehler:

ODBC SQL Server Driver][DBMSLPCN]SQL Server does not exist or access denied.

Ursache

• Dieser Fehler weist in der Regel auf Netzwerk- oder Installationsprobleme hin; der SQL Server existiert nicht, ist nicht verfügbar oder wird nicht gefunden.

⇒Lösung 1:

• Wenn möglich, rücksichern Sie die Systemdatenbanken von der letzten Pfad-Sicherung. Wenn keine solche Sicherung existiert, prüfen Sie die Lösungen 2 und 3.

⇒Lösung 2:

• Erstellen Sie eine neue MS SQL-Instanz. Hierfür benötigen Sie die MS SQL-Installationsdateien. Details finden Sie unter How to manually create the Microsoft SQL Server 2014 ACT7 Instance. Rücksichern Sie dann die MS SQL-Datenbanken auf der neuen Instanz mit dem Zielpfad <Server_name>/<Instanzname>.

⇒Lösung 3:

Sie können auch die MS SQL System Datenbank neu erstellen. Das Verfahren unterscheidet sich geringfügig, wenn Sie die Datenbanken von CD oder DVD (MS SQL Server 2005) oder aus dem Installationsordner auf Ihrem lokalen Computer in \Binn\Templates\ (MS SQL Server ≥ 2008) neu erstellen, z.B. C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn\Templates. Sie müssen den Befehl setup.exe über die Kommandozeile ausführen und dann wie folgt vorgehen:

1. Klicken Sie auf Start -> Run, geben Sie cmd ein, und klicken Sie auf OK.
2. Führen Sie je nach Ihrer MS SQL-Version den entsprechenden Befehl aus, um die Systemdatenbanken neu zu erstellen:
• Um die Systemdatenbanken von CD oder DVD (MS SQL Server 2005) neu zu erstellen, führen Sie den folgenden Befehl aus:

 start /wait <CD_or_DVD_drive>\setup.exe /qn INSTANCENAME=<Instanzname> REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD=<starkes_Passwort>

Zum Beispiel:

 start /wait D:\setup.exe /qn INSTANCENAME=MSSQLSERVER REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD=p@ssw0rd

Für Details, siehe How to Rebuild System Databases in SQL Server 2005.

• Um die Systemdatenbanken von \Binn\Templates\ (MS SQL Server ≥ 2008) neu zu erstellen, führen Sie den folgenden Befehl aus:

 setup /ACTION=REBUILDDATABASE /QUIET /INSTANCENAME=<Instanzname> /SQLSYSADMINACCOUNTS=<Zugang> /SAPWD=<starkes_Passwort>

Für Details und Fehlerbehebung, siehe How to Rebuild System Databases in SQL Server 2008.

Microsoft Exchange Server

Exchange-Sicherung schlägt mit VSS-API-Fehler aufgrund eines fehlenden Microsoft Exchange VSS-Writers fehl

Problem

Bei der Sicherung von Exchange schlägt die Sicherung fehl, weil der für die Sicherung erforderliche Microsoft Exchange VSS-Writer nicht vorhanden ist. Der folgende Fehler tritt auf:

sbc-1178: Error:   VSS API error: 
CVssServer::CreateSnapshot: No volume could be determined.
sbc-1146: Error:   
DB Module: [BackupProcessing: For the specified backup source no volumes could be 
determined. Sources - \Microsoft Exchange Writer]
sbc-3052: Info:    
Items processed correctly: [0]. Not processed or incorrectly processed items: [0]. 
(SF20160503083743700@BLljg0gnWAa)
sbc-1156: Error:   Operation failed!
sbc-3001: Info:    Exiting.

Dieser Fehler tritt auf, wenn ein oder mehrere für die Sicherung erforderliche Writer fehlen oder nicht verfügbar sind. Beachten Sie, dass dies nicht dasselbe ist wie ein VSS-Fehler oder ein fehlgeschlagenes VSS. Im letzteren Fall prüfen Sie bitte Häufige VSS-Probleme.

Ein Writer gilt als fehlend, wenn das Microsoft-Kommandozeilentool vssadmin list writers (als Administrator) keinen verfügbaren Microsoft Exchange VSS-Writer anzeigt. Wenn ein VSS-Writer fehlt, schlagen alle Sicherungen fehl, die diesen Writer für die Erstellung von VSS-Snapshots verwenden. Ein fehlender Writer ist ein Fehler des Windows-Betriebssystems. Um dieses Problem zu beheben, muss die Windows-Registrierung bearbeitet werden. SEP sesam kann keine Daten sichern, bis die erforderlichen VSS Writer verfügbar sind.

Lösung

Anmerkung

SEP sesam ist nicht verantwortlich für Probleme, die durch die Bearbeitung der Windows-Registrierung entstehen. Beachten Sie, dass nur Experten die Registrierung bearbeiten sollten, da die falsche Verwendung des Windows-Registrierungseditors zu ernsthaften Problemen führen kann, wie z.B. dass Windows nicht mehr funktioniert. Für weitere Informationen zur Bearbeitung der Windows-Registrierung siehe Windows registry information for advanced users. Es wird empfohlen, die Registrierung zu sichern, bevor Sie Änderungen daran vornehmen. Es wird auch empfohlen, das folgende Verfahren außerhalb der Arbeitszeiten durchzuführen, da es einen Neustart des Microsoft Exchange Information Store-Dienstes erfordert.

Um den Microsoft Exchange VSS-Writer zu aktivieren, öffnen Sie auf dem Exchange-Server die Registrierung und bearbeiten Sie sie mit dem folgenden Schlüsselwert:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\
"Disable Exchange Writer" DWORD=0

Wenn der Schlüssel bereits mit dem Wert 1 vorhanden ist, ändern Sie den Wert in 0. (Der Wert 1 deaktiviert den Microsoft Exchange Writer.) Weitere Informationen zum Aktivieren des VSS Exchange Writers finden Sie unter How to turn on the Exchange writer for the Volume Shadow Copy service (Der Artikel ist als relevant für Windows Small Business Server 2003 gekennzeichnet, das Verfahren kann aber auch auf spätere Versionen angewendet werden).

Starten Sie dann den Microsoft Exchange Information Store-Dienst neu:

1. Melden Sie sich am Exchange-Server an und klicken Sie auf Start.
2. Geben Sie services.msc in das Suchfeld ein, und drücken Sie Enter. Das Fenster Dienste wird geöffnet.
3. Klicken Sie in der Liste der Dienste mit der rechten Maustaste auf den Dienst Microsoft Exchange Information Store (MSExchangeIS) und dann auf Neu starten. Beachten Sie, dass während des Neustarts die Verbindung der Benutzer zu Exchange getrennt wird.

Geben Sie nach dem Neustart von Exchange in der Eingabeaufforderung vssadmin list writers ein und überprüfen Sie, ob die VSS-Writer aufgelistet sind. Führen Sie dann Ihre Exchange-Sicherung erneut aus.

Exchange Protokolltrunkierungsfehler

Problem

Die Exchange-Protokolle werden nicht abgeschnitten oder die Protokolldateien fehlen.

Ursache

Exchange Datenbank-Protokolltrunkierung ist Teil der Exchange Dienste. SEP sesam benachrichtigt Exchange Writer über jede erfolgreiche Sicherung von Exchange Server und Exchange DAG-Knoten. SEP sesam verwaltet oder löscht keine Exchange Protokolle und ist daher nicht für das Abschneiden von Protokollen verantwortlich, sondern Microsoft Exchange Writer. SEP sesam benachrichtigt Exchange nur über den Status der Sicherung und dann:

• In Konfigurationen ohne DAG schneidet der Exchange Writer die Transaktionsprotokolldateien nach einer erfolgreichen vollständigen oder inkrementellen Sicherung ab.
• In DAG-replizierte Konfigurationen wird die Protokollkürzung vom Replikationsdienst verzögert, bis alle erforderlichen Protokolldateien in alle anderen Kopien übertragen wurden. Der Replikationsdienst löscht die gesicherten Protokolldateien sowohl aus dem Pfad der aktiven als auch aus dem Pfad der kopierten Protokolldateien, nachdem er überprüft hat, dass die Protokolldateien erfolgreich auf die kopierte Datenbank angewendet wurden und dass sowohl die aktive Datenbank als auch die Datenbankkopien den Checkpoint für die zu löschenden Protokolldateien passiert haben.

⇒ Lösung

Um zu überprüfen, ob die Exchange-Protokollkürzung aufgerufen wurde, überprüfen Sie die Anwendungs- und Dienstprotokolle und suchen Sie nach Fehlern im Zusammenhang mit dem Exchange VSS- oder Replika-Writer.

Überprüfen Sie ESE-Ereignisse mit ID:

• 224: Dieses Ereignis zeigt an, dass Protokolle gelöscht werden, und gibt die zugehörige Datenbank an.
• 225: Dieses Ereignis zeigt an, dass keine Protokolle für die Trunkierung verfügbar sind (entweder kann ESE nicht feststellen, ob die Transaktionsprotokolldateien an die Exchange Server-Datenbank übergeben wurden, es sind nicht genügend Protokolle vorhanden oder die zirkuläre Protokollierung ist aktiviert).
• 299: Der Replikationsdienst schneidet den Protokollstrom ab und entfernt nicht mehr benötigte Transaktionsprotokolle (oder meldet, dass die Mindestmenge an Protokollen für die Abschneidung nicht ausreicht).

Wenn die Exchange-Konfiguration eine DAG verwendet, kann der Replikationsprozess zwischen den verschiedenen Knoten im Falle von Fehlern ein Abschneiden des Protokolls verhindern. Diese Fehler werden mit der Ereignisquelle MSExchangeRepl angezeigt.

Nachfolgend finden Sie einige Einträge aus dem Anwendungsprotokoll in der Ereignisanzeige (eine Liste der Fehler finden Sie im Microsoft-Artikel MSExchangeRepl Errors and Events):

· Event ID 224 (ESE) MDB01 deleting log files C:\ExchVols\MDB01\Log Files\E0000000001.log to C:\ExchVols\MDB01\Log Files\E000000002B.log.
· Event ID 225 (ESE) MDB01—no log files can be truncated; will be logged instead of Event ID 224 when circular logging is used.
· Event ID 2046 (MSExchangeRepl) VSS writer has successfully completed the backup of database MDB01.
· Event ID 2006 (ESE) MDB01 shadow copy completed successfully.
· Event ID 2033 (MSExchangeRepl) VSS writer has successfully processed the backup completion event.
· Event ID 2037 (MSExchangeRepl) VSS writer backup has been successfully shut down.

Wenn Fehler in Verbindung mit dem Exchange VSS oder Replica Writer auftreten, überprüfen Sie die Exchange Konfiguration, um die Ursache zu ermitteln und die Fehler zu beheben. Solche Fehler können nicht von SEP sesam verursacht werden, aber bis sie behoben sind, kann Exchange die Protokolldateien nicht abschneiden, was dazu führt, dass das Volume oder die Festplatte, auf der sie sich befinden, gefüllt wird.

Überprüfen Sie auch den aktuellen Status des VSS-Writers, indem Sie Folgendes an einer administrativen Eingabeaufforderung auf dem Exchange-Server ausführen:

   vssadmin list writers

Wenn der Writer fehlt oder in einem fehlgeschlagenen Zustand ist, starten Sie den Exchange Server neu und überprüfen Sie, ob er nun aufgelistet ist und als stabil angezeigt wird. Starten Sie dann den SEP sesam Exchange Sicherungsauftrag neu und überprüfen Sie die Protokollkürzung.

Exchange Recovery Pro fragt nach einer License

Wenn Sie Exchange Recovery Pro das erste Mal gestartet haben, werden Sie aufgefordert, die Lizenz zu installieren. Wenn Sie mehrere verschiedene Windows-Benutzer verwenden, erhalten Sie diese Aufforderung für jeden Benutzer.

NetWare

Überprüfen der Erreichbarkeit der TSA Dienste

Problem 1

• Ermitteln aller verfügbaren TSA auf den NetWare/OES Server.

⇒ Lösung

• Auf einem native NetWare Server (das sbc_smdr Kommando muss auf einem OES Linux Server mit installiertem sesam-novell-client Paket (bis OES2015) oder auf einem OES2018 Server (sesam-novell-client ist bereits im SLES 12 Client Paket enthalten) ausgeführt werden:

 #> /opt/sesam/bin/sesam/sbc_smdr -D -N "nw1:::admin.admins.mydomain:novell:0" "/NetWare"
 2007-03-21 16:42:50: sbc-3500: Info:     ::/NetWare
 2007-03-21 16:42:50: sbc-3036: Info:     
 # @(#)SESAM BACKUP CLIENT FOR NETWARE FILE SYSTEMS, VERSION: 1.8R3 
 Build: 1.161 20070320 17:31:00 Linux i386 abas #
 2007-03-21 16:42:50: sbc-3074: Info:     Backup start time [20070321164250]
 2007-03-21 16:42:50: sbc-3500: Info:     Starting Session "SESAM SBC_NLM Session" ...
 2007-03-21 16:42:52: sbc-3500: Info:     NW1.NetWare File System 
 "NW1.NetWare File System" d_ 2000.01.01 00:00:00 2000.01.01 00:00:00 4096 - ,
 2007-03-21 16:42:52: sbc-3500: Info:     NW1.Novell Directory 
 "NW1.Novell Directory" d_ 2000.01.01 00:00:00 2000.01.01 00:00:00 4096 - ,

In diesem Fall, ist der TSAFS (NW1.NetWare File System) und der TSANDS (NW1.Novell Directory) geladen.

• Auf einem OES(2)-Linux server:

 #> /opt/sesam/bin/sesam/sbc_smdr -D -N "oesnix1::oesnix1:backup:novell:0" "/NetWare"
 2007-03-21 15:55:01: sbc-3500: Info:     ::/NetWare
 2007-03-21 15:55:01: sbc-3036: Info:     # @(#)SESAM BACKUP CLIENT FOR NETWARE FILE SYSTEMS, VERSION: 1.8R3 Build: 1.161 20070320 17:31:00 Linux i386 abas #
 2007-03-21 15:55:01: sbc-3074: Info:     Backup start time [20070321155501]
 2007-03-21 15:55:01: sbc-3500: Info:     Starting Session "SESAM SBC_NLM Session" ...
 2007-03-21 15:55:01: sbc-3500: Info:     OESNIX1.GroupWise System 
 "OESNIX1.GroupWise System" d_ 2000.01.01 00:00:00 2000.01.01 00:00:00 4096 - ,
 2007-03-21 15:55:01: sbc-3500: Info:     OESNIX1.Linux File System
 "OESNIX1.Linux File System" d_ 2000.01.01 00:00:00 2000.01.01 00:00:00 4096 - ,

Der TSAFSGW (OESNIX1.GroupWise System) und der TSAFS (OESNIX1.Linux File System) sind geladen.

Problem 2

• Ermitteln der verfügbaren Quellen (Ressourcen) der TSA (Target Service Agents).

⇒ Lösung

• In Abhängigkeit der installierten Dienste sind die folgenden TSA sichtbar:
  • NetWare File System
  • Linux File System
  • GroupWise System
  • Novell Directory
  • iFolder Store
  • Linux Cluster File System
  • NetWare Cluster File System

	Hinweis
	Für die Aktivierung des TSA Debug Modes siehe Enabling the Debug Options in TSAFS on OES Linux.

Durchsuchen und Sichern eines NetWare Servers ist nicht möglich

Problem

• Es ist nicht möglich die verfügbaren TSA (Filesystem, Groupwise etc.) eines NetWare Servers zu durchsuchen oder über diese verfügbare Daten zu sichern.

Mögliche Ursachen

• Kein TSA auf den NetWare Server geladen
• falscher Data Mover Server gewählt (kein OES Linux oder SMDRD nicht geladen)

⇒ Lösung

• Neustart des Filesystem TSA mittels unload TSAFS und load TSAFS.
• Änderung der Eigenschaften des NetWare Server Clienten im SEP sesam und Anpassung des Data Mover Servers auf dem NetWare Access Reiter.

Beim Einsatz von OES 2018 SP2 mit SMDR/TSA kann die TSA-Sicherung fehlschlagen

Problem

• Beim Einsatz von OES 2018 SP2 mit SMDR/TSA gibt es folgendes Problem (MicroFocus Bug):

Wenn zwei TSA Module (z.B. tsafs und tsands) über die smdr.conf geladen werden, dann funktioniert einer der beiden nicht. Unter Umständen schlägt dann die Sicherung über TSA fehl.

⇒ Workaround

• Nur ein TSA-Modul über die smdr.conf starten, das andere Modul sollte manuell später geladen werden. Da dieser Fehler auf Micro Focus zurückzuführen ist, finden Sie weitere Einzelheiten in der Micro Focus Community-Ausgabe smdr on OES2018SP2 not working.

Sesam Fehlermeldung: Client returns no data

Problem

• Die folgende Fehlermeldung erscheint im /var/log/messages Log auf dem OES Linux Clienten:

 nds_nss_GetGroupsbyMember: failed to init socket, status = 0
 nds_nss_GetPwdbyName: init sock returned 0
 nds_nss_GetPwdbyName: init sock returned 0
 nds_nss_GetPwdbyName: init sock returned 0

Mögliche Ursachen

• Unvollständige oder falsche eDirectory LUM Konfiguration
• Das eDirectory Server Zerifikat des OES Servers ist ungültig/abgelaufen.

⇒ Lösung

• Korrektur der LUM Konfiguration so das eine eDirectory Authentifizierung erfolgen kann.
• Überprüfung und/oder Neuerzeugung der Server Zertifikate mittels iManager.

Fehlermeldungen während der Sicherung

Meldung 1

(0XFFFDFFD7) "Login denied".

Mögliche Ursachen

• Ungültiger Nutzer, falsches Passwort
• Das eDirectory Server Zertifikat des OES Clienten ist ungültig/abgelaufen.

⇒ Solution

• Ändern der Clienten Eigenschaften des OES Linux Clienten im SEP sesam, Anpassung der Login Parameter auf dem Reiter OES-Linux Access bzw. MicroFocus SMS.
• Überprüfung und/oder Neuerzeugung der Server Zertifikate mittels iManager.

Meldung 2

(0XFFFDFFCD) "A data stream cannot be opened." "Unable to open a data stream."

Mögliche Ursachen

• Der Nutzer hat nicht die erforderlichen Rechte, um auf die zu sichernden Daten zuzugreifen.

⇒ Lösung

• Änderung des Nutzers oder Anpassung der Rechte für den verwenderen Nutzer.

Meldung 3

(0XFFFEFFCC) "Could not write an object to NDS or write to a stream"

oder

(0XFFFEFFB1) "Connection to remote host is lost. Remote host might have disconnected."

Mögliche Ursache

• der erforderliche TSA ist nicht geladen oder der SMDRD Dienst läuft nicht.

⇒ Lösung

• Prüfung des TSA mittels opt/novell/sms/bin/smsconfig -t.

Meldung 4

(0XFFFDFFDC) "An invalid path was used."

Mögliche Ursachen

• Ein ungültiger Sicherungspfad wird verwendet oder der TSAFS wird im falschen Mode verwendet (Linux/NetWare).

⇒ Lösung

• Wurde der TSAFS im Dual Mode geladen (Linux und Netware --tsamode=dual), kann als Sicherungspfad die Linux Pfadangabe verwendet werden (z. Bsp. /media/nss/DATA).
• Die Quelle NetWare server sichert alle verfügbaren Volumes am native NetWare Server.
• "VOL-NAME:" sichert ein spezifisches Volume (der TSAFS wurde im NetWare Mode geladen --tsamode=netware).
• Der TSAFS im Linux Mode (--tsamode=linux) unterstützt nur Linux Pfad Notation path to the volumes/volumename (zum Bsp. /media/nss/DATA).
• Im Restore Fall können unzureichende Rechte auf dem Restore Ziel der Grund der Meldung sein.

Dateien sind nach der Sicherung gesperrt, der Server friert ein

Problem

• Dateien sind nach der Sicherung für mehrere Minuten gesperrt, der Server friert ein und muss über Reste neu gestartet werden.

⇒ Lösung

• Update des sesam-novell-client auf eine höhere Version.

Linux Pfad Backup ist performanter als ein Novell/MicroFocus Backup über TSAFS

Problem

• Ein Linux Pfad Backup ist schneller als ein TSAFS Backup.

⇒ Lösung

• Das Deaktivieren des TSA Caches erhöht die Backup Peformance und verringert die Systemlast.
• Editieren der Datei /etc/opt/novell/sms/tsafs.conf, Änderung der Zeile "cachingmode=enable" auf "cachingmode=disable" und Aktivierung der Änderungen durch den Reload des SMDRD mittels rcnovell-smdrd restart bzw. systemctl reload novell-smdrd.service.

Überprüfung der Performance und Verfügbarbeit der eines NSS Volumes mittels TSATEST

• Sicherung der Ressource '/' unter Verwendung der angegeben Anmeldedaten.

tsatest -u root -p unsecure

• Sicherung der Ressource /home unter Verwendung der angegeben Anmeldedaten.

tsatest --path=/home -u root -p unsecure

• Sicherung des NetWare Volumes/Verzeichnis SYS:\SYSTEM auf dem Server ACME_SERVER unter Verwendung der angegebenen Anmeldedaten.

tsatest -s ACME_SERVER -v SYS: --path=SYSTEM -u root -p unsecure

• Sicherung der Ressource '/' unter Verwendung der angegebenen Anmeldedaten und einer Puffergröße von 131072 Byte.

tsatest -b 131072 -u root -p unsecure

• Backup der Ressource '/' auf dem Server ACME_SERVER unter Verwendung der angegebenen Anmeldedaten. Wird TSATEST auf einem anderen Server als ACME_SERVER ausgeführt, erfolgt ein remote Backup vom ACME_SERVER zu dem Server, auf dem das TSATEST ausgeführt wird.

tsatest -s ACME_SERVER -u root -p unsecure

Für die Verwendung von TSATEST.NLM (native NetWare) siehe http://support.novell.com/docs/Tids/Solutions/10092890.html

Micro Focus GroupWise

GroupWise Konfigurationsdatei gwha.conf existiert nicht

Problem 1

• Groupwise Konfigurationsdatei gwha.conf ist nicht im Standardverzeichnis /etc/opt/novell/groupwise/.

⇒ Lösung

1. Kopieren Sie die Datei gwha.conf von /opt/sesam/skel/templates/ in den Ordner /etc/opt/novell/groupwise/.
2. Editieren Sie gwsep.conf und fügen Sie die folgende Zeile im Abschnitt [MISC] hinzu:

gwha=<path to gwha.conf>/gwha.conf

Zum Beispiel:

gwha=/etc/mygw/config/gwha.conf

Problem 2

• Problem mit den Bibliotheken mit externen Ablagebereichen.

⇒ Lösung

1. Kopieren Sie die Datei gwha.conf von /opt/sesam/skel/templates/ in den Ordner /etc/opt/novell/groupwise/ auf dem GroupWise-Server.
2. Fügen Sie einen Abschnitt pro externen Ablagebereich wie folgt hinzu:

 [<Name des Ablagebereichs>.<Postoffice>.<Domain>]
 home=<Pfad zum Ablagebereich>

Zum Beispiel:

 [ablage1.po1.dom1]
 home=/var/grpwise/ablage1

	Hinweis
	Die gwsep.conf Datei muss auf alle Cluster Nodes kopiert werden und angepasst werden. Auf den Cluster Nodes müssen alle gwsep.conf identisch sein.

Oracle

Testen der Oracle-Erweiterung mit sbttest unter AIX funktioniert nicht

Problem

• Das Testen der Oracle-Erweiterung mit sbttest unter AIX funktioniert nur dann, wenn der vollständige Pfad zur Bibliothek mit dem Argument -libname angegeben wird.

⇒ Lösung

• Wenn Sie sbttest unter AIX ausführen, geben Sie den vollständigen Pfad zur Bibliothek mit dem Argument -libname an, z.B.
  sbttest test1 -libname /opt/sesam/bin/sesam/libobk.so oder ... -libname $ORACLE_HOME/lib/libobk.so.

Fehler bei der Ausführung einer Sicherung unter AIX

Problem

• Die Ausführung des RMAN-Befehls auf AIX endet mit Fehlern.

⇒ Lösung

• RMAN-Befehl auf AIX erfordert, dass der vollständige Pfad zur Bibliothek im Skript über PARMS SBT_LIBRARY={full_path_to_libobk.so} gesetzt wird. Details finden Sie unter RMAN spezifische Parameter.

Die erneute Ausführung des Skripts sbttest endet mit dem Fehler Duplicate key

Problem

• Wenn das sbttest-Skript mit dem gleichen Parameter backup_file_name erneut ausgeführt wird, gibt SEP sesam den Fehler duplicate key zurück.

Ursache

• Dies geschieht, weil der sbttest beim nächsten Lauf das gleiche backup_file_name Argument verwendet. SEP sesam interpretiert backup_file_name als die save_set_id und vergleicht sie mit den IDs in der Ergebnistabelle. Wenn die gleiche save_set_id gefunden wird, gibt SEP sesam einen duplicate key Fehler zurück.

⇒ Lösung

• Achten Sie beim Ausführen von sbttestdarauf, dass das Argument backup_file_name bei jedem Durchlauf des Skripts auf einen anderen Wert gesetzt wird.

Die Ausführung eines bash-Skripts unter AIX führt zu dem Fehler bad interpreter: No such file or directory

Problem

• Wenn ein bash-Skript ausgeführt wird, wird die Fehlermeldung bad interpreter: No such file or directory angezeigt, zum Beispiel:

-sh: ./sbc_oracle_rman.sh:
/bin/bash: bad interpreter: No such file or directory

Ursache

• Unter AIX ist bash in der Regel nicht in der Liste der gültigen Shells enthalten.

⇒ Lösung

• Ändern Sie die erste Zeile in sbc_oracle_rman.sh in
  #!/bin/sh.

Die Variablen ORACLE_HOME und ORACLE_SID sind in der Benutzerumgebung nicht gesetzt

Problem

• Wenn ORACLE_HOME und ORACLE_SID nicht definiert sind, kann sich das SEP sesam Skript nicht mit der Zieldatenbank verbinden.

⇒ Lösung

Setzen Sie die ORACLE_HOME und ORACLE_SID Variablen mit einer der folgenden Möglichkeiten:

• Fügen Sie folgende Zeilen hinzu
  export ORACLE_HOME=/u01/app/oracle/product/10gR2/db_1 und export ORACLE_SID=PROD_DB.
• Verwenden Sie zum Beispiel oraenv, um die entsprechende Umgebung zu setzen:

export ORACLE_SID=TEST
export ORAENV_ASK=NO
. oraenv

SAP Oracle Fehlermeldung: "item from input file does not exist"

Problem

• Das brbackup backint Protokoll unter Windows meldet "item from input file does not exist". Die folgenden Fehlermeldungen werden angezeigt:

In backint_<SID>.log

 SSB:(3620): 121043: backint_back.c:( 331):: WARNING: item from input file does not exist: F:\ORACLE\T11\SAPDATA1\ERPUSR_1\ERPUSR.DATA1.

In sbc_<SID>.log

 SSB:(3620): 121242: backint_func.c:(1928):: 2013-06-18 12:12:42: sbc-3008: Info:    Processing item: [F:\ORACLE\T11\SAPDATA1\ERPUSR_1\ERPUSR.DATA1]...
 SSB:(3620): 121242: backint_func.c:(1928):: 2013-06-18 12:12:42: sbc-4000: Trace:   GetFileSecurityInfo: Opening file [\\?\F:\ORACLE\T11\SAPDATA1\ERPUSR_1\ERPUSR.DATA1] with CreateFileW() function failed. Error code: 1314
 SSB:(3620): 121242: backint_func.c:(1928):: 2013-06-18 12:12:42: sbc-2046: Warning: Cannot get item security data for [F:\ORACLE\T11\SAPDATA1\ERPUSR_1\ERPUSR.DATA1].

Mögliche Ursachen

• Der Benutzer, der den brbackup-Prozess startet, hat keine Berechtigung zum Zugriff auf die Sicherheitsdaten (ACL) der Datei F:\ORACLE\T11\SAPDATA1\ERPUSR_1\ERPUSR.DATA1 in Windows. Normalerweise haben nur lokale Gruppenadministratoren die Berechtigung, die SACL eines Objekts zu lesen oder zu schreiben, was durch das Privileg oder Benutzerrecht (SeSecurityPrivilege) gesteuert wird.

⇒ Lösung

• Weisen Sie den Benutzer der lokalen Administratorgruppe des SAP-Servers zu.
• Stellen Sie sicher, dass das Benutzerrecht (SeSecurityPrivilege) dem Benutzer implizit oder explizit erteilt wird.
• Es kann auch erforderlich sein, die User Account Control Settings über die Systemsteuerung auf Never notify zu setzen.

Der RMAN-Dateiname ist zu lang

Problem

• Sie bekommen folgende Warnung:

ORA-19506: failed to create sequential file, name="full_COMP1_1953897796_55938_1.bck", parms=""

Mögliche Ursachen

• Der Dateiname des vom RMAN erstellten Sicherungssatzes ist länger als 32 Zeichen. Wenn beispielsweise das Oracle-Sicherungs-Dateiformat auf das Format 'full_%d_%I_%s_%p.bck' eingestellt ist und der Parameter %s (Sicherungssatz-Nummer) in den Dateinamen integriert wird, erhöht sich die Sicherungssatznummer mit jeder Sicherung. Dies hat zur Folge, dass sich die Anzahl der Zeichen dieser Zeichenkette erhöht. Eine Erhöhung der Anzahl auf mehr als 32 Zeichen führt zu einem Fehlschlag der Sicherung.

⇒ Lösung

• Achten Sie darauf, dass die Zeichenlänge des Sicherungssatzes 32 Zeichen nicht überschreitet.

Informix

Generelle Problembehebung

• Vergewissern Sie sich, dass die folgenden Umgebungsvariablen korrekt gesetzt sind:
  • INFORMIXDIR
  • INFORMIXSERVER
  • ONCONFIG
  • ROOTPATH
• Überprüfen Sie die Nachrichten auf dem SEP sesam Server.
• Weitere Informationen können in den Protokolldateien auf ONBAR und SIB gefunden werden.
• SEP empfiehlt nur eine einzelne Protokolldatei für ONBAR und XBSA Meldungen zu verwenden. Dadurch können Sie sämtliche Aufrufe der Datenbank und des SEP sesams in der korrekten Reihenfolge sehen:

XBSA_LOGFILE=<komplette Pfad zu bar_act.log> und XBSA_TRACE=1.

• Alle SIB (sesam) Meldungen haben das Präfix SIB.
• Um weitere Informationen zu bekommen kann XBSA_TRACE auf 2 gesetzt werden, wodurch allerdings die Protokolldateien recht groß werden können.
• Um das ONBAR-Protokoll zu aktivieren fügen Sie die folgende Zeile in der onconfig-Datei ein:

BAR_DEBUG       2    \# where 'num' = 0-9; 9 producing heaps output defaults to /tmp/bar_dbug.log

Spezielle Fehlermeldungen

Beim Ausführen von oninit erscheint

Allocating and attaching to shared memory...FAILED
oninit: Fatal error in shared memory creation

⇒ Lösung

• Weitere Informationen finden Sie unter IBM Dokumentation.

Problem ixbar bei der ersten Sicherung

Begin backup of critical file 'C:\PROGRA~1\IBM\Informix\11.70\etc\ixbar.0'.
(-43078) Open or close failed on file 'C:\PROGRA~1\IBM\Informix\11.70\etc\ixbar.0', errno = 2 .

⇒ Lösung

• Erstellen Sie die fehlende Datei in C:\PROGRA~1\IBM\Informix\11.70\etc\ixbar.0.

Problem 131 bei der ersten Logical Logs Sicherung

 Unable to start the logical log backup: Log backup to device 'nul' not allowed
 ...
 C:\PROGRA~1\IBM\Informix\11.70\bin\onbar_d complete, returning 131 (0x83)

⇒ Lösung

• Die Variable LTAPEDEV in der ONCONFIG Datei muss zu einem Wert ungleich '/dev/null' oder 'NUL' gesetzt werden, z.B. LTAPEDEV \\.\TAPE0 für Windows. Siehe IBM Informix Dynamic Server LTAPEDEV.

HCL (IBM) Domino Server

Lotus Domino (ehemals Lotus Notes) wurde zunächst von IBM und dann von HCL Technologies übernommen. Der Lotus Domino-Produktname lautet nun HCL Domino Server. Die Aktualisierung der SEP sesam Dokumentation (z.B. Screenshots) bzgl. dieser Änderungen erfolgt schrittweise, so dass HCL Domino weiterhin unter dem Namen Lotus Notes, Lotus Domino oder IBM Domino erscheinen kann.

HCL Domino Server Backup meldet Wiederherstellungsfehler

Problem

• Backup meldet "Wiederherstellung kann fehlschlagen" während der Sicherung der SEP sesam Erweiterung für HCL Domino Server. Während der Sicherung erscheint die folgende Warnung für mehrere oder alle Notes Datenbanken:

sbc-2076: Warning: 
Item [D:\notus03data\mailboxes\mail1\cruoff.nsf] is not logged. 
Recovering may fail.

Mögliche Ursachen

• Dafür kann es zwei Gründe geben:

1. Die Transaktionsprotokollierung wurde nicht eingeschaltet oder befindet sich nicht im archivierten Modus.
2. Die Transaktionsprotokollierung läuft im Archiviert-Modus, ist aber für diese Datenbank in den Optionen der Datenbank ausdrücklich ausgeschaltet.

⇒ Lösung

• Diese Meldung ist eine Warnung der Notes Backup API und wird nur von SEP sesam weitergeleitet. Schalten Sie die Transaktionsprotokollierung generell oder nur für diese Datenbank ein.

Andernfalls kann die Meldung ignoriert werden. Die Warnung wird während des Backups aus Sicherheitsgründen ausgegeben, da nur der Administrator entscheiden kann, ob ein administrativer Eingriff erforderlich ist.

Unzureichender temporärer Speicherplatz

Problem

• Der temporäre Speicherplatz reicht unter Umständen nicht aus, da jede Datenbank zunächst auf den Client kopiert werden muss.

⇒ Lösung

• Ändern Sie den Pfad gv_rw_tmp in <SESAM_VAR>/ini/sm.ini in ein Verzeichnis mit ausreichend Platz.

Transaktionsprotokollierung nicht aktiv

Problem

• Die INCR-Sicherungen schlagen fehl.

⇒ Lösung

• Aktivieren Sie die Transaktionsprotokollierung im Modus Archiviert für Notes.

Bereits in Arbeit befindliche Transaktionsprotokolle

Problem

• Diese Meldung erscheint im SEP sesam:

DB Module: [Archiving of transaction logs already in progress.]

Mögliche Ursachen

• Die HCL Domino API sendet diese Meldung, um anzuzeigen, dass sich die Transaktionsprotokolle bereits im Status "Backup" befinden. Der Status kann nicht zweimal gesetzt werden. Wenn ein Backup nicht erfolgreich abgeschlossen werden konnte, wird dieser Status angezeigt.

⇒ Lösung

• Um den Backup-Status zu beenden, sollten alle logasio-Prozesse aus dem Notes-System entfernt werden:

 UNIX:     killall -9 logasio
 WINDOWS:  sm_kill logasio

• Alternativ dazu können Sie den Notes-Server neu starten.

Das Backup meldet falsche Transaktionsprotokollierung

Problem

• Nach der Wiederherstellung der Transaktionsprotokollierung meldet Notes eine falsche Transaktionsprotokollierung.

⇒ Lösung

• Löschen Sie die nlogctrl.* Dateien im Protokollverzeichnis und starten Sie den Notes-Server neu.

Server fails to restart after a Notes server crash

Problem

• After a crash of the HCL Domino server, the server cannot be started without rebooting.

⇒ Lösung

• If a server crash occurs during a log backup ,logasio processes may remain active. These processes must be stopped. The server can be restarted after running the following command:

 UNIX:     killall -9 logasio
 WINDOWS:  sm_kill logasio

Backup with missing options

Problem

• The restore of Notes on a Linux client ends with:

 "RESTORE STATUS: Restore failed. 2007-05-02 08:52:32:
  sbc-1146: Error:    DB Module: [Notes API NotesInitExtended() failure"

Possible causes

• The restore options are not identical to the backup options.

⇒

Solution

• Set the restore options according to the task. Additionally, the options can be set in the restore wizard under Expert options in the Options tab. For example:

 -v 3 -a USER=nadmin -a NOTESINI=/srv/notedata/notes.ini

Abnormal termination of the sbc.exe process

Problem

• HCL Domino Console repeats: "C:\..\SEPSesam\bin\sesam\sbc.exe Process has terminated abnormally".

Mögliche Ursachen

• If there is a backup failure that causes the SEP sesam backup client to terminate abnormally, the failure will be noticed by the HCL Domino server API and repeat this error message every minute in its logging.

⇒

Solution

• Stop the Domino server forcibly by running nsd -kill.

Restoring Notes database files to different location doesn't work

Problem

• When doing a restore of database files as a Notes restore to a different file location under Notes_Data, all databases are skipped.

Possible causes

• Notes denies an access to an existing database with the same replica-id, e.g.:

Item [\JOBSCHED.NJF] not included. Skipped...

⇒ Lösung

• In the SEP sesam restore wizard, select a file location outside of Notes_Data and store the database file there. This makes it possible to copy the file to the Notes data directory structure.

VMware vStorage API

Sicherung

Virtuelle Maschinen, die sich auf einem NFS-Speicher befinden, reagieren während einer Sicherung nicht

Problem

• Bei der Verwendung von NFSv3 zum Mount von NFS-Datenspeichern und der Durchführung von VMware-Sicherungen im HotAdd-Transportmodus ist die zu sichernde VM ca. 30 Sekunden lang nicht erreichbar, wenn der HotAdd-Datamover das VMDK entfernt.

Ursache

• Dieses Problem tritt auf, wenn die Ziel-VM und der Datamover auf zwei verschiedenen Hosts (ESXi) ausgeführt werden und das NFSv3-Protokoll für den Mount von NFS-Datenspeichern verwendet wird.

⇒ Lösung

• Um dieses Problem zu vermeiden, müssen der VMware Datamover und die VM auf demselben ESXi laufen.
• Verwenden Sie das NFSv4-Protokoll, um einen Mount auf den NFS-Datenspeicher zu erstellen.

VMware vSphere-Sicherung unter Linux schlägt aufgrund eines VDDK-Fehlers fehl

Problem

• Eine VMware vSphere Sicherung (auf dem SEP sesam Server oder RDS) unter Linux schlägt mit folgendem Fehler fehl:

Load VDDK library failed: Cannot load: libvixDiskLib.so

Ursache

• Das VMware Virtual Disk Development Kit (VDDK) ist nicht installiert.

VMware-Sicherung oder das Durchsuchen des VMware vCenter schlägt aufgrund einer Java VM-Sicherheitseinschränkung fehl

Problem

• VMware-Sicherung oder das Durchsuchen des VMware vCenter schlägt fehl mit dem folgenden Fehler:

Error:   VM Exception: [VI SDK invoke exception:javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints].

Ursache

• Aufgrund von erweiterten Sicherheitseinstellungen lässt die virtuelle Java-Maschine keine Verbindung zu VMware vCenter zu.

⇒ Lösung

• Um die Sicherheitsbeschränkung der virtuellen Java-Maschine zu umgehen, gehen Sie wie folgt vor:

1. Auf Ihrem SEP sesam Server finden Sie die folgende Datei im Java-Installationsverzeichnis:

 JDK_HOME/jre/lib/security/java.security

2. Ändern Sie die Zeile

    jdk.certpath.disabledAlgorithms=MD2, RSA > 1024

   in

    jdk.certpath.disabledAlgorithms=

3. Starten Sie anschließend den SEP sesam Dienst neu.

Segmentierungsfehler bei der VMware-Sicherung auf Linux-basiertem Datamover

Problem

• Die VM-Sicherung auf einem Linux-basiertem Datamover schließt erfolgreich ab, jedoch wird ein Segfault-Ereignis aufgezeichnet.

Ursache

• Dies ist das VMware-Bibliotheksproblem, das durch das fehlende Verzeichnis /sys/class/scsi_disk auf dem Linux-System verursacht wird.

⇒ Lösung

• Bevor Sie die VMware-Sicherungen auf einem Linux-basiertem Datamover ausführen, laden Sie mit dem modprobe-Befehl modprobe sd_mod das Kernelmodul sd_mod und machen Sie das Verzeichnis /sys/class/scsi_disk verfügbar.

Langsame VMware Sicherungsleistung über NBD. ODER: Sicherungen schlagen im SAN-Transportmodus mit VMs fehl, die sich auf VMFS 6.0 befinden

Problem

• Langsame Sicherungsleistung über NBD. Ein weiteres Problem ist, dass Sicherungen im SAN-Transportmodus fehlschlagen können.

Ursache

• vSphere 6.5 und 6.7 haben möglicherweise eine langsame Sicherungs-Performance über NBD mit VDDK 6.0.x aufgrund der VMware-Richtlinie zur Abwärts- und Vorwärtskompatibilität für VDDK zur Unterstützung von N-2- und N+1-Versionen.

• Mit vSphere 6.5 bietet keine der VDDK 6.0.x-Versionen Unterstützung für den SAN-Transport bei Verwendung von Datenspeichern, die mit dem neuen VMFS 6.0-Dateisystem formatiert sind. Folglich schlägt die Sicherung fehl.

⇒ Lösung

• Unter Windows wird VDDK automatisch während der SEP sesam Installation installiert. Wenn Sie jedoch eine neue vSphere-Version verwenden, sollten Sie in der VDDK Kompatibilitätsmatrix nach der entsprechenden VDDK-Version suchen und sie bei Bedarf manuell installieren.
• Unter Linux müssen Sie die erforderliche VDDK-Version manuell installieren. Beachten Sie, dass jede neue Version von vSphere eine entsprechende VDDK-Version hat. Normalerweise entspricht die Versionsnummer von VDDK der Versionsnummer von vSphere.

Einzelheiten zur erforderlichen Version finden Sie in VDDK Kompatibilitätmatrix.

VMware-Sicherung schlägt mit einem Fehler aufgrund einer nicht erkannten erweiterten LUN fehl, die mit einem Linux-Datamover verbunden ist

Problem

• VMware Sicherung schlägt fehl, z.B. mit:

Error while reading data. Error: VixDiskLib: VixDiskLib_Read: Read 2048 sectors at 0 failed. Error 16000 (One of the parameters supplied is invalid) (DiskLib error 4096062: One of the parameters supplied is invalid) at 5024.

Ursache

• Wenn Sie auf dem Linux Datamover in VMware-Umgebungen eine LUN erweitern, während Sie online sind (ohne Ihr Linux-System neu zu starten), wird die erweiterte LUN nicht sofort vom Linux-Betriebssystem aus sichtbar. Unter Windows wird die erweiterte Festplatte automatisch angepasst, während Sie unter Linux den SCSI-Bus manuell neu scannen müssen. Infolgedessen wird die Sicherung fehlschlagen.

⇒ Lösung

• Um den SCSI-Bus unter Linux erneut zu scannen, ohne ihn neu zu starten, verwenden Sie den folgenden Befehl, wenn Sie eine neue Platte hinzufügen (X ist die Nummer des zu scannenden SCSI-Hosts):

echo  “- – -” > /sys/class/scsi_host/hostX/scan

• Verwenden Sie den folgenden Befehl, wenn Sie einen vorhandenen Datenträger erweitern möchten:

echo 1 > /sys/class/scsi_device/device/rescan

Einzeldateirücksicherung

Mount des VMware-Sicherungssatzes unter Linux schlägt fehl

Problem

• Der Mount des VMware Sicherungssatzes (auf dem SEP sesam Server oder RDS) schlägt unter Linux z.B. mit folgendem Fehler fehl:

Client mount tools not installed

Ursache

• Das guestmount-Tool ist auf dem Linux-Host nicht installiert.

⇒ Lösung

• Um auf das Dateisystem eines Images unter Linux zugreifen und einen Mount einrichten zu können, müssen Sie die guestfs-Tools verwenden. Installieren Sie das Paket guestfs-tools wie in Installation der guestfs-Tools unter Linux beschrieben.

Einzeldateirücksicherung funktioniert nicht mit VMware 6.0

Problem

• Bei der Einzeldateirücksicherung unter VMware 6.0 schlägt die Rücksicherung fehl mit: Cannot open Thin/TBZ disks in a multiwriter mode.

Dieses Protokoll wird auch in den vCenter-Ereignissen angezeigt.

Ursache

• Dieser Fehler tritt auf, wenn der SCSI-Bus-Sharing-Typ auf dem Proxy-Rechner auf Physical (Physisch) eingestellt ist.

⇒ Lösung

• Fahren Sie die Proxy-Maschine herunter und ändern Sie den Typ des SCSI-Bus Sharing auf Keine, damit die virtuellen Festplatten nicht von anderen virtuellen Maschinen freigegeben werden können.

Bei einer Einzeldateirücksicherung kann SEP sesam nicht auf den Speicher einer VM zugreifen, die mit dem SCSI LSI Logic SAS Adapter konfiguriert ist

Problem

• In SEP sesam Version ≥ 4.4.3.48 in Kombination mit einer Linux-Proxy-VM werden bei der Auswahl der Rücksicherungsquelle im Rücksicherungsassistenten (Schritt 4: Dateiauswahl) keine Elemente im Browser angezeigt.

Ursache

• Dieses Problem scheint mit dem SCSI-Controller der Proxy-VM zusammenzuhängen. Wenn Sie versuchen, eine einzelne Datei aus einer virtuellen Maschine rückzusichern, kann SEP sesam nicht auf den Speicher einer virtuellen Maschine zugreifen, die mit dem SCSI LSI Logic SAS Adapter konfiguriert ist.

⇒ Lösung

• Öffnen Sie die Eigenschaften der Proxy-VM in Ihrem vCenter und ändern Sie den Controller auf der VM vom LSI Logic SAS Controller (bei einigen VMs ist dieser standardmäßig ausgewählt) in einen LSI Logic Parallel Controller.

Weitere Informationen finden Sie in der VMware Dokumentation unter Change the SCSI Controller Type in the vSphere Client.

• Starten Sie den Rücksicherungsassistenten neu. Wenn im Rücksicherungs-Browser immer noch keine Elemente angezeigt werden, starten Sie die Proxy-VM neu und klicken Sie dann auf die Schaltfläche Aktualisieren.

Nach dem Update einer bestehenden SEP sesam Struktur mit einer neuen VDDK Version ist es nicht mehr möglich, einen Mount auf eine VMDK zu einzurichten

Problem

• Nachdem VDDK ≥ 6.5.x manuell auf Windows installiert wurde, ist es nicht mehr möglich, einen Mount des VMDK-Sicherungssatzes auf diesem Host zu erstellen.

Ursache

• Wenn eine andere VDDK-Version, z. B. VDDK ≥ 6.5.x, manuell auf Windows installiert wird, erfordert der Host nach dem Update einen Neustart, wenn Sie einen Mount der VMDK auf diesem Host einrichten möchten.

⇒ Lösung

• Starten Sie den Host nach dem VDDK-Update neu und führen Sie dann das folgende Skript von der Befehlszeile aus:

vstor2install.bat im Verzeichnis C:\Program Files\VMware\VMware Virtual Disk Development Kit\bin

Citrix XEN Server

Error when using quiesced snapshots

Problem

• Using VM.snapshot_with_quiesce method fails in Citrix Hypervisor ≥ 8.1 or in the version ≥ 9.0.x.x drivers.

Cause

• VSS and quiesced snapshots of Windows VMs capability have been removed in Citrix Hypervisor ≥ 8.1 and in the version ≥ 9.0.x.x drivers. They are only supported in Citrix Hypervisor ≤ 8.0.

⇒ Lösung

If you want to continue using the quiesced snapshot feature with Windows VMs hosted on Citrix Hypervisor 8.0 and earlier, do not update to the 9.0.x.x drivers.

CBT backup fails because Xen Server TLS certificate contains wrong IP address

Problem

• CBT backup fails with the NBD client connection error:

Failed to get NBD client for device '******: NBD client connection error: hostname '****' doesn't match u'******

Cause

• The TLS certificate of a Xen Server contains the wrong IP address. Therefore no NBD session can be established.

⇒ Lösung

• Check all Xen Servers in the Pool whether the IP address in the certificate matches.
• On the Xen Server where it does not match, execute the following commands:

1. Create a backup of the existing certificate by using

mv /etc/xensource/xapi-ssl.pem /etc/xensource/xapi-ssl.pem.$(date -u +%Y%m%d)

2. Create a new certificate

/opt/xensource/libexec/generate_ssl_cert /etc/xensource/xapi-ssl.pem <ip-address or FQDN> 

3. Restart XenAPI service

systemctl restart xapi

4. Restart NBD Service

systemctl restart xapi-nbd 

Message "Upload to URL ... failed" appears during restore, "insufficient space" error occurs during backup

Problems

• Restore fails with an error:

"Upload to URL ... failed."

SR_BACKEND_FAILURE_44: : There is insufficient space to create snapshot on Storage Repository. 

Mögliche Ursachen

• There is not enough space available on the default storage.
• If the "insufficient space" error occurs during the backup, it might be related to the snapshot process. XenServer was unable to create a snapshot for the VM because there was not enough space in your Storage Repository.

⇒ Lösung

Use XenCenter to select another default storage that has enough free disk capacity to store the virtual disk(s).

Other issues

• Some errors are not reported in detail by XEN API. More information can be found in XenServer in /var/log directory.
• In some pool configurations all pool members must have their management interface listed in DNS.
• If the settings below don't agree on asynchronous routing and connection drops and/or 3 second or 80 second delays, opening sockets may occour. This is very similar to having 2 network cards configured with ipv4 to the same subnet and connected to the same switch.
• If you use Cisco switches and you have configured (Citrix unsupported) lacp bonding 802.3ad, it is very important that both sides agree on the balancing type. The Linux default is layer2 and the Cisco default is layer3+4.
• Check the bonding mode on the host with cat /proc/net/bond/bond* for bonding mode:

IEEE 802.3ad Dynamic link aggregation

Transmit Hash Policy: layer2 (0) or Transmit Hash Policy: layer3+4 (1).

• Users have reported that this command and a reboot solves the problem, but this cannot be formally recommended due to its untested and unsupported status:

xe pif-param-set uuid=${UUID_OF_BOND_PIF} other-config:bond-xmit_hash_policy=1 

• In the common situation where 802.1ad with xmit_hash_policy=1 and STP are in use, multiple settings need to be adjusted on the Cisco side according to the article Considerations for Connecting XenServer to the Switch Ports.
• Most other network related performance and reliability issues can be resolved with Considerations for Connecting XenServer to the Switch Ports.
• In some situations when using thin storage repositories, an sr rescan is necessary to re-detect free space before a backup or restore.

SAP HANA

After initial configuration the first test backup out of the HANA Studio shows errors

Problem

• Once you configured SAP HANA to work with SEP sesam and start the first test backup, it finishes with errors.

Cause

• There might be an issue with case sensitive file paths, written in the /var/opt/sesam/var/ini/backint_saphana.utl files.

⇒ Lösung

Open the /var/opt/sesam/var/ini/backint_saphana.utl files and make sure that the directory names are listed in the appropriate case (lower case or upper case respectively).

===

SAP HANA backup fails as sbc_hana.sh tries to back up SAP HANA DB on a secondary system===

Problem

• sbc_hana.sh does not recognize the secondary SAP HANA server as the secondary system and attempts to back up the SAP HANA database. Backup fails with error Connection refused.

Cause

• The secondary SAP HANA DB cannot be backed up as it permanently synchronizing data with the primary SAP HANA DB. Only the primary system is able to access the database when the database is running in SYNC mode. Therefore accessing the secondary system and running the backups on the replication target will fail.

⇒ Lösung

Manually switch to the primary host in the command event. For details, see Scheduling start of the SAP HANA script.

Not enough streams for SAP HANA external backups

Problem

• SAP HANA external backups can no longer be performed due to the following error:

2018-07-26 08:04:35 W007-SBC_COM[  6664]: Timeout reached, drive group HANA has no free streams anymore

Cause

• There are not enough streams available to run SAP HANA external backups.

⇒ Lösung

In the data store properties, check the available streams per drive (by default, 5) and adjust them to 20.

SAP HANA backups are not started anymore

Problem

• After a while SAP HANA backups are not starting.

⇒ Lösung

• Connect to the SAP HANA server and stop the client:

1. /opt/sesam/bin/sesam/sm_main stop
2. ps –ef | grep sm_sbc*
3. Search for old sm_sbc* services and kill these services.
4. Start the SEP sesam Client again with the command /opt/sesam/bin/sesam/sm_main start.

Backup finished with error [447]

Problem

• Backup failed with error.

YYYY-MM-DDTHH:MM:SS+00:00  P11252      1480e025c70 ERROR   BACKUP   SAVE DATA finished with error: [447] backup could not be completed, [110507] Backint exited with exit code 1, Traceback (most recent call last):
 File "/usr/local/sesam/lib/python2.7/site-packages/cx_Freeze/initscripts/Console.py", line 27, in <module>
 File "backint_saphana.py", line 124, in <module>
 File "sm_common.py", line 55, in __init__
IOError: [Errno 13] Permission denied: '/var/opt/sesam/var/log/lgc/sbc_backint_NOT DEFINED.log'

Cause

• The hdbbackint does not have the permissions to write to the logging directory.

⇒

Solution

• Execute chmod 755 (directory) to fix the issue.

===

SAP HANA backup failure – analyze log files for cause ===

Problem

• Backup was unsuccessful and is shown with a red dot in either the SAP HANA Studio or the SEP sesam GUI.

⇒ Lösung

• Go to /var/opt/sesam/var/log/lgc and search for the hdbbackint_SID.log or hdbbackint_SID_log.log. These logs contain the logging information for the data connections to the SEP sesam Server and Remote Device Server (if used).

On the SEP sesam Server/RDS, <sesam_install>/var/log/sms will contain stpd_pid.log and stpd_pid.com.log files with the server-side logging information. Additional log information on the SEP sesam Server can also be found in <sesam_install>/var/log/lgc in sm_sbc_com*.log files.

Job status displays multiple running jobs

Problem

• Even though only a single backup or restore is running, multiple jobs are displayed in the Job Status view of the SEP sesam GUI.

⇒ Lösung

This is the usual behaviour. When performing a backup, HANA bundles the data to be saved into a few separate save sets and sends them to the SEP sesam device server. Therefore, multiple jobs will be displayed in the job status. The same in reverse applies to restores.

Log backups running too frequent

Problem

• Log backups are processed every 15 minutes. The time among log backups should be extended.

⇒ Lösung

Open the backup configuration in the SAP HANA Studio. On the right, there is a box where the interval can be adjusted. But be careful: The log area will grow bigger. If the log area is full, the database will stop performing transactions!

After recovery the hardware key changed

Problem

• After a bare metal recovery or full recovery, the hardware key is changed and the license is dropped.

⇒ Lösung

• This is a known issue which can occur even if there is no change in the hardware and hostname with the same configuration: re-installation, restore, recovery, or rename will change the hardware key. Please contact SAP support. For details, see Hardware Key for the HANA Database.

SAP ASE

SAP ASE Sicherung schlägt fehl mit Requested server name not found (Angeforderter Servername nicht gefunden)

Problem

• SAP ASE Sicherung schlägt fehl mit CT-LIBRARY error: ... Requested server name not found.

Ursache

• Der Servername wurde nicht in die Schnittstellendatei aufgenommen oder der angegebene Servername existiert nicht.

Anmerkung

• Wenn als Quelle {Server_name} angegeben ist, haben Sie wahrscheinlich den Servernamen oder den Serverport (Standardwert 5000) falsch eingegeben.
• Wenn die Quelle ohne {Server_name} gesetzt ist, sucht isql nach dem Server, der durch Ihre DSQUERY-Umgebungsvariable angegeben ist.

⇒ Lösung

• Sie müssen die Quelle um den korrekten Servernamen und ggf. auch den Port erweitern.

Quellenformat [/{Server_name}[:{Port}]]/{Datenbank}

Wenn die Quelle zum Beispiel master ist, müssen Sie den Servernamen als ersten Teil hinzufügen, z.B. /SOL/master oder /SYBASE16:5000/master.

• Testen Sie die Verbindung zum SAP ASE Server, indem Sie das isql Utility ausführen. Einzelheiten finden Sie unter SAP ASE Utility Guide: isql.

isql -U<Benutzername> -P<Passwort> -S<Servername>

wobei <Benutzername> den Login-Namen eines Benutzers mit Zugriff auf die Datenbank angibt (Groß- und Kleinschreibung beachten!), <Passwort> Ihr SAP ASE-Passwort und <Servername> den Namen des SAP ASE-Servers enthält, zu dem eine Verbindung hergestellt werden soll. isql sucht diesen Namen in der Schnittstellendatei.

Wenn dieser Test fehlschlägt, verwenden Sie das Dienstprogramm dsedit, mit dem Sie die Servereinträge in der Schnittstellendatei über eine grafische Benutzeroberfläche in Adaptive Server Enterprise anzeigen und bearbeiten können. Einzelheiten finden Sie unter SAP ASE Utility Guide: dsedit.

SAP ASE Sicherung schlägt fehl mit Failed to load library 'libsepsybase.so' ('libsepsybase.so'-Bibliothek konnte nicht geladen werden)

Problem

• Ein Sicherung schlägt fehl mit Failed to load library 'libsepsybase.so' oder Failed to load library '%1' .

Mögliche Ursachen

• Die Bibliothek libsepsybase.so wird nicht in das SAP ASE lib Verzeichnis kopiert.
• Es wird eine falsche binäre Bibliotheksdatei verwendet.
• Der LD_LIBRARY_PATH ist nicht korrekt gesetzt.
• Der SAP ASE Sicherungsserver läuft nicht auf dem angegebenen Host.

⇒ Lösung

• Kopieren Sie die Bibliothek libsepsybase.so in das SAP ASE lib Verzeichnis.
• Prüfen Sie, ob die erforderliche Bibliothek installiert ist: file libsepsybase.so und wie sie gelöst wird: ldd libsepsybase.so.

sybase16:/opt/sap/ASE-16_0/lib # file libsepsybase.so
libsepsybase.so: symbolic link to `/opt/sesam/bin/sesam/libsepsybase.so'
sybase16:/opt/sap/ASE-16_0/lib # file /opt/sesam/bin/sesam/libsepsybase.so
/opt/sesam/bin/sesam/libsepsybase.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
sybase16:/opt/sap/ASE-16_0/lib # ldd /opt/sesam/bin/sesam/libsepsybase.so
       linux-vdso.so.1 =>  (0x00007fffcd75c000)
       libdl.so.2 => /lib64/libdl.so.2 (0x00007f65d0fa6000)
       librt.so.1 => /lib64/librt.so.1 (0x00007f65d0d9c000)
       libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f65d0b7f000)
       libc.so.6 => /lib64/libc.so.6 (0x00007f65d0803000)
       /lib64/ld-linux-x86-64.so.2 (0x00007f65d1cf3000)

• Prüfen Sie, ob die Variable LD_LIBRARY_PATH in der Datei SYBASE.env richtig gesetzt ist (die SAP Shared Libraries befinden sich im lib-Verzeichnis der installierten Komponente).

sybase16:/opt/sap # grep LD_LIBRARY_PATH SYBASE.env
[...]
LD_LIBRARY_PATH=/opt/sap/ASE-16_0/lib:$LD_LIBRARY_PATH

• Prüfen Sie, ob der SAP ASE Sicherungsserver auf dem angegebenen Host läuft -> suchen Sie nach dem Prozess namens backupserver.

sybase16:/opt/sap # ps -ef | grep backupserver
root     15534 15533  0 Mar23 ?        00:00:00 /opt/sap/ASE-16_0/bin/backupserver -e/opt/sap/ASE-16_0/install/qsstor.log -N25 -C20 -I/opt/sap/interfaces -M/opt/sap/ASE-16_0/bin/sybmultbuf -Sqsstor

SAP ASE Sicherung schlägt fehl mit ERROR: No Total: ... line found in LIS file (... Zeile in der LIS-Datei gefunden)

Problem

• SAP ASE Sicherung schlägt fehl mit: No Total: ... line found in LIS file.

Ursache

• sm_backup hat versucht, die LIS Datei zu holen, bevor der Sicherungsserver beendet war.

⇒ Lösung

• Verwenden Sie den SEP sesam Client ≥ Beefalo V2 SP2 und setzen Sie die folgende Sicherungsoption in den Eigenschaften des SAP ASE Sicherungsauftrags -> Reiter Optionen -> Feld Sicherungsoptionen:

-a action=sleep:20

	Anmerkung
	Wenn die Sicherungsoption -a action=sleep:xx nicht funktioniert, verwenden Sie die FTP-Schnittstelle anstelle von HTTP.

SAP ERP

Verwendung des XUSER MaxDB-Werkzeugs zur Authentifizierung während der Sicherung schlägt mit der Fehlermeldung XUser not found! fehl.

Problem

• Das SAP MaxDB XUSER Kommandozeilenwerkzeug kann verwendet werden, um Benutzeranmeldedaten zu speichern und so die Anmeldung an Datenbanken zu vereinfachen. Wenn Sie XUSER verwenden und das Skript als Befehlstermin ausgeführt wird, meldet das Sicherungsskript folgenden Fehler: XUser not found! (XUser nicht gefunden)

Ursache

• Das SAP MaxDB-Werkzeug XUSER legt im Home-Laufwerk des entsprechenden Benutzers eine Datei .XUSER.62 an. Wenn das Skript als Befehlstermin läuft, wird keine Umgebung und damit auch nicht die HOME-Variable gesetzt. Wenn die HOME-Variable nicht gesetzt ist, kann die DB die zum Benutzer gehörende Datei .XUSER.62 nicht finden und den Schlüssel nicht dem Benutzer zuordnen und verifizieren, weshalb der Befehlstermin fehlschlägt.

⇒ Lösung

• Exportieren Sie die Variable HOME für den Benutzer root im Sicherungsskript (Befehlsterminskript) wie folgt:

#!/bin/bash
HOME=/root
export HOME
/.../dbmcli .... -U <key> ....
.....

NetApp Volume Backup

FilerView http might be disabled

Problem

• FilerView might be disabled.

⇒ Lösung

• Check if FilerView is enabled. Logon to your NetApp system via ssh and use the following command to check whether your FilerView http is enabled:

options httpd.admin.enable

In clustered environments or Ontap 8 Versions using Vserver:

vserver services web modify -vserver <NODE_NAME> -name ontapi -enabled true

===

Restore shows permission problems ===

Problem

• A restore fails with the following error message in the protocol:

2012-08-20 12:32:27: sbc-2044: Warning: Cannot create item 
[/var/opt/sesam/var/work/mnt/netapp/VOLUME_NAME/restore/]: Permission denied

⇒ Lösung

Check if the system acting as a data mover has a write access to the NetApp volume the data should be restored to.

Incorrect volume path specification

Problem

• Usually NFS shares on NetApp systems are exported beneath the /vol/ directory. For example the nfs share test is mountable via:

netapp:/vol/test/

This is not the case for all NetApp systems. Some systems export the volume directly via: netapp:/test/

⇒ Lösung

• By default, SEP sesam mounts the volume via /vol/ specification. You can adjust the volume_path parameter in the advanced backup options by specifying the following:

-a volume_path=/

Backup fails with Permission denied - user mapping for NTFS style volumes is missing

Problem

• By default, SEP sesam is accessing the volumes for backup via NFS. If a desired volume for backup has security style set to NTFS, an appropriate user mapping has to be configured on the NetApp system. If not, backup may fail with Permission denied error message.

⇒ Lösung

Map the permission for the administrator user to root as shown in the screenshot below.

MySQL

MySQL Backup schlägt fehl mit mysqldump: Error 2013: Lost connection to MySQL server during query

Problem

• MySQL Backup schlägt fehl mit

mysqldump: Error 2013: 
Lost connection to MySQL server during query

Mögliche Ursachen

• Dieser Fehler kann bei der Sicherung von MySQL Datenbanken auf Bandmedien auftreten. Die Ursache für dieses Problem ist die MySQL Variable net_write_timeout. Der Wert dieser Variable beträgt standardmäßig 60 Sekunden. Zwischen dem Start des MySQL Dump Vorganges und der eigentlichen Schreiboperation auf dem Bandlaufwerk können aber unter Umständen mehr als 60 Sekunden vergehen. Der MySQL Server schließt dann die inaktive Verbindung nach 60 Sekunden und die Sicherung schlägt deswegen fehl.

⇒ Lösung

• Öffnen Sie die Optionsdatei /etc/my.cnf und setzen Sie einen höheren Wert für die Variable net_write_timeout im Abschnitt [mysqld] wie folgt:

[mysqld]
 ... other options ..
net_write_timeout = 180

• Die Einstellung wird erst nach einem Neustart des Dienstes aktiv. Möchten Sie die Einstellung sofort (ohne Neustart) vornehmen, können Sie dies mit Hilfe eines regulären mysql-Client-Befehls tun:

# mysql -u root -p -e "set global net_write_timeout=180;"

Zu beachten ist aber, dass diese Einstellung nach einem Neustart wieder auf den ursprünglichen Wert zurückgesetzt wird, wenn sie nicht ebenfalls in der Konfigurationsdatei angepasst ist.

• Ist die Variable bereits auf 180 Sekunden gesetzt und die Sicherung schlägt immer noch fehl, so ist ggf. ein höherer Wert als 180 Sekunden zu setzen. Wenn während der MySQL Sicherung ein Bandwechsel durchgeführt werden muss, kann dabei ebenfalls dieser Time-out überschritten werden. Für machen Bandroboter sind 180 s zu kurz.

Der derzeit aktive Wert kann folgendermaßen ermittelt werden:

# mysql -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'net_write_timeout'"
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| net_write_timeout | 60    |
+-------------------+-------+

MySQL Sicherungen mit Passwörtern die Umlaute enthalten – Verwenden Sie die Konfigurierungsdatei zur Ablage des Passworts

Problem

• Enthält das Passwort für den vorgegebenen Benutzer über den die Sicherung erfolgen soll Umlaute, so kann dies zu Problemen während der Sicherung führen. Generell wird die Eingabe von maskierenden Hochkommata sowie Umlauten in der GUI meist unterdrückt.

⇒ Lösung

• In diesem Falle - und auch generell bei der Verwendung von MySQL Sicherungen - empfiehlt es sich das Passwort nicht im Auftrag, sondern in einer speziellen Konfigurationsdatei abzulegen. Durch das Ablegen des Passwortes in der Konfigurationsdatei erscheint es nicht in der SEP sesam Protokollierung. Unter Using Option Files werden die unterschiedlichen MySQL Konfigurationsdateien beschrieben. Das folgende Beispiel gilt für Unix und Linux:

• Erstellen Sie eine Konfigurationsdatei mit dem Namen my.cnf. Für den Fall, dass SEP sesam als Benutzer root läuft und um sicherzustellen, dass der SEP sesam Client diese Datei korrekt lesen kann, speichern Sie diese Datei in

/root/.my.cnf

• Die Datei hat den Folgenden Inhalt (user ist optional):

[client]
user=root
password=mysqlpw

• Die Optionen für die Sicherungsaufträge müssen den Benutzernamen enthalten, falls dieser nicht gesetzt ist:

-a user=username

Das Passwort wird nun während der Sicherung aus der Konfigurationsdatei gelesen.

Shell-Login des Benutzers root ist erlaubt (d.h. auf Ubuntu-Systemen), aber die Variable $HOME existiert nicht

Problem

• Wenn die Variable $HOME nicht existiert, dann kann die Datei my.cnf nicht gefunden werden.

⇒ Lösung

• Bearbeiten Sie die Datei <sesam-root>/var/ini/sm.ini und fügen Sie die folgenden Zeilen am Ende der Datei hinzu:

[ENVIRONMENT]
HOME=/root

Nachdem Sie die erforderliche Variable hinzugefügt haben, starten Sie den SEP sesam Dienst neu, damit die Änderungen wirksam werden.

BSR Pro for Windows

BSR Pro - Fehlercodes

Wenn Sie eine BSR Pro-Sicherung oder -Rücksicherung durchführen, kann der Vorgang aus verschiedenen Gründen fehlschlagen. Die folgende Liste kann helfen, die BSR Pro-Fehlercodes zu verstehen.

• e0040002: Es läuft gerade eine BSR Pro-Sicherung oder -Rücksicherung; der gleichzeitige Betrieb von mehr als einem BSR Pro-Sicherungs- oder -Rücksicherungsprozess wird nicht unterstützt.

Die Installation von BSR Pro bricht mit einer Meldung ab: Es wurde eine neue Version gefunden. Ein Update ist nicht notwendig.

Problem

• Die Installation von BSR Pro schlägt mit einer Meldung wie der folgenden fehl: Es wurde eine neue Version gefunden. Ein Update ist nicht notwendig. Dies geschieht, wenn die Installationsprozedur eine andere installierte Version von BSR Pro (oder des Originalprogramms DiskImage von O&O) gefunden hat.

Mögliche Ursache

• BSR Pro oder O&O DiskImage wurde in der Vergangenheit bereits manuell installiert.

⇒ Lösung

• Wenn Sie die aktuell installierte Version behalten wollen, müssen Sie die SEP sesam-Installation ohne BSR Pro durchführen. Andernfalls muss die aktuell installierte BSR Pro-Version deinstalliert und anschließend die SEP sesam-Installation zusammen mit BSR Pro erneut durchgeführt werden.

BSR Pro kann während eines stillen SEP sesam Updates nicht aktualisiert werden

Problem

• BSR Pro wird nicht aktualisiert, wenn Sie eine SEP sesam Server, RDS oder Client Komponente einschließlich BSR im stillen Modus aktualisieren, z.B. über die Powershell-Befehlszeile:

sesam-cli-5.1.0.3-windows.x64.exe -Wait -Verb runAs -ArgumentList '/s',/v"/quiet /lvoicewarmup \"C:\tmp\sm_msi_update.lgc\""

Ursache

• BSR Pro wird mit einem eigenen MSI-Installer installiert und kann nicht automatisch in eine verkettete Installation eingebunden werden.

Während eines manuellen Updates mit der Installer-EXE oder während der Remote-Update-Installation über die SEP sesam GUI (sm_update_client) wird BSR Pro normal aktualisiert. Während der stillen Installation wird die Aktualisierung von BSR Pro nicht durchgeführt.

⇒ Lösung

Um den BSR Pro zu aktualisieren, können Sie eine der folgenden Möglichkeiten nutzen:

• Verwenden Sie das reguläre GUI-basierte Update, das auch die aktualisierte Version von BSR Pro enthält
• Verwenden Sie die SEP sesam GUI (sm_update_client) Update, die auch das BSR Update beinhaltet.

BSR Pro-Sicherung scheitert aufgrund eines Snapshot-Sicherungsproblems

Problem

• BSR Pro-Sicherung schlägt fehl mit BSR Pro unknown return code (0X1).

Ursache

• Unter einigen Windows-Betriebssystemen (z. B. Windows Server 2012) kann ein "volsnap"-Fehler im Windows-Ereignisprotokoll angezeigt werden: Event ID 25: The shadow copies of volume C: were deleted because the shadow copy storage could not grow in time. Consider reducing the IO load on the system or choose a shadow copy storage volume that is not being shadow copied.
  

Dieser Fehler deutet darauf hin, dass das Quelllaufwerk eine hohe IO-Last aufweist, die zu einem Ausfall von VSS und zum Löschen des Schattenkopie-Snapshots geführt hat, was wiederum einen Ausfall der BSR Pro-Sicherung zur Folge hatte.

⇒ Lösung

• Sie müssen die E/A-Last auf dem zu sichernden Laufwerk reduzieren oder VSS so konfigurieren, dass ein anderes Laufwerk mit mehr verfügbarem Speicherplatz (und weniger Last) verwendet wird. Weiterhin muss sichergestellt werden, dass genügend Speicherplatz für die Erstellung und Pflege von Schattenkopien vorhanden ist. Möglicherweise möchten Sie, wie von Microsoft empfohlen, ein separates Volume auf einem separaten Laufwerk für die Speicherung von Schattenkopien zuweisen, um die Leistung zu verbessern und die Möglichkeit auszuschließen, die Schattenkopien aufgrund einer hohen E/A-Last zu löschen.
  

Einzelheiten finden Sie unter Volume Shadow Copy Volsnap Event 25. Siehe auch den folgenden Microsoft-Artikel: Ereignis-ID 25 - Integrität des Diff-Bereichs

Nach Anklicken der Option BSR Pro Quick-Start ausführen sind weder Sicherungssätze noch Clients in SEP sesam vorhanden

Problem

• Die Liste der verfügbaren Sicherungssätze auf dem SEP sesam Server bleibt leer.

Mögliche Ursachen

Dieser Fehler tritt typischerweise auf, wenn die Verbindung zum SEP sesam Server aus einem der folgenden Gründe nicht hergestellt werden kann:

1. Problem mit der Namensauflösung: Der SEP sesam Server Hostname ist dem Client nicht bekannt, Name zu IP oder IP zu Name (Reverse) Auflösung ist nicht korrekt.
2. Der Name des Clients (typischerweise wird im Falle eines Disaster Recovery ein neuer Host mit neuer IP eingerichtet) kann am SEP sesam Server nicht aufgelöst werden.
3. Falscher Servername (ein vollständig qualifizierter Domänenname (FQDN) kann erforderlich sein).
4. Wenn Sie von PE booten, kann es etwas länger dauern, bis die Sicherungssätze erscheinen (30-45 Sekunden).

⇒ Lösung

1. Überprüfen Sie die Namensauflösung auf Client und SEP sesam Server. Beide Namen müssen aufgelöst sein, die Client-IP muss in den Client-Namen aufgelöst sein, und der SEP sesam Server muss erreichbar sein (überprüfen Sie die Route zu ihm - FQDN kann erforderlich sein, um ihn zu erreichen). Als Referenz, siehe Überprüfung der DNS-Konfiguration. Wenn die Auflösung in Ihrem Netzwerk nicht wie erwartet funktioniert, gibt es möglicherweise Probleme mit IPv6 und IPv4.
2. Fügen Sie den Namen des Kunden zur Namensauflösung hinzu oder fügen Sie ihn zur /etc/hosts auf dem SEP sesam Server hinzu, oder verwenden Sie die GLBV gv_stpd_auth NONE, um die IP-Namen-zu-IP-Adresse-Prüfung auf dem SEP sesam Server zu deaktivieren; im letzteren Fall öffnen Sie eine Shell auf dem SEP sesam Server und führen Sie den untenstehenden Befehl aus. Dieser Befehl ermöglicht es Ihnen, den SEP sesam Server zu kontaktieren, auch wenn die Reverse Name Resolution auf dem neuen Client nicht funktioniert.

 sm_glbv w gv_stpd_auth NONE

3. Geben Sie den SEP sesam Server mit dem FQDN an. Öffnen Sie die BSR Pro Einstellungen -> Reiter Security und überprüfen Sie in der Tabelle Authentication die Einstellungen. Unter Network path/Server muss ein gültiger sesam:{server} Name oder interface angegeben werden.
Beispiele:

 ''Network path/server''                      ''Port''
 sesam:http://sep_server.mydomain.com   11000
 sesam:sep_server2                        11001

	Anmerkung
	Nur der erste Eintrag wird verwendet, um die Liste der verfügbaren Sicherungssätze zu füllen!

OODIAG stürzt während der Erstellung des BootISOs ab

Problem

• Wenn Sie versuchen, ein Boot-ISO mit dem BSR Pro auf einem System zu erstellen, auf dem die Datenträger dynamische Datenträger sind, dann ist der OODIAG-Dienst unter bestimmten Umständen ausgefallen.

Mögliche Ursache

• Das Problem ist offensichtlich der Systemdatenträger. Möglicherweise hängt es mit dem dynamischen Datenträger zusammen.

⇒ Lösung

• Installieren Sie eine neuere SEP sesam Version mit BSR Pro.
• Verwenden Sie nach Möglichkeit keine dynamischen Datenträger.

VSS-Snapshot für den Systemdatenträger funktioniert nicht

Problem

• Normalerweise wird VSS standardmäßig verwendet, um Datenänderungen zu protokollieren, damit unveränderte Daten in die Sicherung aufgenommen werden. Auf einigen Systemen funktioniert der VSS-Snapshot für den Systemdatenträger jedoch nicht.

⇒ Lösung

• Starten Sie SEP sesam BSR Pro mit der Option -a snap=snapshot. Diese Option erzeugt einen speziellen Snapshot, der den Microsoft VSS Writer nicht einbezieht: Datenänderungen werden mit Hilfe des installierten Filtertreibers protokolliert, um die unveränderten Daten in die Sicherung aufzunehmen.

Usage: -a snap=vss|snapshot
where <vss> is default

Es ist nicht möglich, das Fehlerprotokoll für eine fehlgeschlagene Rücksicherung in einem PE zu erhalten

Problem

• Diskette voll beim Zugriff auf X: weil Dump darauf geschrieben wird.

Mögliche Ursache

• Das LOG wird zu groß, weil ständig in das LOG geschrieben wird.

⇒ Lösung

• Öffnen Sie die Registrierung in der Befehlsshell mit regedit.
• Fügen Sie den folgenden Reg-Schlüssel hinzu:

[HKEY_LOCAL_MACHINE\SOFTWARE\O&O\O&O DiskImage\<version>]
"DumpFilePath"="E:\\DUMPS\\"

• Nach der Änderung wird das LOG in den Pfad E:\DUMPS geschrieben.

SEP sesam Deinstallation der BSR Pro Komponente schlägt fehl

Problem

• Die Deinstallation der Komponente BSR Pro schlägt fehl und hinterlässt ungültige Registrierungseinträge.

⇒ Lösung

• Nach einer fehlgeschlagenen Deinstallation sind die Informationen des Deinstallationsprogramms wahrscheinlich beschädigt und Sie müssen alle potenziell schädlichen Registrierungsreste beseitigen, um den normalen Betrieb von SEP sesam zu gewährleisten. Es gibt zwei Möglichkeiten, mit den Überresten einer fehlgeschlagenen Deinstallation umzugehen.

1. Am besten deinstallieren Sie diese Komponenten mit dem Installationsprogramm; installieren Sie BSR Pro zunächst neu, um es zu reparieren, und deinstallieren Sie es erst dann wieder.

	Hinweis
	Nach einer erfolgreichen und vollständigen Deinstallation der Komponente BSR Pro sollten die unten aufgeführten Schlüssel (siehe Registrierungseinträge) nicht mehr vorhanden sein. Falls einer der aufgelisteten Schlüssel noch vorhanden ist, kann er wie im nächsten Verfahren beschrieben manuell gelöscht werden.

2. Wenn das obige Verfahren nicht erfolgreich angewendet werden kann, müssen Sie die BSR Pro-Installation manuell entfernen.

	Anmerkung
	Die folgenden Schritte beschreiben, wie Sie die Registrierung ändern können. Wenn Sie die Registrierung nicht korrekt ändern, können schwerwiegende Probleme auftreten. Wenn Sie sich nicht sicher sind, was Sie tun, empfehlen wir Ihnen, den SEP-Support unter support@sep.de um Hilfe zu bitten.

1. Geben Sie im Startmenü/Suchfeld den Text regedit ein und klicken Sie auf Enter. Das Fenster Windows-Registrierungseditor wird geöffnet.
2. Löschen Sie den Registrierungseintrag:

 HKEY_LOCAL_MACHINE\SOFTWARE\O&O\O&O DiskImage
 HKEY_LOCAL_MACHINE\SOFTWARE\O&O\O&O LiveUpdate\SEP sesam BSR Pro

BSR Pro-Sicherung schlägt mit einem Verbindungsfehler fehl

Problem

• Die BSR Pro-Sicherung kann mit einem der folgenden Fehler aufgrund einer blockierten Netzwerkverbindung zum SEP sesam Server fehlschlagen:

script processing failed:

oder

(Status: ERROR 425 Can't open data connection. WINSOCK: Connection timed out. (0x274c,10060)

oder

Port negotiation failed. (10038)

Mögliche Ursache

• Die Windows-Firewall verhindert oder blockiert Ihre Verbindungen.

⇒ Lösung

• Überprüfen Sie die Windows Firewall-Regeln auf dem SEP sesam Client mit BSR Pro. Wenn die Firewall-Regel, die während der SEP sesam Installation angewendet wurde, nicht mehr gültig ist, erstellen Sie eine Ausnahme für oodiag.exe, um die Verbindung durch die Firewall zu erlauben. Details zur Konfiguration dieser Firewall-Regel finden Sie in den Voraussetzungen im SEP sesam BSR Pro – Konfiguration der Sicherung.

NDMP

NDMP-Verbindungsfehler während der Sicherung

Problem

• Der NDMP-Server kann sich während einer NDMP-Sicherung nicht mit SEP sesam (sbc_ndmp) verbinden. Fehler wie die folgenden werden angezeigt und die Sicherung schlägt fehl.

NDMP error:  ERR NDMP4_DATA_CONNECT  NDMP4_CONNECT_ERR
NDMP error:  ERR NDMP4_DATA_ABORT  NDMP4_ILLEGAL_STATE_ERR

oder

NDMP error: NDMP_DATA_CONNECT 

Mögliche Ursachen

• In den meisten Fällen handelt es sich um ein Firewall-Problem.
• Andere falsche Netzwerkeinstellungen verhindern die Verbindung zu sbc_ndmp.
• Im Falle von NetApp können mehrere Schnittstellen die Verbindung zu sbc_ndmp verhindern.

⇒ Lösung

• Schließen Sie sbc_ndmp.exe vom Firewall-Scanner aus und führen Sie die Sicherung erneut aus.
• Überprüfen Sie die Konfiguration Ihres Netzwerks. Beachten Sie, dass Ihr Netzwerk korrekt konfiguriert sein muss, damit die Verbindung zu sbc_ndmp möglich ist.
• Im Fall von NetApp, wenn mehrere Schnittstellen vermutet werden, stellen Sie die bevorzugte Schnittstelle auf Ihrem NAS-Gerät ein, um die Schnittstelle festzulegen, die für NDMP verwendet werden soll:

options ndmpd
options ndmpd.preferred_interface <interface_name>

Weitere Einzelheiten finden Sie unter NetApp-spezifische NDMP-Konfiguration.

NDMP-Rücksicherung auf neues Rücksicherungsziel mit nicht vorhandenem Unterverzeichnis schlägt fehl

Problem

• Eine NDMP Rücksicherung auf ein neues Rücksicherungsziel, bei dem das beabsichtigte Rücksicherungsziel ein anderes, nicht existierendes Unterverzeichnis ist, schlägt fehl. (In früheren SEP sesam Versionen schlägt die NDMP Rücksicherung in ein nicht vorhandenes Unterverzeichnis fehl, wird aber als erfolgreich angezeigt. Obwohl dies nun behoben ist, sollten Sie überprüfen, ob die zuvor wiederhergestellten NDMP-Daten existieren).

Beachten Sie, dass dies nur der Fall ist, wenn das neue Rücksicherungsziel ein nicht vorhandenes Unterverzeichnis ist. Wenn Sie beispielsweise auf /<volume_name>/<sub_dir1>/<sub_dir2> rücksichern möchten und <sub_dir1> nicht existiert, schlägt die Rücksicherung fehl. Sie können NDMP auch in den alternativen Zielunterverzeichnissen rücksichern, wenn diese bereits vorhanden sind.

Ursache

• Wenn ein Unterverzeichnis als neues (nicht existierendes) Rücksicherungsziel angegeben wird, z.B. /<volume_name>/<sub_dir1>/<sub_dir2>, schlägt die Rücksicherung fehl, da nicht existierende Unterverzeichnisse bei der Rücksicherung in ein anderes Ziel nicht unterstützt werden. In diesem Fall kann nur eine einstufige Verzeichnisstruktur als Rücksicherungsziel verwendet werden: /<volume_name>/<target_dir>. Im obigen Beispiel ist der unterstützte Rücksicherungszielpfad also /<volume_name>/<sub_dir1>.

Workaround

• Wenn Sie eine NDMP-Rücksicherung in ein neues Rücksicherungsziel durchführen, stellen Sie sicher, dass Sie Ihre Daten im obersten Verzeichnis rücksichern (/<volume_name>/<target_dir>). Geben Sie keine nicht existierenden Unterverzeichnisse im neuen Zielpfad an, da die Rücksicherung sonst fehlschlägt.

Selektive NDMP-Rücksicherung stellt leere Verzeichnisse nicht wieder her und die Rücksicherung schlägt fehl

Problem

• In SEP sesam Versionen ≤ 4.4.3 Beefalo V2 werden bei einer selektiven NDMP Rücksicherung leere Verzeichnisse auf dem Ziel nicht zurückgespeichert (erstellt), wenn:
  • leere Verzeichnisse in der Rücksicherungsliste zusammen mit normalen Verzeichnissen und Dateien vorhanden sind (dies ist ein bekanntes Problem, aber zu geringfügig, um eine Korrektur zu rechtfertigen)
  • mindestens eine Datei in einem anderen Verzeichnis ausgewählt ist, z.B. wenn die Sicherungsquelle /vol/vol1 ist und die Rücksicherungsauswahl /vol/vol1/dir_1/file_1 und /vol/vol1/empty_dir lautet
    

Folglich schlägt die Rücksicherung fehl.

Ursache

• Wenn nur Verzeichnisse für die selektive Rücksicherung ausgewählt werden, werden die leeren Verzeichnisse von sm_restore zur SEL-Datei hinzugefügt und die Rücksicherung wird ohne Fehler abgeschlossen. Wenn jedoch mindestens eine Datei zusammen mit einem leeren Verzeichnis ausgewählt wird, schlägt die Rücksicherung fehl.

Workaround

• Wenn Sie eine selektive Rücksicherung durchführen, versuchen Sie, keine leeren Verzeichnisse zusammen mit einzelnen Dateien rückzusichern, da die Rücksicherung sonst fehlschlägt.

NDMP auf NetApp

NDMP-Durchsuchen von Nicht-UTF-8 schlägt fehl und die Rücksicherung auf ein Nicht-UTF-8-Volume ist eventuell nicht möglich

Problem

• Beim Durchführen einer Rücksicherung ist es nicht möglich, den Inhalt von NetApp Volumen zu durchsuchen, die nicht UTF-8 sind. Sie erhalten möglicherweise eine Fehlermeldung ähnlich der folgenden:

NDMP error:  ERR NDMP4_SNAP_DIR_LIST  ?0x20500106?

Das kann passieren, weil:

• Nicht-UTF-8-Volumen nicht durchsuchbar sind, wenn Objekte Umlaute oder Sonderzeichen enthalten.
• Folglich ist eine Rücksicherung auf ein Nicht-UTF-8-Volume nicht möglich, wenn Objekte mit Sonderzeichen in der NDMP-Sicherung enthalten sind.

Der folgende ONTAP CLI-Befehl zeigt die Kodierungssprache aller Volumen an:

volume show -vserver * -fields language

⇒ Lösung

• NDMP-Sicherungen von NetApp-Volumen ohne UTF-8-Kodierungssprache sind grundsätzlich möglich, allerdings kann der Pfad im Sicherungsauftrag nur manuell angegeben werden.
• Wenn die Sicherung eines Nicht-UTF-8-Volumen Objekte mit Umlauten oder Sonderzeichen enthält, kann die Rücksicherung nur auf ein UTF-8-Volumen erfolgen.

NDMP DAR-Rücksicherung von einzelnen Dateien ist zu langsam

Problem

• Bei der Verwendung einer Direct Access Recovery (DAR), die eine selektive NDMP-Rücksicherung ermöglicht, ist die Rücksicherung zu langsam, obwohl DAR die Zeit für die Rücksicherung einzelner Dateien erheblich reduzieren sollte.

Ursache

• Die allgemeine Prognose lautet, dass DAR die Rücksicherungsgeschwindigkeit deutlich erhöht, was jedoch von der Menge und Größe der gesicherten Daten abhängt. Wie NetApp angibt, kann die Rücksicherung je nach Anzahl der Dateien im Verzeichnis, der Position des Verzeichnisses und der Datei auf dem Band sowie der Anzahl der zu lesenden Bänder recht lange dauern. Einzelheiten finden Sie in der NetApp Dokumentation.

⇒ Lösung

• Teilen Sie die Sicherung in kleinere Teile auf, um die Menge der Informationen zu reduzieren, die der DAR während der Rücksicherung verwalten muss.

Die Rücksicherung schlägt mit "Storing of nlist entries failed." fehl

Problem

• Die Rücksicherung wird mit der Fehlermeldung beendet: "Storing of nlist entries failed." (Speichern von nlist-Einträgen ist fehlgeschlagen)

⇒ Workaround

• Starten Sie den NDMP-Daemon in Version 3 anstelle der üblichen Version 4 des NDMP-Protokolls, indem Sie die folgenden Befehle eingeben:

ndmpd off
ndmpd version 3
ndmpd on

• Versuchen Sie dann die NDMP-Rücksicherung erneut.

Hyper-V

Hyper-V Sicherung schlägt mit dem folgenden Fehler fehl ERROR [ [NInternal::CVssAsyncDecorator::Wait] - VSS_S_ASYNC_PENDING]

Problem

• Die Hyper-V Sicherung schlägt mit dem folgenden Fehler fehl:

Error: DB Module: [ [NInternal::CVssAsyncDecorator::Wait] - VSS_S_ASYNC_PENDING]

⇒ Lösung

• Der VSS Wert in der Konfigurationsdatei <SESAM_VAR>/var/ini/sm.ini muss von 200

[SBC_OPTIONS]
VSS_WAIT_FOR_ASYNC_OP=200

auf 600 erhöht werden

[SBC_OPTIONS]
VSS_WAIT_FOR_ASYNC_OP=600

Hyper-V Sicherung schlägt mit time-out Fehler fehl

Problem

• Der Sicherungsauftrag schlägt mit time-out Error fehl unter Windows:

Error:   DB Module: [ [Failed at thaw] - VSS_E_WRITERERROR_TIMEOUT.
[Microsoft Hyper-V VSS Writer] - VSS_E_WRITERERROR_TIMEOUT]

⇒ Lösung

• Installieren sie den folgenden Microsoft Servicepack auf dem Hyper-V Knoten und auf jeder Microsoft VM welche auf dem Hostsystem läuft.

Hyper-V Sicherung schlägt mit dem Fehler VSS_E_SNAPSHOT_SET_IN_PROGRESS fehl

Problem

• Beim Sichern einer Hyper-V VM in Windows Server 2012 erscheint der folgende Fehler:

Error: VSS_E_SNAPSHOT_SET_IN_PROGRESS error and in the Windows Event logs VDS basic provider error

⇒ Lösung

• Installieren sie den folgenden Microsoft Servicepack auf dem Hyper-V Knoten und auf jeder Microsoft VM welche auf dem Hostsystem läuft.

Sicherung einer Linux-VM schlägt fehl

Problem

• Beim Sichern einer Linux-VM ohne Guest Services Unterstützung schlägt der Sicherungsauftrag mit einem Fehler fehl:

VSS_E_WRITERERROR_NONRETRYABLE

Sicherungen von Linux-Systemen mit Guest Services Unterstützung funktionieren normal.

⇒ Lösung

• Wenn die Sicherung einer Linux VM mit dem Fehler VSS_E_WRITERERROR_NONRETRYABLE fehlschlägt, öffnen Sie VM Settings -> Integration Services und deaktivieren Sie die Option Sicherung (Volume Shadow Copy).

Hyper-V Rücksicherung schlägt fehl

Problem

Beim Versuch, eine Hyper-V VM in eine andere Hyper-V Umgebung zurückzusichern, kann die Rücksicherung mit einem der folgenden Fehler fehlschlagen:

Virtuelle Maschine kann aufgrund von Konfigurationsfehlern nicht importiert werden.

oder etwas wie

Die virtuelle Maschine <VM_name> verwendet derzeit einen AMD-Prozessor, aber der physische Computer <host_name> hat einen Intel-Prozessor. Eine laufende oder eine virtuelle Maschine im saved state kann nicht auf einen physischen Computer mit einem Prozessor eines anderen Herstellers migriert werden. 

Sie können die virtuelle Maschine jedoch auf diesen Knoten verschieben, wenn Sie die virtuelle Maschine herunterfahren.

Ein Konfigurationsfehler kann auftreten, wenn eine wiederherzustellende VM nicht mit dem Ziel Hyper-V Host kompatibel ist. Die Rücksicherung kann aus folgenden Gründen fehlschlagen:

• Hyper-V VMs verwenden erweiterte CPU-Funktionen und schlagen fehl, wenn die CPUs zu unterschiedlich sind (unterschiedliche Generation, Typ....), wenn VMs zwischen Servern mit unterschiedlichen Prozessortypen, z.B. Intel VT oder AMD-V, wiederhergestellt werden oder wenn dem Zielserver Virtualisierungserweiterungen fehlen oder diese deaktiviert sind.
• Das Rücksichern einer VM, die vollständig mit virtuellen Switches und Netzwerkdefinitionen konfiguriert ist, in eine andere Hyper-V Umgebung kann dazu führen, dass die ursprünglichen Switch Definitionen nicht gefunden werden.

⇒ Mögliche Lösungen

VM- und Hyper-V Host Kompatibilität prüfen

Bevor Sie eine VM auf einem anderen Hyper-V Host rücksichern, prüfen Sie, ob der Host den VM Typ, den Sie rücksichern möchten, unterstützen kann. Verwenden Sie das Cmdlet Compare-VM, um die Kompatibilität einer VM und eines Hyper-V Hosts zu prüfen. Führen Sie die folgenden Befehle aus, um die Ausgabe zuerst in einer PowerShell-Variablen $Report zu speichern und dann das Resultat anzuzeigen:

$report = Compare-VM -Path $Source
$report.Incompatibilities | FT -AutoSize

Verwenden Sie den Bericht, um Kompatibilitäts- oder Konfigurationsprobleme zu beheben. Details siehe MS-Artikel Compare-VM.

Prozessorkompatibilitätsmodus für eine virtuelle Maschine aktivieren

Laut Microsoft: "Hyper-V führt Pre-Flight Prüfungen durch, wenn eine Live-Migration oder ein Save/Rücksicherungs-Betrieb der virtuellen Maschine gestartet wird. Diese Prüfungen vergleichen die Menge der Prozessorfunktionen, die der virtuellen Maschine auf dem Quellhost zur Verfügung stehen, mit der Menge der Prozessorfunktionen, die auf dem Zielhost verfügbar sind. Wenn diese Funktionen nicht übereinstimmen, wird der Migrations- oder Wiederherstellungsvorgang abgebrochen." Weitere Informationen finden Sie im gesamten MS-Artikel Processor Compatibility Mode in Hyper-V. Um den Prozessorkompatibilitätsmodus für eine virtuelle Maschine zu aktivieren, gehen Sie wie folgt vor:

	Anmerkung
	Der Prozessorkompatibilitätsmodus gilt nur für Prozessortypen innerhalb derselben Prozessorfamilie. Er ermöglicht keine Migration zwischen AMD- und Intel-basierten Hosts. Weitere Informationen finden Sie unter TechNet Magazine Tip: When to Use Processor Compatibility Mode to Migrate Virtual Machines.

1. Öffnen Sie den Hyper-V Manager und beenden Sie die VM, die Sie für den CPU-Kompatibilitätsmodus konfigurieren möchten.
2. Klicken Sie mit der rechten Maustaste auf die ausgeschaltete VM. Klicken Sie im Aktionsbereich auf Einstellungen und dann auf Prozessor.
3. Erweitern Sie den Prozessor, und klicken Sie auf Kompatibilität.
4. Klicken Sie auf einen physischen Computer mit einem anderen Prozessor migrieren, und klicken Sie dann auf OK.

VM herunterfahren, sichern und rücksichern

Wenn Sie eine VM von einem Hyper-V Host mit einem Prozessortyp (z.B. AMD) auf den Host mit einem anderen Prozessortyp (z.B. Intel) rücksichern, können Sie versuchen, eine Hyper-V VM zu verschieben, indem Sie sie herunterfahren, sichern und dann auf dem neuen Host rücksichern.

Hyper-V Manager 2016 VM startet nicht nach einer Rücksicherung

Problem

Nach der erfolgreichen Rücksicherung einer virtuellen Hyper-V-Maschine (VM) lässt sich die rückgesicherte VM nicht mehr starten. Dieses Problem betrifft insbesondere Hyper-V Manager 2016 oder ältere Versionen. Die Ursache für den Boot-Fehler ist die Secure Boot-Option, die eine Diskrepanz zwischen der Boot-Konfiguration der VM und der rückgesicherten Umgebung erzeugen kann.

⇒Lösung

Die Deaktivierung der Secure Boot Option ermöglicht es der VM, die Sicherheitsüberprüfungen zu umgehen, die das Boot-Problem verursachen können. So deaktivieren Sie die Secure Boot Option:

1. Fahren Sie die rückgesicherte VM im Hyper-V Manager 2016 herunter.
2. Deaktivieren Sie die Option Secure Boot:
   • Wählen Sie im Hyper-V Manager die VM aus und gehen Sie zu Settings der VM.
   • Navigieren Sie zu Hardware -> Security, und deaktivieren Sie die Option Enable Secure Boot.
   • Klicken Sie auf Apply und dann auf OK, um die Änderungen zu speichern.
3. Starten Sie die VM im Hyper-V-Manager.

Beim Mount einer Hyper-V RCT-Sicherung wird für jede eingehängte VHDX ein Windows Explorer-Fenster geöffnet

Problem

Während des Mounts einer Hyper-V-Sicherung öffnet sich das Windows Explorer-Fenster für jede eingehängte vhd(x). Dieses Problem tritt unter dem Betriebssystem Microsoft Windows Workstation auf, wenn Autoplay für Wechsellaufwerke aktiviert ist und die Option Ordner öffnen, um Dateien anzuzeigen (Datei-Explorer) ausgewählt ist.

Mögliche Lösungen

Für Wechsellaufwerke setzen Sie die Option Keine Aktion als Standard oder deaktivieren Sie Autoplay vollständig.

KVM/QEMU

Zusammenführen und Löschen von übrig gebliebenen Snapshots

Problem

• Die Sicherung schlägt fehl und der Snapshot bleibt zurück.

⇒ Lösung

Verwenden Sie das grafische Tool virt-manager zum Löschen des Snapshots oder virsh, wie im Beispiel gezeigt:

1. Liste der verfügbaren Snapshots für die Domäne:

 user@hypervisor:~$ virsh snapshot-list <domain_name>
 Name                 Creation Time             State
 ------------------------------------------------------------
 '''Sesam_SF20173828282@XXXX'''       2017-07-06 08:15:11 +0200 disk-snapshot

In diesem Beispiel gibt es einen übrig gebliebenen Snapshot für diese VM.

2. Liste der virtuellen Festplatten für die Domäne:

 user@hypervisor:~$ virsh domblklist <domain_name>
 Target     Source
 ------------------------------------------------
 '''sda'''        /path/to//Sesam_SF20173828282@XXXX.snapshot

3. Starten Sie für jedes Gerät, das auf einen SEP sesam Snapshot verweist, einen Block-Commit, um den Snapshot zusammenzuführen:

 user@hypervisor:~$ virsh blockcommit <domain_name> '''sda''' --active --verbose --pivot
 Block Commit: [100 %]
 Successfully pivoted

4. Confirm that the device is now switched to the original disk device:

 user@hypervisor:~$ virsh domblklist <domain_name>
 Target     Source
 ------------------------------------------------
 sda        /my/original/base.img

5. Löschen Sie die Metadaten des Snapshots:

 user@hypervisor:~$ virsh snapshot-delete <domain_name> --metadata --snapshotname '''Sesam_SF20173828282@XXXX'''
 Domain snapshot sesam_snapshot deleted

6. Löschen Sie die Snapshot-Datei:

 user@hypervisor:~$ rm /path/to//Sesam_SF20173828282@XXXX.snapshot

Si3 Deduplication

Verbindung zum S3-Datenspeicher kann nicht hergestellt werden

Problem

Si3 NG-Datenspeicher ist möglicherweise nicht in der Lage, eine sichere Verbindung zum S3-Speicher herzustellen, und es tritt der folgende Fehler auf:

Error: Could not access data store. Server Status: 2023-03-30 10:17:10: ERROR Not started due to error: S3 is not connected Server Status: 2023-03-30 10:17:10: ERROR Not started due to error: S3 is not connected

Ursache

Wenn ein Si3 NG Datenspeicher eine Verbindung zu einem Speicheranbieter herstellt, der ein selbstsigniertes Zertifikat verwendet, wird dieses Zertifikat standardmäßig nicht als vertrauenswürdig erkannt, da es nicht von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde. Dies kann dazu führen, dass die Verbindung verweigert wird und die Protokolldateien in /var/opt/sesam/var/log/sms eine ähnliche Protokollmeldung enthalten:

[...default-dispatcher-6] [1;31mERROR[0;39m [36mS3[0;39m - Unexpected error: {}, cause: {}
software.amazon.awssdk.core.exception.SdkClientException: Unable to execute HTTP request: javax.net.ssl.SSLHandshakeException: General OpenSslEngine problem

⇒ Lösung

Um dieses Problem zu lösen, verwenden Sie das Dienstprogramm keytool, um das Zertifikat public.crt in den Zertifikatspeicher des Servers zu importieren. Dadurch kann der Si3-Server das Zertifikat des S3-Speicheranbieters erkennen und ihm vertrauen, so dass eine sichere Verbindung hergestellt werden kann.

1. Besorgen Sie sich das öffentliche Zertifikat. Beachten Sie, dass Sie es über den Browser exportieren können.
2. Suchen Sie die Datei cacerts auf Ihrem Server. Dies ist der Speicherort Ihres JVM-Zertifikat-Keystore.
3. Importieren Sie das Zertifikat public.crt mit dem folgenden Befehl in den Zertifikatspeicher der JVM:

auf Linux:

keytool -import -trustcacerts -keystore /var/lib/ca-certificates/java-cacerts -storepass changeit  -noprompt -alias <URL des Speicher Backend Endpunkts> -file /<Pfad zum Zertifikat>/public.crt

auf Windows:

C:\Program Files\ojdkbuild\java-11-openjdk-11.0.15-1\bin>keytool -import -trustcacerts -keystore "C:\Program Files\ojdkbuild\java-11-openjdk-11.0.15-1\lib\security\cacerts" -storepass changeit -noprompt -alias <URL des Speicher Backend Endpunkts> -file <Pfad zum Zertifikat>\public.crt

Probleme mit S3 oder S3-kompatiblem Speicher

Problem

• Si3 NG-Datenspeicher, die S3 oder S3-kompatiblen Speicher verwenden, können je nach Cloud-Speicheranbieter verschiedene Probleme aufweisen. Diese Probleme können Sicherungen, Migrationen und Replikationen beeinträchtigen. Darüber hinaus kann die Prüfung des Sicherheitsstatus von Si3 NG Fehler melden, die eine ähnliche Ursache haben.

Ursache

• Einige Cloud-Speicheranbieter (z. B. Wasabi) haben Beschränkungen für die Anfragerate (wie viele HTTP(S)-Anfragen pro Sekunde zulässig sind). Auch bei lokalem Speicher mit aktivierter S3-Option kann der Zugriff mehrerer RDS auf denselben lokalen S3-Speicher viele IOPS (E/As pro Sekunde) erzeugen.

⇒ Lösung

• Sie können die Einstellungen für den betroffenen Si3 NG-Datenspeicher anpassen:

1. Klicken Sie in der Auswahl -> Komponenten auf Datenspeicher, um die Liste Ihrer Datenspeicher anzuzeigen.
2. Klicken Sie mit der rechten Maustaste auf den ausgewählten Si3 NG-Datenspeicher und dann auf Eigenschaften.
3. Doppelklicken Sie auf ein Laufwerk, um den Dialog Laufwerkseigenschaften zu öffnen, und geben Sie dann im Feld Optionen Folgendes ein:

dedup.s3.timeoutInSeconds=1200,dedup.s3.page.workers=2,dedup.maxAsyncRequests=50

Dies erhöht die Timeout-Periode, die Anzahl der aktiven Pageworker und die Anfragerate.

Si3 bleibt im Zustand "Herunterfahren"

Problem

• Das manuelle Anhalten der Garbage Collection (GC) schlägt fehl und Si3 verbleibt daher im Zustand "Herunterfahren".

⇒ Lösung

• Starten Sie den Si3 Daemon mit sm_main restart sds neu. Weitere Details zum Stoppen und Starten der SEP sesam Dienste finden Sie unter So Starten und Stoppen Sie SEP sesam.

Si3 Deduplizierung funktioniert nicht mit NFSv4

Problem

• Si3 Deduplizierung funktioniert nicht mit Network File System Version 4 (NFSv4).

Ursache

• SEP sesam Operationen, wie z.B. Sicherung, Rücksicherung und Migration, können aufgrund von Java Problemen mit NFSv4 fehlschlagen.

⇒ Lösung

• Um dieses Problem zu vermeiden, verbinden Sie Ihre Sicherungsgeräte über NFSv3.

Reparieren eines beschädigten Si3 NG-Datenspeichers

Sie können den Si3 NG Speicher reparieren, wenn Seiten oder Objekte beschädigt werden.

1. Bestimmen Sie zunächst das Ausmaß der Beschädigung:
   • Um die Liste der beschädigten Objekte zu erhalten, verwenden Sie:

     sm_dedup_interface -d <datastore> corruptedobjects

   • Um die Liste der beschädigten Seiten zu erhalten, verwenden Sie:

     sm_dedup_interface -d <datastore> corruptedpages

2. Verwenden Sie den folgenden Befehl, um die Seiten im Verzeichnis /pages durch eine ältere Version aus dem Verzeichnis /pages-trash zu ersetzen:

   sm_dedup_interface -d <datastore> repair pages

   Die Seiten im Papierkorb enthalten alle Chunks, die mit der vorherigen GC gelöscht wurden. Die älteste Version einer Seite hat Vorrang.
3. Verwenden Sie den folgenden Befehl, um die fehlenden Chunks im Verzeichnis /pages-trash zu suchen und wiederherzustellen:

   sm_dedup_interface -d <datastore> repair start

   Während des Reparaturvorgangs wird eine neue Seite erstellt, die alle Chunks der aktuellen Seite (Seite, die vom Problem der fehlenden Chunks betroffen ist) und alle Chunks, die im Papierkorb gefunden wurden, enthält.

Bereinigung eines nicht wiederherstellbaren Si3 NG Speichers

	Achtung
	Sie sollten die in diesem Abschnitt beschriebenen Befehle nur dann verwenden, wenn der beschädigte Speicher nicht wiederhergestellt werden kann.

Wenn Beschädigungen im Si3 NG Speicher fortbestehen, wurde die ursprüngliche Seitenversion bereits aus dem Papierkorb gelöscht, oder es gab fatale Fehler während der Sicherung oder Rücksicherung. In diesem Fall können beschädigte Seiten oder fehlende Chunks nicht wiederhergestellt werden.

Die Bereinigung kann durch manuelles Löschen von nicht wiederherstellbaren Objekten oder durch die automatische Bereinigungsfunktion erfolgen.

Löschen von Objekten

Wenn es nur wenige nicht wiederherstellbare Objekte gibt, löschen Sie jedes Objekt mit den folgenden Befehlen:

sm_dedup_interface -d <datastore> delete corruted_object_id_1

...

sm_dedup_interface -d <datastore> delete corruted_object_id_Nth

Bei vielen Beschädigungen können Sie alle beschädigten Objekte mit dem folgenden Befehl löschen:

sm_dedup_interface -d <datastore> fsck purge

Garbage collection

Wenn Sie alle nicht wiederherstellbaren Objekte gelöscht haben, führen Sie die Garbage Collection (gc) aus:

sm_dedup_interface -d <datastore> gc start

Automatische Bereinigungsfunktion

Um eine automatische Bereinigungsfunktion zu starten, verwenden Sie den folgenden Befehl:

sm_dedup_interface ... fsck purge auto

Die automatische Bereinigungsfunktion führt die folgende Befehlssequenz aus: PCCK Start -> OCCK Start -> Löschen aller beschädigten Objekte -> GC Start.

Protokolle

Die Protokollfunktion benutzt eine mächtige Logback Bibliothek. Weitere Informationen finden Sie unter Logback Project. Bitte beachten Sie, dass diese Informationen nur für erfahrene Nutzer gedacht sind.

Protokollinformation

• gv_rw_ini:sm_sds.xml (/var/opt/sesam/var/ini/sm_sds.xml)
• /var/opt/sesam/var/log/sms enthält zwei Protokolldateien:
  • sm_dedup_server_info-<drive>.log: Protokollstufe INFO und höher.
  • sm_dedup_server-<drive>.log: Protokollstufe DEBUG und höher. Diese Datei kann sehr groß werden.
  • sm_dedup_gc-<drive>.log: Garbage Collection Protokoll.
  • sm_dedup_fsck-<drive>.log: Dateisystemprüfungsprotokoll.
• Automatische Rotation, wenn die Größe der Protokolldatei 100 MB erreicht.

Dateien und Verzeichnisse

Objekte

Für jeden SEP Sesam Sicherungssatz werden drei Objekte (Dateien) im Si3 NG Store gespeichert:

• <ssid>.data
• <ssid>.info
• <ssid>.info2

Die Dateien .data und .info sind identisch mit denen eines normalen Datenspeichers. Die Datei .info2 wird für die Daten benötigt, die an ein Si3-Objekt angehängt werden sollen. In diese Datei werden alle Datenbankinformationen geschrieben, die vor Abschluss einer Sicherung nicht verfügbar sind.

Verzeichnisse

Probleme mit Bändern und Bandgeräten

Problem mit Bandlaufwerken

Problem

• Es gibt Probleme mit LTO-Bandlaufwerken, die wiederholt Reinigungsbänder anfordern. Zusätzlich misslingen Sicherungen mit I/O-Fehlern.

⇒ Lösung

Dafür gibt es zwei mögliche Ursachen:

• SEP sesam hat Probleme mit der korrekten Kommunikation mit Bandgeräten, wenn die Band-Diagnose-Tools des Hardware-Herstellers noch installiert sind, nachdem der Band-Lese/Schreib-Diagnosetest erfolgreich war. Um zu verhindern, dass die Bandlaufwerke wiederholt die Säuberungsanforderung ausgeben, und um sicherzustellen, dass Sicherungen erfolgreich abgeschlossen werden, entfernen Sie die Band-Diagnosetools sofort nach Abschluss der Diagnosetests. Es gibt zum Beispiel einige Probleme mit verschiedenen Bandlaufwerken LTO5 und LTO7. In unserem Beispiel werden Sie die folgenden Komponenten deaktivieren oder entfernen:

1. Deaktivieren Sie den HPE Versionskontroll-Agent.
2. Deaktivieren Sie alle Band-Agenten für HPE Insight Management Agents wie unten dargestellt.

1. Deinstallieren Sie HP Library and Tape Tools (L&TT) von Ihrem Server, indem Sie Programme hinzufügen/entfernen in der Systemsteuerung des Windows Rechners benutzen.

• Ähnliche Probleme können durch häufige Hardware-bezogene Probleme verursacht werden. Einzelheiten zur Hardware-Konfiguration und Fehlerbehebung finden Sie in der Dokumentation Ihres Hardware-Herstellers.

Die Rücksicherung misslingt aufgrund eines fehlenden Blocks, der nicht auf Band geschrieben wurde, aber während der Sicherung wird kein Fehler gemeldet.

Problem

• (Gilt nur für Windows SEP sesam Server oder RDS, ≤ SEP sesam Beefalo V2) In den SEP sesam Versionen von Tigon bis Beefalo V2, kann u.U. beim Sichern auf Band ein Datenblock nicht geschrieben werden, wenn die Segmentgröße zugleich mit dem Bandende - End Of Media (EOM) erreicht wird. Aus diesem Grund ist eine Rücksicherung von Daten, die diesen Block referenzieren, nicht möglich. Während im Falle eines Pfadarchivs die Daten noch bis zum Erreichen des EOM rückgesichert werden können, schlägt eine vollständige Rücksicherung oder Migration fehl.

⇒ Lösung:

1. Finden Sie heraus, ob Ihre Bänder betroffen sind, indem Sie die unten stehende Prozedur Wie entdecke ich betroffene Sicherungssätze?.

1. Aktualisieren Sie Ihren Windows SEP sesam Server auf eine neuere Version. Wenn Ihr Bandgerät an ein Windows RDS angeschlossen ist, müssen Sie das Update auf diesem RDS installieren.

Wie entdecke ich betroffene Sicherungssätze?

Die folgenden Schritte müssen auf Ihrem SEP sesam Server ausgeführt werden.

1. Überprüfen Sie den Pfad hinter gv_rw_lis in der Datei sm.ini, ob der Ordner für die Ablage ihrer LIS Dateien geändert wurde. Beispiel mit modifiziertem LIS Ordner - gesetzt auf D:\SEPsesam\var\lis\:

 [PATHES]
 gv_rw_lis=D:\SEPsesam\var\lis\

2. Öffnen Sie die Kommandozeile ('Windows Eingabeaufforderung' bzw. Linux 'Terminal') und geben Sie die folgenden Befehle ein. Wechseln sie dazu in ihren LIS-Ordner gemäß sm.ini gv_rw_lis=...:
   • Windows (default): C:\ProgramData\SEPsesam\var\lis

      cd C:\ProgramData\SEPsesam\var\lis
      findstr /R /C:"^.*:.*:0:.*:1$" *.sgm

   • Linux (default): /var/opt/sesam/var/lis

      cd /var/opt/sesam/var/lis
      grep "^.*:.*:0:.*:1$" *.sgm

3. Wenn der Befehl Zeilen ausgibt, dann inspizieren Sie die zugehörigen sgm Dateien. Im folgenden Beispiel zeigt die dritte Zeile (rot markiert) den verlorenen Block.

    1:140479734912:1088:MP_File_Full00001:38956
    1:143030262144:1089:MP_File_Full00001:48605
    <span style="color:red">1:146212528704:0:MP_File_Full00010:1</span>
    10:146212594176:1:MP_File_Full00010:55536

Die dritte Zeile zeigt Folgendes: Auf dem Band mit der ID 1: sind 146212528704 Bytes geschrieben, aber dann wird das Segment 0 angezeigt, was keiner echten Segmentnummer entspricht, sondern durch den Fehler verursacht wurde :1 der eine fehlende Block.

Probleme mit LTO-9 Bändern

Problem

• Fehlgeschlagene Sicherungen auf LTO-9-Bändern. Eingeschränkter oder fehlender Zugriff auf die LTO-9-Bänder

Mögliche Ursachen

• Sicherungsfehler oder eingeschränkter Zugriff auf LTO-9-Bänder in SEP sesam kann durch verschiedene Faktoren verursacht werden, einschließlich nicht initialisierter Bänder, inkompatibler Software, falscher Konfiguration, physischer Bandprobleme und Firmware- oder Treiberkompatibilität.

⇒ Lösung

• Um dieses Problem zu beheben, müssen die LTO-9-Bänder vor der ersten Verwendung in SEP sesam manuell mit der vom Hersteller des LTO-9-Laufwerks/Laders bereitgestellten Software initialisiert werden. Die Dauer der Initialisierung kann variieren und dauert typischerweise zwischen 20 und 120 Minuten, abhängig von den spezifischen Software- und Hardwarekonfigurationen. Sobald die LTO-9 Bänder erfolgreich initialisiert wurden, können sie in SEP sesam importiert und für Sicherungen oder Migrationen verwendet werden.

Volume Shadow Copy Service (VSS)

SEP sesam verwendet den Volume Shadow Copy Service (VSS) von Microsoft, um Sicherungen für verschiedene Auftragstypen durchzuführen. Es werden nur die VSS-Komponenten verwendet, die von Microsoft bereitgestellt werden. VSS-Fehler werden typischerweise durch die Systemkonfiguration und nicht durch SEP sesam verursacht. Beachten Sie, dass VSS einige Beschränkungen und Einschränkungen hat. Detaillierte Informationen zu VSS finden Sie im Microsoft-Artikel Volume Shadow Copy Service.

Dieser Abschnitt enthält nur begrenzte Anweisungen für die meisten häufigen VSS-Probleme. In spezifischeren und schwierigeren Fällen wenden Sie sich bitte an den Microsoft-Support (KB).

Häufige VSS-Probleme

Gehen Sie bei einem VSS Fehler die nachfolgenden Schritte durch, und testen nach jedem Schritt, ob das Problem behoben wurde.

1. Die Sicherung schlägt mit einem Fehler 10054 fehl. Die Ereignisanzeige zeigt den Fehler an: Cryptographic Services failed while processing the OnIdentity() call in the System Writer Object.

Problem

• Die VSS-Sicherung unter Windows 10 oder 2012/R2 schlägt mit einem Fehler fehl. Das Sicherungsprotokoll zeigt:

Info: Backup finished. Status: ERROR Data sending failed. (10054) An existing connection was forcibly closed by the remote host.

Genauere Informationen über die Fehlerursache finden Sie im Anwendungsprotokoll der Ereignisanzeige:

Cryptographic Services failed while processing the OnIdentity() call in the System Writer Object.
Details:
AddLegacyDriverFiles: Unable to back up image of binary Microsoft Link-Layer Discovery Protocol.
System Error:
Access is denied.

Ursache

• Die Sicherheitsberechtigungen des MSLLDP-Treibers erlauben NETWORK_SERVICE nicht den Zugriff auf den Treibersatz. Dies kann dazu führen, dass der Sicherungsprozess für lange Zeit hängen bleibt oder fehlschlägt.

⇒ Lösung

1. Öffnen Sie eine administrative Eingabeaufforderung (NICHT PowerShell) und führen Sie den folgenden Befehl als einen langen Befehl ohne Zeilenumbrüche aus (bewegen Sie den Cursor nicht an den Anfang der Zeile):

sc sdset MSLLDP D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)(A;;LCRPWP;;;S-1-5-80-3141615172-2057878085-1754447212-2405740020-3916490453)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

2. Wenn Sie ein erfolgreiches Ergebnis erhalten, z.B. [SC] SetServiceObjectSecurity SUCCESS, ist das Problem gelöst. Andernfalls müssen Sie Ihr Windows-System neu starten.

2. Windows Reboot

⇒ Lösung

• Versuchen Sie als erstes einen Windows Reboot. Ein Windows Neustart beseitigt oftmals diverse VSS-Writer Probleme.

3. Plattenplatz

Problem

• Wenn zu wenig Plattenplatz vorhanden ist, können VSS Snapshots fehlschlagen.

⇒ Lösung

• Überprüfen Sie ob ausreichend Plattenplatz vorhanden ist.

4. Mehrere VSS Sicherungs-Jobs

Problem

• Wenn mehrere VSS Jobs gestartet werden, meldet das Betriebssystem folgende VSS Fehlermeldung:

VSS_E_SNAPSHOT_SET_IN_PROGRESS

Mögliche Ursachen

• Es ist nicht möglich mehrere VSS Snapshots gleichzeitig auszuführen, Windows kann immer nur einen VSS Snapshot pro Partition starten.

⇒ Lösung

• Um generell solche VSS Fehler zu vermeiden, teilen Sie die Sicherungsaufträge eines Clients zeitlich auf, wie z.B.:
  • 22:00: Start System Recovery Sicherung
  • 23:00: Start Pfadsicherung des Systems
• Falls das zeitliche Auftrennen nicht möglich ist, versuchen Sie die nachfolgende Lösung. Dazu muss auf dem Client, welcher gesichert werden soll, in der sm.ini folgende Einstellungen gesetzt werden:

[SBC_OPTIONS]
VSS_WAIT_FOR_ASYNC_OP=600
VSS_DELAY=120
VSS_MAX_RETRY=9

Mit diesen VSS Einstellungen versucht der sesam Client VSS Operationen nacheinander auszuführen und wartet auf bereits aktive VSS Operationen. Die passenden Einstellungen können je nach System und Sicherungsaufträge variieren.

5. Sicherungssoftware von Drittanbietern

⇒ Lösung

• Überprüfen Sie, ob auf dem System eine weitere Sicherungs-Software von einem anderen Herstellern läuft, die auch Microsoft Windows VSS verwendet wie z.B:
  • Windows Backup, NTbackup
  • Acronis, Backup Exec, usw.

Deaktivieren Sie diese fremde Sicherungs-Software gegebenenfalls.

6. Alte VSS Snapshots entfernen

⇒ Lösung

• Starten Sie die CMD Kommandozeile als Administrator und geben folgenden Befehl ein:

vssadmin delete shadows /all

Der Befehl bereinigt alle VSS Snapshots aus allen Volumes.

7. VSS Writer-Status überprüfen

⇒ Lösung

• Starten Sie die CMD Kommandozeile als Administrator und geben folgenden Befehl ein:

vssadmin list writers

• Falls ein VSS writer Fehler auftaucht, starten Sie folgende Dienste neu:
  • Volume Shadow Copy Service
  • VSS writer der Applikation (z.B. Exchange, MS-SQL, Hyper-V)
  • COM+ System Application Service
  • Distributed Transaction Coordinator Service
• Mit dem erneuten Befehl vssadmin list writers überprüfen Sie ob das Problem behoben wurde.

8. Windows Ereignisprotokoll überprüfen

⇒ Lösung

• Überprüfen Sie die Ereignisprotokolle der Windows Ereignisanzeige, und suchen dort nach VolSnap Fehlern, welche zum Zeitpunkt des SEP sesam Sicherungsauftrags passen.
• Oft hilft es dann, im Internet nach der Ereignis ID des Fehlers zu suchen, um einen Hinweis für die eigentliche Fehlerursache zu bekommen.

9. VSS- und COM+-Komponenten umregistrieren

Schritt 1:

• Die folgenden Skripte registrieren alle VSS- und COM+-Komponenten neu.
• Kopieren Sie die Befehle in eine neue *.bat Datei. Starten Sie das Batch-Skript in der Kommandozeile als Administrator:

Für 64-Bit und 32-Bit Systeme:

cd /d %windir%\system32
Net stop vss
Net stop swprv
regsvr32 ole32.dll
regsvr32 vss_ps.dll
Vssvc /Register
regsvr32 /i swprv.dll
regsvr32 /i eventcls.dll
regsvr32 es.dll
regsvr32 stdprov.dll
regsvr32 vssui.dll
regsvr32 msxml.dll
regsvr32 msxml3.dll
regsvr32 msxml4.dll
regsvr32 Vssapi.dll
regsvr32 Vssui.dll
net start vss
net start swprv

Schritt 2:

• Kopieren Sie die Befehle in eine neue *.bat Datei. Starten Sie das Batch-Skript in der Kommandozeile als Administrator:

Für 64-Bit Systeme:

Net stop vss
Net stop swprv
regsvr32.exe /i %windir%\system32\eventcls.dll
regsvr32.exe /i %windir%\system32\swprv.dll
regsvr32.exe %windir%\system32\vssui.dll
regsvr32.exe %windir%\SysWOW64\vss_ps.dll
regsvr32.exe %windir%\SysWOW64\msxml.dll
regsvr32.exe %windir%\SysWOW64\msxml2.dll
regsvr32.exe %windir%\SysWOW64\msxml3.dll
regsvr32.exe %windir%\SysWOW64\msxml4.dll
regsvr32.exe %windir%\SysWOW64\ole32.dll
regsvr32.exe %windir%\SysWOW64\oleaut32.dll
regsvr32.exe %windir%\SysWOW64\es.dll
regsvr32.exe %windir%\SysWOW64\comsvcs.dll
vssvc /register
net start swprv
net start vss
net stop winmgmt
regsvr32 wmiutils.dll  
net start winmgmt 

10. VM Utility Update

⇒ Lösung

• Wenn das System eine virtuelle Maschine ist, deinstallieren Sie die installierte Utility Version und starten die VM neu. Danach installieren Sie wieder die aktuellste Utility Version:
  • VMware vSphere: VMware Tools
  • Microsoft Hyper-V: Hyper-V Integration Services
  • Citrix XenServer: XenServer Tools

11. Windows Aktualisierung

⇒ Lösung

• Installieren Sie die neuesten Windows Aktualisierung, Service Packs und Hot-Fixes von Microsoft.
• Führen Sie nach der Aktualisierung einen Test durch.

VSS Sicherunge schlägt mit einem VSS Fehler fehl

Wenn beim Sichern Ihres Windows-Clients ein VSS-Fehler auftritt, müssen Sie die Ursache herausfinden. Öffnen Sie die Windows Ereignisanzeige und überprüfen Sie die entsprechenden Protokolle. Diese Fehler können eine der folgenden sein:

"VSS_ERROR_UNEXPECTED_ERRORCODE" 
"VSS_E_PROVIDER_VETO"
"VSS_E_VOLUME_NOT_SUPPORTED" 

	Anmerkung
	Sie können ähnliche Fehlermeldungen und/oder abgebrochene Sicherungen erhalten, wenn Sie versuchen, eine VSS-Sicherung auf Volumes durchzuführen, die größer als 64 TB sind, selbst wenn die Volumes von der Sicherung ausgeschlossen sind. Beachten Sie, dass beschreibbare Snapshots oder Snapshots, die größer als 64 TB sind, denselben Fehler verursachen.

Microsoft gibt in dem Artikel Usability limit for Volume Shadow Copy Service (VSS) in Windows die Begrenzung auf "64 TB" an.

Die oben genannten Fehler können durch eine der folgenden Punkte verursacht werden:

Problem 1

• Wenn Sie versuchen, eine VSS-Sicherung mit Volumes, die größer als 64 TB sind, auf einem Windows-Server durchzuführen, erhalten Sie den folgenden Fehler:

"DB Module: [ [NInternal::CVssAsyncDecorator::Wait] - S_OK]"

und die Windows Ereignisprotokolle zeigen ein VSS-Ereignis ID 12289

"VSS_ERROR_UNEXPECTED_ERRORCODE" 

Ursache

• Microsoft hat eine Beschränkung von 64 TB als maximale Größe für Volumes bei der Durchführung von Sicherungen mit VSS. Es ist nicht möglich, VSS für größere Volumes zu verwenden, selbst wenn diese von der Sicherung ausgeschlossen sind.

⇒ Lösung

• Aktivieren Sie den Volumeschattenkopie-Dienst (Volume Shadow Copy Service) für alle Laufwerke: Klicken Sie mit der rechten Maustaste auf eines der aufgelisteten Festplattenlaufwerke und klicken Sie auf Schattenkopien konfigurieren. Klicken Sie im Fenster Schattenkopien auf Aktivieren und aktivieren Sie dann Schattenkopien für alle Laufwerke.

Problem 2

• Wenn Sie versuchen, eine VSS-Sicherung eines Volumes mit einer Größe von mehr als 60 TB durchzuführen oder wenn Sie VSS-Sicherungen von mehreren Volumes in Windows Server 2008/Windows Storage Server 2008 erstellen, schlägt die VSS-Sicherung mit der folgenden Meldung fehl:

ERROR: [CVssServer::CreateSnapshot(): IVssBackupComponents::DoSnapshotSet: WaitForAsyncOperation] - VSS_E_PROVIDER_VETO 

Mögliche Ursachen

• Wie bereits erläutert (siehe obige Anmerkung), hat Microsoft eine Grenze für die Verwendbarkeit von Volumes und Snapshots mit VSS gesetzt.

• Dieser Fehler kann auch auftreten, wenn ein VSS-Anbieter die Snapshot-Erstellung aus folgenden Gründen blockiert: Die Software wurde mit einem eigenen VSS-Anbieter installiert oder die vorhandene VSS-Komponente ist beschädigt.

• HP Device Access Manager (FLCDLOCK-Dienst; Teil der HP Protect Tools-Suite) verhindert, dass VSS-Vorgänge ordnungsgemäß auf Laufwerkspartitionen zugreifen.

⇒ Lösung

• Aufgrund der Beschränkung in volsnap.sys sollten Sie keine Volumes, die größer als 60 TB sind, als Sicherungsquelle oder Ziel für Windows-Sicherungen verwenden.
  • Entfernen Sie Volumes mit mehr als 60 TB aus der VSS-Snapshot-Aktion.
  • Konfigurieren Sie alle Festplatten mit einer aktuellen Größe von mehr als 60 TB auf 60 TB oder weniger um, um zu verhindern, dass VSS bei der Erstellung des Snapshots stoppt.
  • Überprüfen Sie auch die Größe des Schattenspeichers auf den jeweiligen Laufwerken und erhöhen Sie sie (falls erforderlich). Verwenden Sie das Kommandozeilenprogramm Vssadmin von einer erweiterten Eingabeaufforderung aus (wobei c: durch das richtige Laufwerk ersetzt werden sollte):

vssadmin Resize ShadowStorage /For=C: /On=C: /Maxsize=5%

• Beheben Sie die VSS-Probleme und registrieren Sie dann die VSS-Komponenten erneut. Überprüfen Sie außerdem die Größe des Schattenspeichers auf den betreffenden Laufwerken und erhöhen Sie sie (falls erforderlich) mit dem Befehlszeilenwerkzeug Vssadmin, wie in der vorherigen Lösung beschrieben.

• Deinstallieren Sie HP Device Access Manager und starten Sie Ihr System neu. Beachten Sie, dass eine unvollständige Deinstallation von HP Device Access Manager zu Problemen führen kann.

Sie können ein Entfernungsprogramm eines Drittanbieters verwenden, um Device Access Manager für HP ProtectTools korrekt und vollständig zu deinstallieren. Weitere Informationen finden Sie in dem Artikel von UninstallHelps.com How to uninstall Device Access Manager for HP ProtectTools?.

	Anmerkung
	Der angegebene Link führt Sie zu einer Website von Dritten. SEP stellt diese Links nur zu Informationszwecken zur Verfügung und ist nicht verantwortlich für die Informationen, die Verfügbarkeit oder die Richtigkeit dieser externen Ressourcen.

Problem 3

• VSS Pfadsicherung von einem Windows Speicherplatzvolume schlägt mit einem Fehler fehl:

Error:   DB Module: [ [CVssServer::WaitForAsyncOperation: IVssAsync::QueryStatus] - VSS_E_PROVIDER_VETO]

Ursache

• VSS Snapshots werden für Windows Speicherplätze nicht unterstützt.

⇒ Lösung

• Um Daten von Windows Speicherplatzvolumes zu sichern, müssen Sie die Option Sicherung mit VSS (standardmäßig aktiviert) in den Eigenschaften des Sicherungsauftrags deaktivieren. Für Details, siehe Deaktivieren/Aktivieren von VSS-basierten Sicherungen.

HPE StoreOnce Catalyst

HPE StoreOnce-Sicherungen schlagen fehl

Wenn Ihre Sicherungen fehlschlagen, könnte einer der Gründe mit den HPE StoreOnce-Größenparametern zusammenhängen. Überprüfen Sie in diesem Fall die folgenden Punkte:

• Wenn Sie für Ihren Catalyst-Speicher entweder eine physische oder ein logische Datengrößenquote definiert haben, prüfen Sie, ob die Grenzen erreicht wurden. Wenn ja, erhöhen Sie die Quote auf die ausreichende Größe. Einzelheiten finden Sie unter HPE StoreOnce Konfiguration.
• Wenn Sie einen HPE Catalyst-Datenspeicher in SEP sesam erstellt und später die Größenparameter des HPE Catalyst-Speichers geändert haben, z. B. durch Ändern oder Entfernen seiner Datengrößenquoten, überprüfen Sie die Werte in der SEP sesam GUI: Auswahl -> Komponenten -> Datenspeicher, doppelklicken Sie auf Ihren StoreOnce Speicher und klicken Sie dann auf den Reiter HPE Catalyst Speicherstatus. Wenn der Status des Datenspeichers auf fehlgeschlagen gesetzt ist, müssen Sie möglicherweise die Werte für den StoreOnce-Datenspeicherkapazität und den oberen Schwellenwert anpassen, um eine korrekte Berechnung zu ermöglichen und den Datenspeicher wieder funktionsfähig zu machen. Details finden Sie unter Größe und Speicherplatzverbrauch.

HPE StoreOnce Sicherung schlägt fehl mit "553 STOR Failed. Error: Ctl_OpenObject failed, error: OSCLT_ERR_MAXIMUM_SESSIONS. (0)"

Problem

• HPE StoreOnce-Sicherung schlägt mit 553 STOR Failed. Error: Ctl_OpenObject failed, error: OSCLT_ERR_MAXIMUM_SESSIONS. fehl. Dieses Problem kann auftreten, wenn eine HPE StoreOnce Catalyst-Datensitzung nicht geöffnet werden kann, weil die maximale Anzahl von Sitzungen auf dem HPE StoreOnce Catalyst-Server erreicht ist und daher keine weitere Sitzung gestartet werden kann, bis Ressourcen verfügbar sind. Sie können die Anzahl der freien Datensitzungen in SEP sesam überprüfen, indem Sie die Eigenschaften Ihres HPE StoreOnce-Datenspeichers öffnen und auf den Reiter HPE Catalyst Speicher Status klicken und dann den Wert Free data sessions überprüfen.

⇒ Lösung

Es gibt zwei mögliche Lösungen:

• Der HPE Catalyst-Server unterstützt eine begrenzte Anzahl von gleichzeitigen Datensitzungen. Daher müssen Sie sicherstellen, dass die maximale Anzahl von Datensitzungen für Ihr HPE StoreOnce nicht überschritten wird, oder die maximale Anzahl von Datensitzungen (einschließlich Rücksicherungen) erhöhen, die gleichzeitig ausgeführt werden können.
• Öffnen Sie SEP sesam und doppelklicken Sie in der Auswahl -> Komponenten -> Datenspeicher auf Ihren HPE StoreOnce Datenspeicher, um die Eigenschaften zu öffnen. Klicken Sie dann unter Laufwerke auf das entsprechende Laufwerk, um dessen Eigenschaften anzuzeigen. Verringern Sie in der Auswahlliste Max. Anzahl Kanäle die Anzahl der verfügbaren Kanäle für gleichzeitig ausgeführte Sicherungs-/Migrationsströme. Standardmäßig ist die Anzahl der verfügbaren Kanäle entsprechend Ihrer SEP sesam Server Lizenz eingestellt (z.B. unterstützt die Standardlizenz 10 gleichzeitige Ströme, so dass 10 Sicherungsprozesse gleichzeitig laufen können).

Proxmox VE

Proxmox VE backup does not work with the client name as plain IP address

Problem

• If the node added to the SEP sesam environment is not set up correctly and an IP address is used as the client name instead of the client's hostname matching the hostname returned by the Proxmox server, the backup fails.

⇒ Lösung

• This problem can only be solved by correctly configuring the Proxmox clients in the SEP sesam environment. For more details how to correctly configure the client name, see Proxmox VE Backup: Adding the Proxmox server (and nodes) to the SEP sesam environment.

Proxmox VE backup failed with a connection error

Problem

• Proxmox VE backup failed with Error connecting to proxmox System: "('Connection aborted.', gaierror(-2, 'Name or service not known'))"]. This error occurs after a VM has been migrated to another cluster node. Consequently, the Proxmox VE backup fails.

⇒ Lösung

• Ensure that every Proxmox VE cluster node can correctly resolve other cluster nodes using DNS or the Hosts file.

File backup of Proxmox hypervisor fails

Problem

• Backup of /etc/pve/ fails.

⇒ Lösung

• Exclude the /etc/pve/ directory from backup. /etc/pve/ is just a file system representation of the cluster database, which is located under the path /var/lib/pve-cluster/config.db. For more information, see the Proxmox wiki article. For more information, see also Proxmox Cluster File System (pmxcfs).

Siehe auch

Analysieren der SEP sesam Protokolldateien – Fehlermeldungen interpretieren - Error Messages Guide – SEP sesam Exit Codes

Copyright © SEP AG 1999-2023. Alle Rechte vorbehalten.

Jede Form der Reproduktion der Inhalte dieses Benutzerhandbuches, ganz oder in Teilen, ist nur mit der ausdrücklichen schriftlichen Erlaubnis der SEP AG gestattet. Bei der Erstellung dieses Benutzerhandbuches wurde mit größtmöglicher Sorgfalt gearbeitet, um korrekte und fehlerfreie Informationen bereit stellen zu können. Trotzdem kann die SEP AG keine Gewähr für die Richtigkeit der Inhalte dieses Benutzerhandbuches übernehmen.