Troubleshooting Guide/de

From SEPsesam
This page is a translated version of the page Troubleshooting Guide and the translation is 98% complete.
Other languages:

Copyright © SEP AG 1999-2022. 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.

Docs latest icon.png Willkommen in der aktuellsten Version der SEP sesam Dokumentation 4.4.3 Beefalo/5.0.0 Jaglion. Frühere Versionen der Dokumentation finden Sie hier: Dokumentation Archiv.


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.
  • SEP Tip.png 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:
    3. HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products
    4. Suchen Sie den folgenden Ordner und klicken Sie ihn an:
    5. 7737007073521AA4885C03C7AEE4954D
    6. 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:
  2. > 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
  3. Laden Sie das System neu, indem Sie den Befehl verwenden:
  4. > root@cefix:~# systemctl daemon-reload
  5. Geben Sie dann an:
  6. > 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.
Information sign.png Anmerkung
In der msi log Datei ist die Zeile 'Transforming table Error' sehr oft zu finden. Dies bedeutet nicht dass ein Fehler aufgetreten ist, sondern nur dass die Tabelle Error transformiert wurde. Es handelt sich also nur um eine Information keine Fehlermeldung.

Problem 2

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

Mögliche Ursachen

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

Lösung

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

Red Hat Enterprise Linux

Problem

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

Lösung

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

Powershell-Skript wird auf einem Zielcomputer nicht ausgeführt

Problem

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

Mögliche Ursachen

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

Lösung

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

Set-ExecutionPolicy RemoteSigned

Weitere Informationen finden Sie unter About Execution Policies.

IBM DB2

Problem

  • Es gibt Probleme mit SEP sesam Operationen.

Lösung

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

  • Führen Sie die Installation/Aktualisierung des Client- oder GUI-Pakets Schritt für Schritt aus, bis Sie zum letzten Installationsschritt Zusammenfassung gelangen.
  • Gehen Sie zum Installationsmenü und klicken Sie auf Fenster -> Installationsprotokoll.
  • 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


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

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

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.



Sicherungsprobleme

Client backup error

Problem 1

  • Backup of a Windows or Linux client fails with the following error:
  • "E020-HOSTS [..] : Error: Network communication problem: SOCKET error: 10060

Possible causes

  • The cause of this problem is most likely:
    • The active firewall on the SEP sesam backup Client. In this case, check the firewall settings and if ports 11322 or 11301 are blocked.
    • On Linux also check if the sesam SSHD daemon is running ps axw | grep sm_sshd and if port 11322 is open and in state LISTEN lsof -i TCP | grep 11322
    • An active antivirus program is blocking access or running its own firewall and blocking access.
    • Third party firewall between the backup server and the backup client blocking access.
    • The SEP sesam Client agent is not running on the system.
    • Other network related errors.

Problem 2

  • A client backup did not function properly. How can I determine where the problem is?

Solution

  • Run the following commands to determine the error:
SEP Warning.png Warning
The following commands produce a high network load.

BACKUP SERVER UNIX, CLIENT WINDOWS

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

Data from the F:/ directory on Windows is written over the network to the directory /dev/null on Unix. To display it, append -v 1 to the command above. Everything written to /dev/null will be displayed.

 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

With backup data logging:

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

If the test backup is to be run on the target backup client only, execute the following command:

In the Unix directory <sesam>/bin/sesam/:

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

In the Windows directory <SESAM_ROOT>\bin\sesam\:

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

Enter -v 1 to show the backed up data on your monitor.

Failed backups will be automatically deleted

Problem

  • By default, SEP sesam deletes all failed backups after 3 days automatically to release the storage space. How can I keep such backups for a longer time?

Solution

  • If you want to keep your failed backups for more than 3 days, you may manually extend the backup EOL (expiration date) of this particular saveset. For details, see Manually extending EOL. Note that as of v. 4.4.3 Tigon V2, SEP sesam automatically retains the last successful backup saveset when the next backup fails. This means that SEP sesam extends the EOL of the previous 'successful' or 'with warnings' backup, thus ensuring that at least one successful backup is retained.

Failed to write the data to media during backup

Problem

  • During backup, operating system error "23 (ERROR_CRC)" is displayed.

Possible causes

  • The tape drive cannot write proper blocks onto the backup media.

Solution

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

Possible causes

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

Solution

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

Solution

  • 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.
  5. 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)

Possible causes

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.

Solution

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

Information sign.png Anmerkung
Retransmission Fehler erscheinen als schwarze Linien im Wireshark Log.

ON WINDOWS

