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 ein Tageswechsel-Ereignis verursacht wurde. Sie können verhindern, dass der Tageswechsel laufende Aktivitäten abbricht, wie unter Tageswechsel Ereignis.
• 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 Backups 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 (EN) / Forum (DE).
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 Backup-Job gibt, wählen Sie in der GUI 'JOB STATUS'- 'SICHERUNGEN' - Rechtsklick auf den betroffenen Job und wählen Sie den untersten Menüpunkt 'Archiv mit allen LOG-Dateien herunterladen' -> Bitte senden Sie das erstellte LOG-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.

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 Topologie 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 .

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 Template:Pfad 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 Backup 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 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 Backup-Server und dem Backup-Client blockiert den Zugriff.
  • Der SEP sesam Client Agent läuft nicht auf dem System.
  • Other network related errors.

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

To display the read data:

 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-Backup-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 Template:Pfad:

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

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

Fehlgeschlagene Backups 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 Savesets manuell verlängern. Für Details, siehe Manuelles Verlängern der EOL. Beachten Sie, dass SEP sesam automatisch das letzte erfolgreiche Backup-Saveset 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 Ursachen

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

⇒ Lösung

Check the tape drive and backup media.

Backup to data store fails

Problem

Backup (or migration) to data store fails with the error message All available space of media is used, stop writing to media.

Mögliche Ursachen

• SEP sesam aborts a data transfer because less than 1 GB is available on the data store (disk storage). A disk failure can also cause this problem.

⇒ Lösung

• The following points may help to resolve the problem:
  • Check the system messages on Linux or the event log on Windows for any hardware problems.
  • Remove orphaned savesets from the data stores by using the Clean up option, see Data Store.
  • Reset the EOL of backups and start a purge process for the data store to delete the obsolete (EOL-free) savesets. For details, see Purging a Data Store.
  • Increase the disk space.

Run FSCK on the disk storage.

If you cannot solve this issue, report it to SEP sesam support. The support team will then provide you further instructions.

Incorrect login or password

Problem

• During backup, the message "Login incorrect. Password incorrect" is displayed.

⇒ Lösung

• Check your name resolution (DNS or etc/hosts file). The SEP sesam Server and SEP sesam Client must be reachable with or without FQDN and should be able to resolve each other correctly, including the reverse lookup. If the resolution is correct, do the following:

1. In the SEP sesam GUI, go to Main Selection -> Tasks -> By Clients, and select the client with the backup problem.
2. Open the backup properties and click the Options tab.
3. Type -v 4 at Save options.
4. Start the backup again, then go to Main Selection -> Job state -> Backups and double-click the backup task to open its properties.

Go to Logging -> Day log and search for the line Login incorrect. Password incorrect then correct the name resolution.

Data transfer via FTP fails with XBSA Initialisation error

Problem

• At the beginning of a backup data transfer via FTP, the following error message appears:

- 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

This problem can be caused by the following:

• Active firewall on the system that is supposed to transfer the backup data between SEP sesam Server and Client.
• Routing or Network Address Translation (NAT) between the systems involved.

⇒ Lösung

The following steps can help to solve the problem:

• In the case of a firewall problem:
  • Disable the firewall.
  • Adjust the firewall application-based. This needs to be done on system, which should transfer the data. SEP sesam uses active FTP. When starting regular file backups on Windows add binary sbc.exe to the firewall exclude list. In case of BSR on Windows also add binary oodiag.exe to the firewall exclude list.
  • Customize the firewall port-based. Make sure that all required ports are available on the system and are not blocked by a firewall. If a port range is open, it is important that you configure that port range in the STPD options for the client. For details, see Port numbers for SEP sesam Client.
• In case of a router/NAT, adjust the rules to allow SEP sesam RDS and Client to transfer data.

Ausfall der Netzwerkverbindung auf physischen oder virtuellen Systemen

Problem

• Sicherungen physikalischer oder virtueller Systeme mit SEP sesam schlagen fehl (Netzwerkverbindungsfehlers fehl 10054). Die Logfiles 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 Clienten, 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 Clienten, 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 Backup Server 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 FAQ: 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

Fur 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.

ON WINDOWS

	Anmerkung
	{{{1}}}

Path backup on Windows is not working

Problem

• SEP sesam Server failed to execute a path backup of a Windows client (however, a path backup without VSS is working). The following error is displayed:

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

• Typically, when dll cannot be initialised, a running antivirus solution is preventing it.
• The client's VSS configuration is incorrect.

⇒ Lösung

• Disable the antivirus software during backup.
• Check the client's VSS configuration by running the following commands:
  • vssadmin list writers - check the status of all writers on a daily basis
  • vssadmin list shadows - check existing VSS copies
  • vssadmin list shadowstorage - check how much space is reserved and available space for VSS
  • vssadmin resize shadowstorage - set the reserved space for VSS snapshots to unlimited

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 Backup Protokoll:

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 Ursachen

• Insufficient size of the registry/paged memory area. This problem affects SEP sesam as well as other backup tools, such as NTBackup.

⇒ Lösung

• The Microsoft article Backup program is unsuccessful when you back up a large system volume explains approaches for different versions of Microsoft Windows.

System state backup is backing up large amount of data due to DFS

Problem

• When performing a Windows system state backup on the server that runs DFS (Distributed File System), large amount of data is backed up and the backup is slow.

Mögliche Ursachen

• If the DFS replication is enabled, the system state backup may include all the data from the DFS Replication service too.

⇒ Lösung

	Anmerkung
	{{{1}}}

• Exclude the DFS writer from the system state backup task in the SEP sesam GUI: from the Main Selection -> Tasks -> By clients, select your Windows client then click New backup task. In the New backup task window switch to the Options tab and under Additional call arguments -> Backup options exclude the DFS writer as follows:

-x "VSS:/DFS Replication service writer"

Next, you have to back up the file system data, served by the DFS, separately by performing a regular Path backup (create a Path task type instead of a System_state backup task). For details, see Backing up System State.