Information sign.png Note
SEP sesam uses Microsoft’s Volume Shadow Copy Service (VSS) to perform backup for various task types. VSS failures are typically caused by system configuration and not by SEP sesam; this section may provide some instructions on how to troubleshoot such issues. If you cannot find your issue here, check also VSS Troubleshooting or refer to Microsoft's article Volume Shadow Copy Service for more detailed information on VSS.

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

Possible causes

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

Solution

  • 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

  • What should I do when a client backup fails with a WIN32 API error: "1450 - Not enough system resources to execute the requested service"?
  • The backup of a client may end with the following error message in the backup log:
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().].

Possible causes

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

Solution

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.

Possible cause

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

Solution

Information sign.png Note
On a Domain Controller (DC) the DFS is used to replicate the SYSVOL, therefore it should be included in the system state backup. Use the following procedure only as a workaround if your system state backups are slow due to large amount of DFSR data.
  • 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

  • What does the warning "The system cannot find path. RegLoadKey()..." during System_State backup mean?
  • You may see the following output in NOT-log:
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().].

Possible causes

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

Solution

  • Delete the user in question or restore the profile date in the file system.
  • Check the following in your registry to see whether it still includes references to usernames which no longer exist:
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"?

Possible causes

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

Solution

  • 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]" ?

Possible causes

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

Solution

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

Possible causes

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

Solution

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

Possible causes

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

  • the size of a file has changed during the backup
  • a file is deleted during the backup (between 'find' and data processing)
  • the 'find' function encountered an error

Solution

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

Solution

  • 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 command for each affected folder
    • fusermount -u /home/$USER/.gvfs
    • test with stat /home/$USER/.gvfs


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.
  • Example:
    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
    

Cause

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

Solution

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

Solution

  • Delete the file /etc/rear-release.

ReaR image hangs during bootup

Problem

  • The system hangs during bootup like shown in the following image:
  • Rear-hang.jpg

Solution

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

Solution

  • Include the /dev/ file system in your backup.
  • If the restore cannot restore /dev/:
  1. Boot from the SEP sesam LIVE CD.
  2. Mount the ROOT partition of the restored system.
  3. Manually create the /dev/ directory.
  4. 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.

Possible cause

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

Solution

  • 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. Rhelcentos grub1.jpg
    3. Select the appropriate boot loader entry:
    4. Rhelcentos grub2.jpg
    5. Press e to modify the commands for the selected entry:
    6. Rhelcentos grub3.jpg
    7. Add selinux=0 to the commands:
    8. Rhelcentos grub4.jpg
    9. Press Enter to confirm the changes and b to boot up the machine with SELinux disabled.
    10. When having access to the system, change the option SELinux of /etc/selinux/config to the following:
    11. 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

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.

Solution

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

Solution

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

Solution

  • Install the lsb package as follows:
  • yum install redhat-lsb-core mkisofs syslinux

Error 2

Solution

  • To solve this problem, proceed as follows:
    1. Edit
    2. /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. REQUIRED_PROGS=( "$SCRIPT_FILE" remove the line: mingetty
    3. Run the backup again.

ReaR error occurred during grub2-mkimage of bootx64.efi

Information sign.png Note
In order to be able to create an UEFI/EFI bootable ISO image, the additional tool ebiso has to be installed on the client system as described in the section Installing ebiso for creating UEFI aware ISO images.

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

Solution

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

Solution

  • 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/

or

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.
  • SEP Warning.png 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

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.
  • Die HTML-Hilfe-Datei ist nicht im GUI konfiguriert.

Lösung

  • Installieren Sie einen Browser.
SEP Tip.png 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
  Adresse: 193.28.59.40
  Name: decunix.sep.de
  Adresse: 193.28.59.94
  # nslookup 193.28.59.94
  Server: seplinux2.sep.de
  Adresse: 193.28.59.40
  Name: decunix.sep.de
  Adresse: 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.

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

Information sign.png 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:

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.
Information sign.png 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:

MSSQL restoring.jpeg

  • Aufruf des sbc in der Kommandozeile mit:
sbc -r -a recover sbcmsql:"/MIRACULIX/SECOND/msdb"
Information sign.png 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:

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.

Solution

Information sign.png Note
SEP sesam is not responsible for any issue caused by Windows registry editing. Note that only experts should edit the registry, as using Windows registry editor incorrectly can cause serious problems, such as Windows to stop working. For more information on editing Windows registry, see Windows registry information for advanced users.
It is advised to back up the registry before making any change to it. It is also recommended to perform the following procedure outside of working hours as it requires restarting the Microsoft Exchange Information Store service.

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

Cause

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.

Solution

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
SEP Tip.png 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", or
  • (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:
  3. gwha=<path to gwha.conf>/gwha.conf Zum Beispiel: gwha=/etc/mygw/config/gwha.conf

Problem 2

  • Problem mit den Bibliotheken mit externen Ablagebereichen.
  • Gw2012 C1 ext ablage 01 de.jpeg

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:
  3. [<Name des Ablagebereichs>.<Postoffice>.<Domain>] home=<Pfad zum Ablagebereich> Zum Beispiel: [ablage1.po1.dom1] home=/var/grpwise/ablage1
SEP Tip.png 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.

Solution

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

Solution

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

Cause

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

Solution

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

Solution

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

Solution
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].

Possible causes

  • 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).