System_State backup (RegLoadKey) error

Problem

• Warnung beim System_State Backup "Das System kann den angegebenen Pfad nicht finden. RegLoadKey()..."
• Folgende Fehlerausgabe ist im NOT-Log 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 Ursachen

• There are inconsistencies in the OS configuration. The reason is that a user profile has been deleted but the user account still exists. System_State backup is looking for files corresponding to the user in the file system but the files no longer exist.

⇒ Lösung

• Delete the user in question or restore the profile date in the file system.
• Ü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

Access denied during Microsoft Windows backup via VSS

Problem

Why does a Microsoft Windows backup via VSS stop with the message "[CVssBaseObject::CreateVssBackupComponents] - Access denied"?

Mögliche Ursachen

• SEP sesam is not allowed to create a snapshot with the current user.

⇒ Lösung

Check the user running the SEP sesam daemon and make sure that the user has all permissions to access the volume(s).

Stream data length exceeds buffer capacity

Problem

What does the warning "Stream data length bigger than buffer can accept. Input buffer length = [65536], Stream data size = (High part)[0] (Low part)[65564]" ?

Mögliche Ursachen

• SEP sesam uses 64 kB to back up Windows ACL files and folders and one object exceeds this buffer. You can use the Windows command icacls to display the ACL of a file or folder. The output looks like this:

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

If you get several hundred or thousand lines, there is something wrong with the ACL.

⇒ Lösung

• Reset the permissions of the file's respective folder by using the command:

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

This command inherits the permissions of the parent object. You may have to adjust the permissions after running this command if manual settings have been applied for this object.

Backup on Windows 7 did not complete successfully

Problem

• When you perform a Windows 7 backup, the backup might fail with one of the following errors.

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]

• To see more detailed error, view the Event Log on your Windows client: Event Viewer -> Windows Logs -> System. The Event Id 33, volsnap shows the following message:

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

• There was not enough disk space for the Volume Shadow Service to take a snapshot; consequently, the operating system automatically deleted the snapshot due to the lack of space.
• This error occurs if the snapshot size exceeds the snapshot Maximum size: Use limit configured for the volume.

⇒ Lösung

• Check the Maximum size: Use limit on your Windows 7 client: Open a Windows Explorer on the client and right-click the drive letter to open the drive properties. Select the Shadow copies tab -> Settings -> check the Maximum size: Use limit:
  • If you select No limit, Windows will not delete the snapshot regardless of how much space it consumes. Note, however, that in case of a large snapshot the process might be failing to create the snapshot because there is not enough disk space left on the respective drive.
  • If you specify Use limit, change the maximum size limit to a large enough value to contain the snapshot with room to spare. According to Microsoft, it is recommended to set the maximum size limit to a value that equals 10% of the volume size. For example, if the C:\ drive has 100 GB of data, the limit should be set to 10 GB. Or, you can store the shadow copy data on another disk. For details, see Microsoft forum answers Shadow Copy.

ON LINUX

SEP sesam Linux Client error during backup

Problem

A SEP sesam Linux Client (SBC) issues an error or warning during backup.

Mögliche Ursachen

Backup on Linux may finish with an error or warning if:

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

⇒ Lösung

• To avoid these warnings and resolve the above errors, double-click the backup task to open its properties and under the Options tab in the Backup options field enter the following command:

-o ignore_finderr=<regex>|ALL

• If you want to avoid all such errors/warnings, specify:

-o ignore_finderr=ALL

GVFS error during Linux backup

Problem

• If a user is logged on to the gnome or kde session and makes use of the GVFS layer, the directory ~/.gvfs is created. This directory cannot be entered by any other user (even root).
• Additionally, the system call "stat" also errors out on this directory. The directory cannot be excluded, because while creating the file list and looking at the excludes, sbc_find once does a "stat()" call on the directory and receives an error.

⇒ Lösung

• Create a new file named /etc/profile.local with the contents below /etc/profile.local:

GVFS_DISABLE_FUSE=1 
export GVFS_DISABLE_FUSE

• Run the following commands for each affected folder:
  • 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 on Linux

Problem with a ReaR backup execution

Problem

• SEP sesam Client package was successfully installed and path backups are working. If you have problems executing a ReaR backup check the backup log if there are some missing dependencies.
Beispiel:

<div lang="en" dir="ltr" class="mw-content-ltr">
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
</div>

Ursache

• In this case the package libvirt-client is missing.

⇒ Lösung

• Depending on your distribution, install libvirt-client as follows:
  • On RHEL/CentOS 7 use the command:

yum install libvirt-client

• • On SLES 12/15 use: zypper install libvirt-client

The workflow mkrescue is not supported in the ReaR system

Problem

• The workflow mkrescue is not supported in the ReaR rescue/recovery system.

⇒ Lösung

• Delete the file /etc/rear-release.

ReaR image hangs during bootup

Problem

• The system hangs during bootup like shown in the following image:

⇒ Lösung

• Boot the system with the ACPI=OFF option (this option can be specified on the command line in the boot menu prompt, after the options BACKUP=SESAM OUTPUT=ISO).

The recovered system does not boot

Problem 1

• The system does not boot because /root/dev/console cannot be found.

Possible causes

• Certain distributions rely on the existence of the directory /dev/ while booting
• Certain static devices must exist before the udev daemon creates them.

⇒ Lösung

• Include the /dev/ file system in your backup.
• If the restore cannot restore /dev/:

Boot from the SEP sesam LIVE CD.

1. Mount the ROOT partition of the restored system.
2. Manually create the /dev/ directory.
3. Manually create the /dev/console entry with:

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

Problem 2

• The system does not boot because of missing libblkid.so.1.

Mögliche Ursachen

• This is most likely caused by SELinux which is activated by default.

⇒ Lösung

• Especially on RHEL6 or CentOS6 systems, follow these steps after rebooting from the ReaR recovery:
1. Press a key when prompted by the boot loader (GRUB):

2. Select the appropriate boot loader entry:

3. Press e to modify the commands for the selected entry:

4. Add selinux=0 to the commands:

5. Press Enter to confirm the changes and b to boot up the machine with SELinux disabled.
6. When having access to the system, change the option SELinux of /etc/selinux/config to the following:
SELINUX=permissive

Afterwards, reboot the system and feel free to set the SELinux value back to enforcing if needed.

No bootable operating system can be found

Problem

• The system is not able to find a bootable OS instance after the restore.

Possible causes

• There may have been problems during the installation of the GRUB boot loader.

⇒

Solution

• The restore protocol includes a statement whether or not the installation of the boot loader was successful:

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

It is also possible to boot the system again from the live-CD, mount the target partitions and use grub-install to install the boot loader correctly.

The device does not have a corresponding BIOS drive

Problem

• During the restore, the following error occurs:

/dev/sda1 does not have any corresponding BIOS drive

Possible causes

• Check the file /boot/grub/device.map on the target system. If there are entries referring to the disk through /dev/by-disk/... as shown in the example below, the entry is most likely the reference to the hard disk partition of the broken system. GRUB will not find the proper device:

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

⇒

Solution

• Reboot from the live-CD
• Mount the root and boot partitions to /mnt/disk (and /mnt/disk/boot, if necessary)
• Restart grub-install with the following options:

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

Output:

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