Solution

  • 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=""

Possible causes

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

Solution

  • 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

Problem ixbar bei der ersten Sicherung

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

Lösung

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

Problem 131 bei der ersten Logical Logs Sicherung

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

Lösung

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



HCL (IBM) Domino Server

Lotus Domino Server backup reports recovery failure

Problem

  • Backup reports "Recovery may fail" during backup of the SEP sesam extension for Lotus 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.

Solution

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

Solution

  • 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.]

Possible causes

  • The Lotus Notes 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 Lotus Notes server, the server cannot be started without rebooting.

Solution

  • 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

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

Possible causes

  • If there is a backup failure that causes the SEP sesam backup client to terminate abnormally, the failure will be noticed by the Lotus 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...

Solution

  • 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

SEP sesam version > 4.4.3.22

Backup

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.

Solution

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

Solution

  • 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:
  2. JDK_HOME/jre/lib/security/java.security Then 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.

Solution

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

Solution

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

Solution

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

Solution

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

Solution

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

Solution

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

Solution

  • 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

Hard reset (offline via CLI)

Depending on SEP sesam version, use a relevant command for hard reset via CLI:

  • For SEP sesam v. < 4.4.1.x, if a soft reset does not work or it is not available, use the following command for hard reset.
  • Example sbc_vadp -b -a "action=resetcbt,server=ws2008x64,username=Administrator,password=secret"
    "DC/linuxdbserver"
  • As of SEP sesam v. 4.4.1.x, use this command for hard reset.
  • Example sm_cmd resetcbt -S qsbox1 -d "SEP Cloud" -V "cosinus (SEP)" -m hard The virtual machine must be powered off for this action.

CBT reset via the vSphere client

  • Alternatively, a CBT-reset can be performed via the vSphere client:

Online

  • The virtual machine does not need to be shut down to reset CBT:
  1. Open the properties of the affected virtual machine from Tasks > By Clients.
  2. Uncheck Enable Change Block Tracking (CBT) and save the task.
  3. Create a snapshot via vSphere Client of the affected virtual machine (none of the ticks needs to be selected).
  4. Delete the snapshot that was created before.
  5. In SEP sesam, activate the CBT option in the VM client settings and start the VM backup.

Offline

  • This step needs to be performed if a reset of CBT in online mode does not work. The virtual machine must be turned off for this step:
  1. Shut down the VM.
  2. Open the VMware Snapshot-Manager and delete all snapshots.
  3. Right-click VM -> Edit settings -> Options tab -> General -> Configuration Parameters.
  4. Set the value "ctkEnabled" to false.
  5. Set the value "scsi0:0.ctkEnabled" to false (NOTE: set the value to false for each disk).
  6. Open the folder where the VM *.VMDK files exists and delete all *-CTK.VMDK files
  7. Start the VM.
  8. Shut down the VM (this is required for the CTK table update).
  9. Start the VM again.
  10. In SEP sesam, activate the CBT option in the VM client settings and start the VM backup.-->



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.

Solution

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

Solution

  • 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
    2. mv /etc/xensource/xapi-ssl.pem /etc/xensource/xapi-ssl.pem.$(date -u +%Y%m%d)
    3. Create a new certificate
    4. /opt/xensource/libexec/generate_ssl_cert /etc/xensource/xapi-ssl.pem <ip-address or FQDN>
    5. Restart XenAPI service
    6. systemctl restart xapi
    7. Restart NBD Service
    8. 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.

Possible cause

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

Solution

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

Solution

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

Solution

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.

Solution

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

Solution

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

Solution

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

Solution

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

Solution

  • 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

Solution

  • 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
    Information sign.png 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.

Solution

  • 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

Solution

  • 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/

Solution

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

Solution

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

Netapp name mapp.png


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 error codes

When performing a BSR Pro backup or restore, the procedure might fail due to different reasons. The following list may be of help to understand the BSR Pro error codes.

  • e0040002: There is a BSR Pro backup or restore currently running; simultaneous operation of more than one BSR Pro backup or restore process is not supported.

BSR Pro installation stops with a message: A new version was found. An update is not necessary.

Problem

  • BSR Pro installation fails with a message, such as: A new version was found. An update is not necessary. This happens when the installation procedure has found another installed version of the BSR Pro (or the original program DiskImage from O&O).

Possible cause

  • In the past, the BSR Pro or O&O DiskImage was already installed manually.

Solution

  • If you want to keep the currently installed version, you have to perform the SEP sesam installation without the BSR Pro. Otherwise the currently installed BSR Pro version has to be uninstalled and then the SEP sesam installation together with BSR Pro has to be performed again.

BSR Pro backup fails due to snapshot backup issue

Problem

  • BSR Pro backup fails with BSR Pro unknown return code (0X1).

Cause

  • On some Windows OS (e.g., Windows Server 2012) you may receive a "volsnap" error in the Windows Event log: 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.

This error indicates that the source drive is experiencing a high IO load, which caused VSS to fail and deleted the shadow copy snapshot, as a result causing a BSR Pro backup failure.

Solution

  • You have to reduce the IO load on the drive being backed up or configure VSS to use a different drive with more available space (and less load) and ensure that there is sufficient storage space to create and maintain shadow copies. You may want to allocate a separate volume on a separate disk for storing shadow copies, as recommended by Microsoft, to improve performance and eliminate the possibility to delete the shadow copies due to a high I/O load.

For details, see Volume Shadow Copy Volsnap Event 25. See also the following Microsoft article: Event ID 25 — Diff Area Integrity

No savesets nor clients exist in SEP sesam after clicking Execute BSR Pro Quick-Start option

Problem

  • The list of available save sets at the SEP sesam Server remains empty.

Possible cause

This error typically occurs when the connection to the SEP sesam Server cannot be established due to any of the following:

  1. Problem with name resolution: SEP sesam Server hostname is not known to client, name to IP and IP to name (reverse) resolution is not correct.
  2. The client's name (typically a new host is set up in case of disaster recovery with new IP) cannot be resolved at the SEP sesam Server.
  3. Wrong server name (a fully qualified domain name (FQDN) may be required).
  4. When booting from PE, it may take a little longer until the savesets appear (30-45 seconds).

Solution

  1. Check your name resolution on client and SEP sesam Server. Both names must be resolved, the client IP must be resolved to the client name, and SEP sesam Server must be reachable (check the route to it – FQDN may be required to reach it). For reference, see How to check DNS configuration. If the resolution in your network does not work as expected, there might be issues with IPv6 and IPv4.
  2. Add the client's name to the name resolver or add it to the /etc/hosts on SEP sesam Server, or use the GLBV gv_stpd_auth NONE to disable the IP name to IP address check on SEP sesam Server; in the latter case, open a shell on the SEP sesam Server and execute the command below. This command enables you to contact the SEP sesam Server even if the reverse name resolution does not work on the new client.
  3. sm_glbv w gv_stpd_auth NONE
  4. Specify the SEP sesam Server with the FQDN. Open the BSR Pro Settings -> tab Security and in the Authentication table check the settings. Under the Network path/server, a valid sesam:{server} name or interface must be specified.
  5. Examples: Network path/server Port sesam:http://sep_server.mydomain.com 11000 sesam:sep_server2 11001
    Information sign.png Note
    Only the first entry is used to fill the list of available savesets!

OODIAG cores while creating BootISO

Problem

  • If you try to create a boot ISO with the BSR Pro on a system where the volumes are dynamic volumes, then the OODIAG service cored under certain circumstances.

Possible cause

  • Problem is apparently the system volume. Possibly it is related to the dynamic volume.

Solution

  • Install a newer SEP sesam version with BSR Pro.
  • If possible, do not use dynamic volumes.

VSS snapshot for the system volume does not work

Problem

  • Typically, VSS is used by default to log changes in data so that unchanged data is included in the backup. But on some systems the VSS snapshot for the system volume does not work.


Solution

  • Start SEP sesam BSR Pro with the option -a snap=snapshot. This option creates a special snapshot that does not involve the Microsoft VSS Writer: data changes are logged using the installed filter driver to include the unchanged data in the backup./li> Usage: -a snap=vss|snapshot where <vss> is default

It is not possible to get the error-log for a failed restore in a PE

Problem

  • Disk full while accessing X: because dump is written to it.

Possible cause

  • The LOG is getting too big because it is constantly being written on.