You can ignore the error line 374: [: =: unary operator expected.
More important is the result Installation finished. No error reported.

No corresponding BIOS drive for /dev/cciss/c0d0p2

Problem

• You receive the message: /dev/cciss/c0d0p2 does not have any corresponding BIOS drive in restore log.

⇒

Solution

• Please see: Novell support

fsck.ext3: File system has unsupported features

Problem

• During a restore of a system with kernel version 2.4 the system may not boot because the Live-CD creates a file system with features which are not supported by kernel 2.4.

Possible causes

• Most likely the file system options resize_inode,dir_index,large_file,ext_attr are causing the problem and making the system unbootable.

⇒

Solution

• Reboot from the Live-CD image, which includes the tool debugfs.
• Show the file system features with 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

Replace /dev/sda2 with the corresponding partition names on your system.

• To remove file system features:

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

After removing the options, the system should boot correctly.

Incorrect inode size (256)

Problem

• After a successful restore the boot process stops with incorrect inode size (256).

Possible causes

• Older kernel versions (2.4) may use a different inode size than the one the file system's created through the Live-CD (which includes kernel 2.6). For example, this happens during the restore of SLES8 based systems which use an inode size of 128k.

⇒ Lösung

• This can only be solved by formatting the devices manually from the Live-CD, using the proper mkfs options:

mkfs.ext3 -I 128 /dev/sda1

After this step, remount the partition to /mnt/disk and repeat the restore operations. Changing the inode size is only possible by reformatting the devices.

Missing root file system

Problem

• The restored system can't find a root file system and fails during resume.

Possible causes

• The /etc/fstab file was configured with the root file system as UUID.

⇒ Lösung

• Specify the root file system device name in conventional device names if you are using a different physical disk. After booting, use YAST to reconfigure your boot loader or edit your /boot/grub/menu.lst manually:

root=/dev/sda2

Missing network cards

Problem

• The restored system does not find any network cards.

Possible causes

• If the restore was done to dissimilar hardware, SLES-based distributions may not configure the network devices correctly. SLES-based systems save their network configuration by using the system's MAC address. Most likely the system will not use eht0 as a device name, but eth1, as it has another MAC address.

⇒

Solution

• Use YaST and reconfigure your network interfaces.

Client does not start on the RHEL6/Debian9 recovery image

Problem

• The SEP sesam Client does not start automatically on RHEL6 and Debian9-based recovery images.

Cause

• The file /etc/init.d/functions is missing within the recovery image.

⇒

Solution

• The client can be started manually via:

/opt/sesam/bin/sesam/sm_main start

RHEL7-related issues

RHEL7 backup fails with an error

Error 1

• The RHEL backup fails with the following error:

ERROR: The LSB package is not installed.

⇒ Lösung

• Install the lsb package as follows:

yum install redhat-lsb-core mkisofs syslinux

Fehler 2

• The RHEL backup fails with:

ERROR: Cannot find required programs: mingetty

For more details, see Rear dependencies on RHEL7.

⇒ Lösung

To solve this problem, proceed as follows:

1. Edit

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

and from the line:

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

remove the line:

 mingetty

Run the backup again.

ReaR error occurred during grub2-mkimage of bootx64.efi

	Anmerkung
	{{{1}}}

Problem

• The ReaR error occurrs during grub2-mkimage of bootx64.efi.

⇒

Solution

• To solve the problem, install the grub2-efi-x64-modules package.

SLES-related issues

SM_SSH does not work on SLES11 recovery image

⇒ Lösung

• In this case, execute

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

before starting the recovery process.

Client is unreachable after booting the rescue image

Problem

• After booting the rescue image the client is not reachable.

⇒ Lösung

• Start the client manually using the following command on the rescue command line:

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

EFI bootable image cannot be created on SLES11

Problem

• EFI bootable image of GRUB2 cannot be created on SLES11.

Cause

• SEP sesam v. 4.4.3.64 Grolar is the last version that supports SLES11 with UEFI.

⇒

Solution

• To continue using SLES with UEFI, you should not upgrade to a later version of SEP sesam.

====

Installing ebiso for creating UEFI aware ISO images ====

In order to be able to create an UEFI/EFI bootable ISO image the, the additional tool ebiso has to be installed on the client system. This package is not part of a regular SLES12/SLES15 installation and can be downloaded at the following URL:

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

oder

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

For other Linux distributions contact SEP support at support@sep.de for assistance.

Install ebiso as follows:

rpm -i ebiso-<version>.rpm

Note that in ReaR v. < 1.19, the generated ISO image mount migt be too small for storing all needed information and need to be adjusted.

In this case, under

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

change

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

to

(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 Ursachen

• 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.
• Eintrag für den Computer in sm java.policy fehlt. Zum Beispiel:

// NET
permission java.net.SocketPermission "'mypcname:*"',
"'connect,accept,resolve"';

• Ein Problem mit der Bildschirmauflösung.

⇒ Lösung

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

Problem beim Lesen/Beschreiben des Arbeitsverzeichnisses

Problem

• Es gibt ein Problem beim Lesen oder Schreiben in das Arbeitsverzeichnis.

Mögliche Ursachen

• Eintrag für das Arbeitsverzeichnis in sm java.policy fehlt:

Beispiel Windows

// FILE
permission java.io.FilePermission
"'D:nsesamnvarn-"', "'read,write"';

Beispiel Linux/Unix/Tru64

// FILE
permission java.io.FilePermission
"'/sesam/var/-"', "'read,write"';

⇒ Lösung

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.

Hinweis

Die Nutzerrechte von fehlenden Computern können auf Serverseite mit dem Programm sm_setup allow_gui {host} {user} in die java-policy-file eingegeben werden. Nach den Änderungen in der sm_java.policy der GUI-Server is ein Neustart nicht erforderlich. Aktualisierung ist in sm_java.policy ausdrücklich erlaubt mit dem Eintrag permission java.security.SecurityPermission "getPolicy";. Die Syntax der Pfadnamen in der sm_java.policy sind platfromabhängig. Um zu testen, ob es in der Java Sicherheit Probleme gibt kann die Zeile permission java.security.AllPermission; unkommentiert werden (vorangehende '//' entfernen). So wird die Beschränkung auf genau bestimmte Rechte abgschaltet. Um Sicherheitslöcher zu vermeiden sollte diese Zeile nach dem Test wieder auskommentiert werden ('//' wieder voranstellen).

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 gbit, muss die Auflösung für diese IP-Adresse den selben 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 backup fails with VSS API error due to missing Microsoft Exchange VSS writer

Problem

When backing up Exchange, the backup fails because the Microsoft Exchange VSS writer required for backup is missing. The following error occurs:

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.

This error occurs when one or more writers required for backup are missing or not available. Note that this is not the same as VSS error or failed VSS. In the latter case, check Common VSS problems.

A writer is consider missing, if running (as administrator) the Microsoft command-line tool vssadmin list writers shows no available Microsoft Exchange VSS writer. If a VSS writer is missing, all backups that use that writer to perform VSS snapshots will fail. A missing writer is a failure of the Windows operating system. To fix this issue, Windows registry needs to be edited. SEP sesam cannot back up any data until the required VSS writers are available.

Lösung

	Anmerkung
	{{{1}}}

To enable Microsoft Exchange VSS writer, on the Exchange server open and edit the registry with the following key value:

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

If the key already exists with a value of 1, change the value to 0. (Value 1 disables the Microsoft Exchange Writer.) For more information on enabling VSS Exchange writer, refer to How to turn on the Exchange writer for the Volume Shadow Copy service (it is marked as relevant for Windows Small Business Server 2003, but the procedure can also be applied to later versions).

Then restart the Microsoft Exchange Information Store service:

1. Log in to the Exchange server and click Start.
2. Enter services.msc in the search box, and press Enter. The Services window opens.

From the list of services, right-click the Microsoft Exchange Information Store service (MSExchangeIS), and then click Restart. Note that during restart the users will be disconnected from Exchange.

After restarting Exchange, in the command prompt enter vssadmin list writers and verify that the VSS writers are listed. Then run your Exchange backup again.

===

Exchange logs truncation errors ===

Problem

The Exchange logs are not truncated or the log files are missing.

Ursache

Exchange database log truncation is part of Exchange services. SEP sesam notifies Exchange Writer of each successful backup of Exchange Server and Exchange DAG nodes. SEP sesam does not manage or delete Exchange logs and is therefore not responsible for truncating logs, Microsoft Exchange Writer is. SEP sesam only notifies Exchange of the backup status and then:

• In configurations without DAG, Exchange Writer truncates the transaction log files after a successful full or incremental backup.
• In DAG replicated configurations, log truncation is delayed by the replication service until all required log files have been replayed into all other copies. The replication service deletes the backed-up log files from both the active and the copy log file paths after verifying that the log files have been successfully applied to the copy database and that both the active database and the database copies checkpoint have passed the log files to be deleted.

⇒ Lösung

To verify that Exchange log truncation has been called, check the Applications and Services Logs and look for errors related to the Exchange VSS or Replica writer.

Check ESE events with ID:

• 224: This event indicates that logs are being deleted and denotes the associated database.
• 225: This event indicates that there are no logs available for truncation (either ESE cannot determine whether the transaction log files have been committed to the Exchange Server database, there are not enough logs or Circular Logging is enabled).

299: The replication service truncates the log stream and removes transaction logs that are no longer needed (or reports that there is not a minimum amount of logs for truncation).

If the Exchange configuration uses DAG, the replication process between the different nodes can prevent log truncation in case of errors. These errors are indicated with the event source MSExchangeRepl.

Below are some entries from the application log in the Event Viewer (for a list of errors, see the Microsoft article 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.

If errors occur in connection with the Exchange VSS or Replica Writer, check the Exchange configuration to determine the cause and resolve the errors. Such errors cannot be caused by SEP sesam, but until they are resolved, Exchange cannot truncate the log files, resulting in filling up the volume or disk where they reside.

Also check the current status of the VSS writer by running the following at an administrative prompt on the Exchange server:

   vssadmin list writers

If the writer is missing or is in a failed state, reboot the Exchange server and verify that it is now listed and showing as stable. Then restart the SEP sesam Exchange backup task and check the log truncation.

Exchange Recovery Pro asks for License

If you have started Exchange Recovery Pro the first time you get prompted to install the license. If you use several different Windows users, you get this prompt for every user.

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

Testing the Oracle extension with sbttest on AIX does not work

Problem

• Testing the Oracle extension with sbttest on AIX will not work unless the full path to the library with argument -libname is specified.

⇒ Lösung

When running sbttest on AIX, specify the full path to the library with argument -libname, e.g.,
sbttest test1 -libname /opt/sesam/bin/sesam/libobk.so or ... -libname $ORACLE_HOME/lib/libobk.so.

Errors when attempting to perform a backup on AIX

Problem

• Running RMAN command on AIX ends with errors.

⇒ Lösung

RMAN command on AIX requires that the full path to the library is set in the script via PARMS SBT_LIBRARY={full_path_to_libobk.so}. For details, see RMAN specific parameters.

Rerunning the sbttest script ends with duplicate key error

Problem

• When rerunning the sbttest script with the same backup_file_name parameter, SEP sesam returns duplicate key error.

Ursache

• This happens because the sbttest is using the same backup_file_name argument on the next run. SEP sesam interprets backup_file_name as the save_set_id and compares it with the IDs in the results table. When the same save_set_id is found, SEP sesam returns duplicate key error.

⇒ Lösung

When running sbttest, make sure that the backup_file_name argument is set to a different value for each run of the script.

Running bash script on AIX results in bad interpreter: No such file or directory error

Problem

• When running a bash script, a bad interpreter: No such file or directory error message is shown, for example:

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

Cause

• Typically, on AIX bash is not included in the list of valid shells.

⇒ Lösung

Change the first line in sbc_oracle_rman.sh to
#!/bin/sh.

ORACLE_HOME and ORACLE_SID variables are not set in the user environment

Problem

• If ORACLE_HOME and ORACLE_SID are not defined, SEP sesam script cannot connect to the target database.

⇒ Lösung

Set ORACLE_HOME and ORACLE_SID variables using any of the following:

• Add the lines
  export ORACLE_HOME=/u01/app/oracle/product/10gR2/db_1 and export ORACLE_SID=PROD_DB.
• Use oraenv to set the appropriate environment, for example:

export ORACLE_SID=TEST
export ORAENV_ASK=NO
. oraenv

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

Problem

• brbackup backint log on Windows reports "item from input file does not exist". The following error messages appear:

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

• The user starting the brbackup process does not have permission to access the security data (ACL) of the file F:\ORACLE\T11\SAPDATA1\ERPUSR_1\ERPUSR.DATA1 in Windows. Typically, only local group administrators have permission to read or write an object's SACL, which is controlled by the privilege or user right (SeSecurityPrivilege).

⇒ Lösung

• Assign the user to the local administrator group of the SAP server.
• Ensure that the user right (SeSecurityPrivilege) is implicitly or explicitly given to the user.

It may also be necessary to set the User Account Control Settings to Never notify through the Control Panel.

The RMAN file name is too long

Problem

• You receive the warning:

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

Mögliche Ursachen

• The file name of the backup set created by the RMAN is longer than 32 characters. For example, if the Oracle backup file format is set to format 'full_%d_%I_%s_%p.bck', when the parameter %s (backup set number) is integrated into the filename, the backup set number increases with every backup. As a consequence, the count of characters of that string will increase. Increasing the number to over 32 characters will cause the backup to fail.

⇒ Lösung

• Make sure that the character length of the backup set does not exceed 32 characters.

Informix

Allgemeine Troubleshooting Probleme

• 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 Logfiles auf ONBAR und SIB gefunden werden.
• SEP empfiehlt nur eine einzelne log file für ONBAR und XBSA Meldungen zu verwenden. Dadurch können Sie sämtliche Aufrufe der Datenbank und des 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 Logfiles recht groß werden können.
• Um das ONBAR Log zu aktivieren fügen Sie die folgende Zeile in the onconfig Datei ein:

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

Spezifische Troubleshooting Probleme

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

HCL Domino Server backup reports recovery failure

Problem

• Backup reports "Recovery may fail" during backup of the SEP sesam extension for HCL Domino Server. During the backup, the following warning appears for several or all Notes databases:

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

Possible causes

• There may be two reasons for this:

1. Transactional logging was not turned on or is not in Archived mode.
2. Transactional logging is running in Archived mode but is explicitly turned off for this database in the options of the database.

⇒ Lösung

This message is a warning of the Notes Backup API and is only forwarded by SEP sesam. Turn on Transactional logging in general or just for this database.

Other than that, the message can be ignored. The warning is given during the backup for safety reasons because only the admin can determine if administrative intervention is necessary.

Insufficient temporary space

Problem

• Temporary space may not suffice because every database must first be copied to the client.

⇒ Lösung

Change the path gv_rw_tmp in <SESAM_VAR>/ini/sm.ini to a directory with sufficient space.

Transactional logging not active

Problem

• The INCR backups fail.

⇒

Solution

• Activate Transactional logging in Archived mode for Notes.

Transaction logs already in progress

Problem

• This message appears in the SEP sesam:

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

Mögliche Ursachen

• The HCL Domino API sends this message to show that the transactional logs are already in the state Backup. The state cannot be set twice. If a backup could not be completed successfully, this state mat appear.

⇒

Solution

• To finish the backup status, all logasio processes should be removed from the Notes system:

 UNIX:     killall -9 logasio
 WINDOWS:  sm_kill logasio

Alternatively, you can reboot the Notes server.

Backup reports incorrect transactional logging

Problem

• After the restore of Transactional logging, Notes reports incorrect Transactional logging.

⇒

Solution

• Delete the nlogctrl.* files in the log directory then restart the Notes server.

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

====

Virtual machines residing on NFS storage are unresponsive during a backup====

Problem

• When using NFSv3 to mount NFS data stores and performing VMware backup in HotAdd transport mode, the VM that is backed up is not reachable for approx. 30 seconds when the HotAdd data mover detaches the VMDK.

Cause

• This issue occurs when the target VM and the data mover are running on two different hosts (ESXi), and the NFSv3 protocol is used to mount NFS data stores.

⇒ Lösung

• To avoid this problem, the VMware data mover and VM have to run on the same ESXi.

Use the NFSv4 protocol to mount NFS data stores.

VMware vSphere backup on Linux fails due to VDDK error

Problem

• A VMware vSphere backup (on the SEP sesam Server or RDS) on Linux fails with the following error:

Load VDDK library failed: Cannot load: libvixDiskLib.so

Cause

• The VMware Virtual Disk Development Kit (VDDK) is not installed.

====

VMware backup or browsing of VMware vCenter fails with an error due to a Java VM security restriction====

Problem

• VMware backup or browsing of VMware vCenter might fail with the following error:

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

Cause

• Due to advanced security settings, the Java virtual machine does not allow connection to VMware vCenter.

⇒ Lösung

• To avoid the Java virtual machine security restriction, proceed as follows:

1. On your SEP sesam Server, locate the following file in the Java installation directory:

 JDK_HOME/jre/lib/security/java.security

2. Change the line

    jdk.certpath.disabledAlgorithms=MD2, RSA > 1024

   to

    jdk.certpath.disabledAlgorithms=

3. Once done, restart the SEP sesam service.

====

Segmentation fault during VMware backup on Linux-based data movers ====

Problem

• VM backup on Linux-based data mover completed successfully, however a segfault event is recorded.

Cause

• This is the VMware library issue caused by the missing /sys/class/scsi_disk directory on the Linux system.

⇒ Lösung

Before executing the VMware backups on Linux-based data movers, use the modprobe command modprobe sd_mod to load the sd_mod kernel module and make the /sys/class/scsi_disk directory available.

VMware slow backup performance via NBD. OR: Backups are failing in SAN transport mode with VMs residing on VMFS 6.0

Problem

• Slow backup performance via NBD. Another problem is that backups might fail in SAN transport mode.

Cause

• vSphere 6.5 and 6.7 may have slow backup performance via NBD with VDDK 6.0.x due to the VMware policy concerning backward and forward compatibility for VDDK to support N-2 and N+1 releases.

• With vSphere 6.5 neither of VDDK 6.0.x versions provides SAN transport support when using datastores formatted with new VMFS 6.0 filesystem. Consequently, the backup will fail.

⇒ Lösung

• On Windows, VDDK is installed automatically during the SEP sesam installation. However, if you use a new vSphere version you should check the VDDK Compatibility Matrix to find its corresponding VDDK version and install it manually, if required.
• On Linux, you have to install the required VDDK version manually. Note that every new release of vSphere has a corresponding VDDK version; typically, the version number of VDDK matches the version number of vSphere.

For details on the required version, see VDDK Compatibility Matrix.

VMware backup fails with error due to unrecognized extended LUN connected to a Linux data mover

Problem

• VMware backup fails with error, such as:

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.

Cause

• On the Linux data mover in VMware environments, when you extend LUN while online (without restarting your Linux system), the extended LUN will not be instantly visible from the Linux operating system. The extended disk is automatically adjusted on Windows, while on Linux you need to rescan SCSI bus manually. Consequently, the backup will fail.

⇒ Lösung

• To rescan SCSI bus on Linux without restarting it, use the following command when adding a new disc (X is the number of SCSI host to scan):

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

• Use the following command when expanding an existing disc:

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

Single file restore

====

Mounting VMware saveset on Linux fails with error ====

Problem

• Mounting VMware saveset (on the SEP sesam Server or RDS) on Linux fails with an error, for example:

Client mount tools not installed

Cause

• The guestmount tool is not installed on the Linux host.

⇒ Lösung

To be able to access and mount the file system of an image on Linux, you have to use use the guestfs-tools. Install the guestfs-tools package as described in Installing guestfs-tools on Linux.

====

Single file restore is not working with VMware 6.0====

Problem

• When restoring single files on VMware 6.0, the restore fails with: Cannot open Thin/TBZ disks in a multiwriter mode.

This log is also shown in the vCenter events.

Cause

• This error appears if the SCSI bus sharing type on the proxy machine is set to Physical.

⇒ Lösung

Shut down the proxy machine and change the type of SCSI bus sharing to None, so the virtual disks cannot be shared by other virtual machines.

When restoring a single file, SEP sesam cannot access storage on a VM that is configured with the SCSI LSI Logic SAS adapter

Problem

• In SEP sesam version ≥ 4.4.3.48 in combination with a Linux proxy VM, when trying to select the restore source in the restore wizard (step 4: Select Files), no items are displayed in the browser.

Cause

• This issue seems to be related to the SCSI controller of the proxy VM. When trying to restore a single file from a virtual machine, SEP sesam cannot access storage on a virtual machine that is configured with the SCSI LSI Logic SAS adapter.

⇒ Lösung

• Open the properties of the proxy VM in your vCenter and change the controller on the VM from the LSI Logic SAS controller (on some VMs, this is selected by default) to an LSI Logic Parallel controller.

For more information, see VMware Docs article Change the SCSI Controller Type in the vSphere Client.

Restart the restore wizard. If there are still no items displayed in the restore browser, reboot the proxy VM and then click the Update button.

====

After updating an existing SEP sesam structure with a new VDDK version, it is no longer possible to mount a VMDK ====

Problem

• After VDDK ≥ 6.5.x has been manually installed on Windows, it is no longer possible to mount a VMDK saveset on this host.

Cause

• If another VDDK version, for example VDDK ≥ 6.5.x, is manually installed on Windows, the host requires a reboot after the update if you want to mount a VMDK on this host.

⇒ Lösung

• Reboot the host after the VDDK update, then run the following script from the command line:

vstor2install.bat in directory 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 das Backup 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öchte man die Einstellung sofort (ohne Neustart) vornehmen, so kann dies durch einen regulären mysql Client Befehl geschehen:

# 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 das Backup 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 des Backups 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 einem speziellen Konfigurationsfile abzulegen. Durch das ablegen des Passwortes in der Konfigurationsdatei erscheint es nicht im SEP sesam Logging. 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 connection error during backup

Problem

• The NDMP server fails to connect to SEP sesam (sbc_ndmp) during an NDMP backup. Errors like the following are displayed and the backup fails.

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 most cases, this is a firewall problem.
• Other incorrect network settings prevent the connection to sbc_ndmp.
• In the case of NetApp, multiple interfaces may prevent the connection to sbc_ndmp.

⇒ Lösung

• Exclude sbc_ndmp.exe from the firewall scanner and run the backup again.
• Check the configuration of your network. Note that your network must be configured correctly to allow the connection to sbc_ndmp.
• In the case of NetApp, if multiple interfaces are suspected, set the preferred interface option on your NAS device to specify the interface which should be used for NDMP:

options ndmpd
options ndmpd.preferred_interface <interface_name>

For more details, see NetApp-specific NDMP configuration.

===

NDMP restore to new restore target with non-existent subdirectory fails===

Problem

• An NDMP restore to a new restore target where the intended restore target is a different, non-existent subdirectory fails. (In previous SEP sesam versions, the NDMP alternate restore to a non-existent subdirectory fails, but it is shown as successful. Although this is now fixed, you may want to verify that the previously restored NDMP data exists.)

Note that this is only the case if the new restore target is a non-existent subdirectory. For example, if you want to restore to a /<volume_name>/<sub_dir1>/<sub_dir2> and <sub_dir1> does not exist, the restore will fail. You can still restore NDMP to the alternative target subdirectories if they already exist.

Ursache

If a subdirectory is specified as the new (non-existing) restore target, for example, /<volume_name>/<sub_dir1>/<sub_dir2>, the restore fails as non-existing subdirectories are not supported when restoring to another target. In this case, only a single level directory structure can be used as the restore target: /<volume_name>/<target_dir>; so in the above example, the supported restore target path is /<volume_name>/<sub_dir1>.

Workaround

• When performing an NDMP restore to a new restore target, make sure that you restore your data to the top-level directory (/<volume_name>/<target_dir>). Do not specify any non-existing subdirectories in the new target path, otherwise the restore will fail.

===

Selective NDMP restore does not restore empty directories and the restore fails===

Problem

• In SEP sesam versions ≤ 4.4.3 Beefalo V2, when performing a selective NDMP restore, empty directories are not restored (created) on the target if:
  • empty directories are present in the restore list along with normal directories and files (this is a known issue, but too minor to warrant a fix)
  • at least one file is selected in another directory, for example, if the backup source is /vol/vol1 and the restore selection is /vol/vol1/dir_1/file_1 and /vol/vol1/empty_dir
    

Consequently, the restore fails.

Ursache

If only directories are selected for selective restore, the empty directories are added to the SEL file by sm_restore and the restore completes without error. However, if at least one file is selected together with an empty directory, the restore fails.

Workaround

• When performing a selective restore, try not to restore empty directories together with individual files, otherwise the restore will fail.

NDMP on NetApp

====

NDMP browsing of non-UTF-8 fails and restore to non-UTF-8 volume may not be possible====

Problem

• When performing a restore, it is not possible to browse the contents of non-UTF-8 NetApp volumes. You may receive an error message similar to the following:

NDMP error:  ERR NDMP4_SNAP_DIR_LIST  ?0x20500106?

This can happen because:

• Non-UTF-8 volumes are not searchable if objects contain umlauts or special characters.

Consequently, a restore to a non-UTF-8 volume is not possible if objects with special characters are included in the NDMP backup.

The following ONTAP CLI command displays the encoding language of all volumes:

volume show -vserver * -fields language

⇒ Lösung

• NDMP backups of NetApp volumes without UTF-8 encoding language are basically possible, but the path in the backup task can only be specified manually.
• If a backup of a non-UTF-8 volume contains objects with umlauts or special characters, the restore can only be performed to a UTF-8 volume.

====

NDMP DAR restore of single files is too slow====

Problem

When using a Direct Access Recovery (DAR) which enables NDMP selective restore, restore is too slow, even though DAR should greatly reduce the time it takes to restore individual files.

Ursache

• The general prediction is that DAR greatly increases restore speed, but this depends on the amount and size of data backed up. As stated by NetApp, the restore can take quite some time depending on the number of files in the directory, the position of the directory and file on the tape, and the number of tapes to be read. Refer to the NetApp documentation for details.

⇒ Lösung

• Split the backup into smaller parts to reduce the amount of information that DAR has to manage during the restore.

Restore fails with: "Storing of nlist entries failed."

Problem

• Restore finishes with the error message: "Storing of nlist entries failed."

⇒ Workaround

• Instead of commonly used version 4 of the NDMP protocol, start the NDMP daemon in version 3 by entering the following commands:

ndmpd off
ndmpd version 3
ndmpd on

• Then retry the NDMP restore.

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.

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

Merging and deleting leftover snapshots

Problem

• The backup fails and the snapshot is left behind.

⇒ Lösung

Use the graphical virt-manager tool to delete the snapshot or virsh, as shown in the example:

1. List the available snapshots for the domain:

 user@hypervisor:~$ virsh snapshot-list <domain_name>
 Name                 Creation Time             State
 ------------------------------------------------------------
 '''Sesam_SF20173828282@XXXX'''       2017-07-06 08:15:11 +0200 disk-snapshot

In this example, one leftover snapshot for this VM exists.

2. List the virtual disks for the domain:

 user@hypervisor:~$ virsh domblklist <domain_name>
 Target     Source
 ------------------------------------------------
 '''sda'''        /path/to//Sesam_SF20173828282@XXXX.snapshot

3. For each device that refers to SEP sesam snapshot, start a block commit to merge the snapshot:

 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. Delete the snapshot metadata information:

 user@hypervisor:~$ virsh snapshot-delete <domain_name> --metadata --snapshotname '''Sesam_SF20173828282@XXXX'''
 Domain snapshot sesam_snapshot deleted

6. Delete the snapshot file:

 user@hypervisor:~$ rm /path/to//Sesam_SF20173828282@XXXX.snapshot

Si3 Deduplication

===

Unable to establish connection to S3 data store===

Problem

Si3 NG data store may be unable to establish secure connection to S3 storage with the following error:

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

Cause

In case Si3 NG data store connects to a storage provider that uses a self-signed certificate, this certificate is not recognized as trustworthy by default because it is not issued by a trusted certificate authority. This can result in connection being denied and log files in /var/opt/sesam/var/log/sms may contain a log message similar to this:

[...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

⇒

Solution

To solve this problem use the keytool utility to import the public.crt certificate to the server certificate store. This will allow the Si3 server to recognize and trust the S3 storage provider's certificate, and establish a secure connection.

1. Obtain the public certificate. Note that you can export it from the browser.
2. Locate the cacerts file on your server. This is the location of your JVM certificate keystore.
3. Import the public.crt certificate into the JVM's certificate keystore with the following command:

on Linux:

keytool -import -trustcacerts -keystore /var/lib/ca-certificates/java-cacerts -storepass changeit  -noprompt -alias <storage backend endpoint URL> -file /<path_to_certificate>/public.crt

on 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 <storage backend endpoint URL> -file <path_to_certificate>\public.crt

Issues with S3 or S3-compatible storage

Problem

• Si3 NG data store using S3 or S3-compatible storage can experience various issues, depending on cloud storage provider. These issues can affect backups, migrations, and replications. In addition, sanity state check of Si3 NG could report errors that have similar root cause.

Cause

• Some cloud storage providers (for example, Wasabi) have request rate restrictions (how many HTTP(S) requests are allowed per second). Also on local storage with S3 option enabled, when multiple RDSs access the same local S3 storage, this can generate a lot of IOPS (I/Os per second).

⇒

Solution

• You can adjust the settings on the affected Si3 NG data store:

1. In the Main selection -> Components, click Data Stores to display the data store contents frame.
2. Right-click the selected Si3 NG data store and then click Properties.
3. Double-click a drive to open Drive Properties dialog, and then in Options field enter as follows:

dedup.s3.timeoutInSeconds=1200,dedup.s3.page.workers=2,dedup.maxAsyncRequests=50

This will increase the timeout period, active page workers and request rate.

Si3 remains in "shutting down" state

Problem

• Manually stopping Garbage Collection (GC) fails and consequently Si3 remains in the "shutting down" state.

⇒ Solution

• Restart the Si3 daemon by using sm_main restart sds. For more details on stopping and starting the SEP sesam services, see How to Start and Stop SEP sesam.

===

Si3 deduplication may not work with NFSv4===

Problem

• Si3 deduplication may not work with Network File System version 4 (NFSv4).

Cause

• SEP sesam operations, such as backup, restore and migration, may fail due to Java problems with NFSv4.

⇒ Solution

• To avoid this problem, connect your backup devices via NFSv3.

Repairing corrupted Si3 NG data store

You can repair the Si3 NG store when pages or objects get corrupted.

1. First determine the scope of corruption:
   • To get the list of corrupted objects use:

     sm_dedup_interface -d <datastore> corruptedobjects

   • To get the list of corrupted pages use:

     sm_dedup_interface -d <datastore> corruptedpages

2. Use the following command to replace the page in /pages directory with an older version from /pages-trash directory:

   sm_dedup_interface -d <datastore> repair pages

   The pages in trash contain all chunks deleted on previous GC. The oldest version of a page takes priority.
3. Use the following command to search for and recover the missing chunks in /pages-trash directory:

   sm_dedup_interface -d <datastore> repair start

   During the repair process a new page is created, which contains all chunks from the current page (page affected by 'missing chunks' issue) and all chunks found in the trash.

Cleanup of unrecoverable Si3 NG store

	Achtung
	You should use the commands described in this section only in case the corrupted store cannot be recovered.

When corruptions in the Si3 NG store persist, the initial page version has already been purged from trash or there were fatal errors during backup or restore. In this case broken pages or missing chunks cannot be recovered.

Cleanup can be performed by deleting unrecoverable objects manually or by using the automatic cleanup function.

Deleting objects

When there are only a few unrecoverable objects, delete each object with the following commands:

sm_dedup_interface -d <datastore> delete corruted_object_id_1

...

sm_dedup_interface -d <datastore> delete corruted_object_id_Nth

In case of many corruptions you can delete all corrupted objects using the following command:

sm_dedup_interface -d <datastore> fsck purge

Garbage collection

When you have deleted all unrecoverable objects, run garbage collection (gc):

sm_dedup_interface -d <datastore> gc start

Automatic cleanup function

To start an automatic cleanup function, use the following command:

sm_dedup_interface ... fsck purge auto

The automatic cleanup function runs the following sequence of commands: PCCK start -> OCCK start -> Delete all corrupted objects -> GC start.

Logging

The logging function uses a relatively powerful logback library. For more information, see Logback Project. Note that this information is intended for advanced users only.

Logging info

• gv_rw_ini:sm_sds.xml (/var/opt/sesam/var/ini/sm_sds.xml)
• /var/opt/sesam/var/log/sms contains two log files:
  • sm_dedup_server_info-<drive>.log: Log level INFO and higher.
  • sm_dedup_server-<drive>.log: Log level DEBUG and higher. This file can become quite large.
  • sm_dedup_gc-<drive>.log: garbage collection log.
  • sm_dedup_fsck-<drive>.log: file system check log.
• Auto rotation if the log file size reaches 100 MB.

Files and directories

Objects

For every SEP sesam saveset, three objects (files) are stored in the Si3 NG store:

• <ssid>.data
• <ssid>.info
• <ssid>.info2

The .data and .info files are identical to those of a normal data store. The .info2 file is required for the data to be appended to a Si3 object. All database information that is not available before a backup is completed is written to this file.

Directories

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.

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.