Solution

  • Open the registry in the command shell by using regedit.
  • Add the following reg-key:
  • [HKEY_LOCAL_MACHINE\SOFTWARE\O&O\O&O DiskImage\<version>] "DumpFilePath"="E:\\DUMPS\\"
  • After the change the LOG is written to the path E:\DUMPS.

SEP sesam uninstallation of the BSR Pro component fails

Problem

  • Uninstallation of the BSR Pro component fails and leaves invalid registry entries behind.

Solution

  • After a failed uninstallation, the uninstaller information is probably corrupted and you have to get rid of any potentially harmful registry leftovers to ensure normal operation of SEP sesam. There are two possible ways to deal with failed uninstallation leftovers.
  1. The best way to uninstall these components is to use the installer; you should first reinstall BSR Pro in order to repair it, and only then uninstall it again.
  2. SEP Tip.png Tip
    After a successful and complete uninstall of the BSR Pro component, the keys listed below (see registry entries) should no longer exist. If any of the listed keys is still present, it can be deleted manually as described in the next procedure.
  3. If the procedure above cannot be successfully applied, you have to manually remove the BSR Pro installation.
  4. Information sign.png Note
    The following steps describe how to modify the registry. If you modify the registry incorrectly, serious problems might occur. If you are not sure about what you are doing, we recommend that you contact SEP support at support@sep.de for assistance.
    1. In the Start menu/Search box, type regedit and click Enter. The Windows Registry Editor window opens.
    2. Delete the registry entries:
    3. HKEY_LOCAL_MACHINE\SOFTWARE\O&O\O&O DiskImage HKEY_LOCAL_MACHINE\SOFTWARE\O&O\O&O LiveUpdate\SEP sesam BSR Pro

BSR Pro backup fails with a connection error

Problem

  • BSR Pro backup may fail with one of the following errors due to blocked network connection to SEP sesam Server:
  • script processing failed: or (Status: ERROR 425 Can't open data connection. WINSOCK: Connection timed out. (0x274c,10060) or Port negotiation failed. (10038)

Possible cause

  • Windows Firewall is preventing or blocking your connections.

Solution

  • Check the Windows Firewall rules on the SEP sesam Client with BSR Pro. If the firewall rule applied during SEP sesam installation is no longer valid, create an exception for oodiag.exe to allow connection through the firewall. For details on how to configure this firewall rule, check the Prerequisites in the SEP sesam BSR Pro – Backup Configuration.


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 or NDMP error: NDMP_DATA_CONNECT

Possible causes

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

Solution

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

Cause

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

Cause

  • 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

Solution

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

Cause

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

Solution

  • 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

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

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).
  • VM settings.png

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 Wiederherstellen 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 wiederherstellen, prüfen Sie, ob der Host den VM Typ, den Sie wiederherstellen 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:
    Information sign.png 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 wiederherstellen
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) wiederherstellen, können Sie versuchen, eine Hyper-V VM zu verschieben, indem Sie sie herunterfahren, sichern und dann auf dem neuen Host wiederherstellen.

During mount of a Hyper-V RCT backup, a Windows Explorer window is opened for every mounted VHDX

Problem

During mounting of a Hyper-V backup, Windows Explorer window opens for every mounted vhd(x). This problem occurs on Microsoft Windows workstation OS if Autoplay is enabled for removable drives and option Open folder to view files (File Explorer) is selected.

Possible solutions

For removable drives set the option Take no action as default, or disable Autoplay completely.


KVM/QEMU

Merging and deleting leftover snapshots

Problem

  • The backup fails and the snapshot is left behind.

Solution

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:
  2. 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.
  3. List the virtual disks for the domain:
  4. user@hypervisor:~$ virsh domblklist <domain_name> Target Source ------------------------------------------------ sda /path/to//Sesam_SF20173828282@XXXX.snapshot
  5. For each device that refers to SEP sesam snapshot, start a block commit to merge the snapshot:
  6. user@hypervisor:~$ virsh blockcommit <domain_name> sda --active --verbose --pivot Block Commit: [100 %] Successfully pivoted
  7. Confirm that the device is now switched to the original disk device:
  8. user@hypervisor:~$ virsh domblklist <domain_name> Target Source ------------------------------------------------ sda /my/original/base.img
  9. Delete the snapshot metadata information:
  10. user@hypervisor:~$ virsh snapshot-delete <domain_name> --metadata --snapshotname Sesam_SF20173828282@XXXX Domain snapshot sesam_snapshot deleted
  11. Delete the snapshot file:
  12. user@hypervisor:~$ rm /path/to//Sesam_SF20173828282@XXXX.snapshot


Si3 Deduplication

Repairing Si3 deduplication store

Problem

  • There are problems with my Si3 deduplication store.

Solution

Repair the Si3 deduplication store as follows:

  1. Update the SEP sesam Server (where the Si3 runs) to the latest version, see Updating SEP sesam.
  2. Check the recovery log (in the Si3 root directory). If only one, two or three savesets are shown, check whether they have been deleted (purged) due to the expired EOL. If this is the case, delete the entire contents of recovery.log (but do not delete the file!). In a few seconds, the Si3 status should be changed to OK ; in the GUI and in the Web UI, the Si3 store will change from red to black. In this case the problem is solved. However, see also next step.
  3. If there are many entries in recovery.log, you have to use the repair command.
  4. Check if gc or fsck is running (sm_dedup_interface -d <Si3_drive> status). If they are, stop them with the command
  5. sm_dedup_interface -d <Si3_drive> gc stop and fsck stop
  6. Check again if 'gc or fsck are stopped (note that fsck can restart quickly).
  7. Start the quick repair; this only works if there are ddl files in <si3-root-dir>/trash/data.
  8. sm_dedup_interface -d <Si3_drive> repair start asc quick <si3-root-dir>/trash/data
  9. Use
  10. sm_dedup_interface -d <Si3_drive> repair start asc quick <si3-root-dir>/trash/data
    1. If the sanity state is not OK, use
    2. sm_dedup_interface -d <Si3_drive> repair start asc quick <si3-root-dir>/data/lostnfound
    3. If the sanity state is still not OK, use
    4. sm_dedup_interface -d <Si3drive> repair start asc quick <si3-root-dir>/data
  11. Check that the repair works:
  12. sm_dedup_interface -d <Si3_drive> status The following line confirms that it works: … GC: 0 FSCK: 0, Repair: 1
  13. Wait a few minutes. Check the repair with dedup-status. Once the repair is complete, the Si3 state should change to OK. If not, use FULL instead of QUICK repair. Have in mind that this can be quite time-consuming.

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.

Using sm_dedup_interface

sm_dedup_interface

This is the main utility for configuring and managing data stores. Below is a list of some commands and their usage.

Information sign.png Note
Depending on the deduplication store used, Si3 or Si3-NG, some of the commands may be slightly different. When relevant, both command versions are described.
sm_dedup_interface -d <datastore> <command>
  - purge
  - objectinfo <remote filename>
  - put <input filename> <dest filename>
  - get <remote filename> <dest filename> [<bytes skipped then> [<bytes read at beginning>]]
  - delete <remote filename> [<filename 2>]*
  - getlabel
  - getuuid
  - list
  - fsck [start|stop|autopurge|status|incremental|purge now|dump status into <file>|fsck incr start from <file>]
  - gc <start|stop|status|result>
  - key <set <key> <value>|get <key>|list>
  - log@server <msg>
  - propose serverconfig <repository netto GiB>
  - propose jvmconfig <repository netto Gib> (for Si3 store; slightly different usage for Si3 NG, see Notea)
  - snapshot
  - replicate from [-f] <remote hostname> <remote port> <remote filename>
  - replicate show
  - replicate abort <task id>
Notea

Depending on the deduplication store used, Si3 or Si3-NG, the command to find out how much RAM is needed at what capacity of Si3/Si3-NG differs slightly. Example:

Si3-NG
Use the command sm_dedup_interface -T dedup2 propose jvmconfig <Si3_capacity>.
Si3
Use the command sm_dedup_interface propose jvmconfig <Si3_capacity>.

The output of MaxDirectMemorySize is the required RAM value.
Note, however, that SEP sesam calculates the RAM consumption and uses these commands in the background. It is usually not needed to set the values manually. These manual changes are overwritten with the next drive configuration.
The index calculation is also associated with the command. If the index grows and is 95% full, backups can no longer be performed. The RAM must hold the entire index (described by max_pages) in memory. The MaxDirectMemorySize depends directly on max_pages. To solve the problems with the growing index, refer to Si3 Deduplication Troubleshooting.

Specific options

Most of the parameters are for internal use only.

status

Provides information about used space, stored data, label uuid and running processes (gc or fsck), etc.

The value Overall dedup ratio shows by how many percent the stored data has been reduced.

gc start
  • Starts the garbage collection.
  • Identifies unreferenced chunks and moves them to the trash.
  • Is started by SEP sesam with sm_start.
gc stop
  • Stops the garbage collection.
  • Can be restarted later.
gc status
Si3 NG gc status output example
sm_dedup_interface -d 3 gc status
Current gc status:
 State:                       Finished
 Started:                     2022-03-07 08:10:56
 Ended:                       2022-03-07 10:00:15
 Message:                     Sweep Phase: swept 97124/97124 pages [deleted=2194,rewritten=13611,skipped=79550,locked=1769,missing=0]
STATUS=SUCCESS MSG=Sweep Phase: swept 97124/97124 pages [deleted=2194,rewritten=13611,skipped=79550,locked=1769,missing=0]
get
  • Reads an object (file, saveset) from the deduplication store.
  • '-' can be used to specify STDIN.
put
  • Writes an object (file, saveset) to the deduplication store.
  • '-' can be used to specify STDOUT.
fsck
  • Starts a data store check.
  • Must be started manually.
  • If the parameter autopurge is set, all corrupted objects are deleted.
fsck status
Displays the current state or the state of the most recent data store check.

The Si3 NG deduplication store has two types of fsck: object check (occk), which checks if the Si3 data part is still readable, and page check (pcck), which checks the physical data on the disk. All processes (gc, occk and pcck) can run simultaneously.

purge
  • Deletes all pages marked as obsolete (empty trash) by the last run of garbage collection (gc).
  • Is started by sm_start after a SEP sesam day change.
  • getlabel and getuuid can be replaced with status



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.
  3. HPE Insight-disable tape agent.jpg
  4. 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?.
  2. 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\:
  2. [PATHES] gv_rw_lis=D:\SEPsesam\var\lis\
  3. Ö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
  4. 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.
  5. 1:140479734912:1088:MP_File_Full00001:38956 1:143030262144:1089:MP_File_Full00001:48605 1:146212528704:0:MP_File_Full00010:1 10:146212594176:1:MP_File_Full00010:55536 Die dritte Zeile zeigt Folgendes: Auf dem Band mit der ID 1: sind 146212528704 Bytes geschrieben, aber dann wird das Segment 0 angezeigt, was keiner echten Segmentnummer entspricht, sondern durch den Fehler verursacht wurde :1 der eine fehlende Block.


Probleme mit dem Volume Shadow Copy Service (VSS)

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. Backup is failing with a 10054 error. The event viewer shows the error: Cryptographic Services failed while processing the OnIdentity() call in the System Writer Object.

Problem

  • The VSS backup on Windows 10 or 2012/R2 fails with an error. The backup log shows:
  • Info: Backup finished. Status: ERROR Data sending failed. (10054) An existing connection was forcibly closed by the remote host. More detailed information about the cause of the error can be found in the application event log: 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.

Cause

  • The MSLLDP driver's security permissions do not allow NETWORK_SERVICE to access the driver record. This can cause the backup process to hang for a long time or fail.

Solution

  1. Open an administrative command prompt (NOT PowerShell) and execute the following command as one long command without carriage returns (do not move the cursor to the beginning of the line):
  2. 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)
  3. If you get a successful result, e.g., [SC] SetServiceObjectSecurity SUCCESS, the problem is solved. Otherwise, reboot your Windows system.

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 Backup 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. Backup Fremdsoftware

Lösung

  • Überprüfen Sie ob auf dem System eine weitere Backup 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 Backup 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 Event Logs überprüfen

Lösung

  • Überprüfen Sie die Event Logs der Windows Ereignisanzeige, und suchen dort nach VolSnap Fehlern welche zum Zeitpunkt des sesam Backup Auftrags passen.
  • Oft hilft es dann, im Internet nach der Event 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 Update

Lösung

  • Installieren Sie die neuesten Windows Updates, Service Packs und Hot-Fixes von Microsoft.
  • Führen Sie nach dem Update einen Test durch.

VSS backup fails with VSS error

If a VSS error occurs when backing up your Windows client, you need to find out the cause. Open the Windows Event Viewer and check the relevant logs. These errors can be any of the following:

"VSS_ERROR_UNEXPECTED_ERRORCODE" 
"VSS_E_PROVIDER_VETO"
"VSS_E_VOLUME_NOT_SUPPORTED" 
Information sign.png Note
You may receive similar error messages and/or aborted backups if you try to perform a VSS backup on volumes larger than 64 TB, even if the volumes are excluded from the backup. Note that writable snapshots or snapshots larger than 64 TB produce the same error.

Microsoft states the limitation of "64 TB" in the article Usability limit for Volume Shadow Copy Service (VSS) in Windows.

The above errors can be caused by any of the following:

Problem 1

  • When trying to perform a VSS backup with volumes larger than 64 TB on a Windows server, you get the following error:
"DB Module: [ [NInternal::CVssAsyncDecorator::Wait] - S_OK]"

and the Windows event logs show a VSS event ID 12289

"VSS_ERROR_UNEXPECTED_ERRORCODE" 

Cause

  • Microsoft has a restriction of 64 TB as the maximum size for volumes when performing backups with VSS. It is not possible to use VSS for larger volumes, even if they are excluded from the backup.

Solution

  • Enable the Volume Shadow Copy Service for all drives: Right-click on any of the listed Hard Disk Drives and click Configure Shadow Copies. In the Shadow Copies window, click Enable and then enable shadow copies for all drives.

Problem 2

  • When trying to perform a VSS backup of a volume larger than 60 TB or when you create VSS backups of multiple volumes in Windows Server 2008/Windows Storage Server 2008, the VSS backup fails with the following message:
ERROR: [CVssServer::CreateSnapshot(): IVssBackupComponents::DoSnapshotSet: WaitForAsyncOperation] - VSS_E_PROVIDER_VETO 

Possible causes

  • As already explained (see above note), Microsoft has set a usability limit for volumes and snapshots with VSS.
  • This error can also occur if a VSS provider blocks snapshot creation for the following reasons: Software has been installed with its own VSS provider or the existing VSS component is corrupted.
  • HP Device Access Manager (FLCDLOCK service; part of the HP Protect Tools suite) prevents VSS operations from properly accessing drive partitions.

Lösung

  • Due to the limitation within volsnap.sys, do not use volumes larger than 60 TB as a backup source or destination for Windows backups.
    • Remove volumes larger than 60 TB from the VSS snapshot action.
    • Reconfigure all disks with a current size larger than 60 TB to 60 TB or less to prevent VSS from stopping when the snapshot is created.
    • Also check the size of the shadow storage on the respective drives and increase it (if necessary). Use the Vssadmin command-line tool from an elevated command prompt (where c: should be replaced with the correct drive):
vssadmin Resize ShadowStorage /For=C: /On=C: /Maxsize=5%
  • Fix the VSS problems and then re-register the VSS components. Additionally, check the size of the shadow storage on the drives in question and increase it (if necessary) with the Vssadmin command-line tool, as described in the previous solution.
  • Uninstall HP Device Access Manager and restart your system. Note that incomplete uninstallation of HP Device Access Manager may cause problems.

You can use a third-party removal tool to correctly and completely uninstall Device Access Manager for HP ProtectTools. For details, see the UninstallHelps.com article How to uninstall Device Access Manager for HP ProtectTools?.

Information sign.png Note
The link provided will take you to a third party website. SEP provides such links for informational purposes only and is not responsible for the information, availability or accuracy of these external resources.


Problem 3

  • VSS Path backup from a Windows Storage Spaces volume fails with error:
Error:   DB Module: [ [CVssServer::WaitForAsyncOperation: IVssAsync::QueryStatus] - VSS_E_PROVIDER_VETO]

Cause

  • VSS snapshots are not supported for Windows Storage Spaces.

Solution

  • To back up data from Windows Storage Spaces volumes, you have to disable the option Backup with VSS (enabled by default) in the backup task properties. For details, see Disabling/enabling VSS-based backups.


HPE StoreOnce Catalyst

Backup

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 backup failed with "553 STOR Failed. Error: Ctl_OpenObject failed, error: OSCLT_ERR_MAXIMUM_SESSIONS. (0)

Problem

  • HPE StoreOnce backup failed with 553 STOR Failed. Error: Ctl_OpenObject failed, error: OSCLT_ERR_MAXIMUM_SESSIONS. This issue can occur when an HPE StoreOnce Catalyst data session fails to open because the maximum number of sessions on the HPE StoreOnce Catalyst server is reached, thus no other session can be started until resources are available. You can check the number of free data sessions in SEP sesam by opening your HPE StoreOnce data store properties and clicking the tab HPE Catalyst Store State, then checking the value of Free data sessions.

Solution

There are two possible solutions:

  • The HPE Catalyst server supports a limited number of concurrent data sessions. Therefore, you need to ensure that the maximum number of data sessions for your HPE StoreOnce is not exceeded, or increase the maximum number of data sessions (including restores) that can be run simultaneously.
  • Open SEP sesam and from the Main selection -> Components -> Data Stores double-click your HPE StoreOnce data store to open the properties. Then, under Drives click the relevant drive to view its properties. In the Max. channels drop-down list, decrease the number of available channels for concurrently running backup/migration streams. By default, the number of available channels is set according to your SEP sesam Server license (e.g., the standard license supports 10 concurrent streams, enabling 10 backup processes to run simultaneously).


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.

Solution

VM/Container Backup

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.

Solution

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

Solution

  • 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 ProtokolldateienError Messages GuideSEP sesam Exit Codes