Troubleshooting Guide/de: Difference between revisions

From SEPsesam
(Created page with "Weitere Quellen")
(Updating to match new version of source page)
(29 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<languages />
<languages />
{{Copyright SEP AG en}}
{{Copyright SEP AG|de}}
{{Navigation_latest_de|release=[[Special:MyLanguage/SEP_sesam_Release_Versions|4.4.3]]|link=[[Special:MyLanguage/SEP_sesam_Documentation#previous|Dokumentation Archiv]]}}<br />
{{Navigation_latest_de|release=[[Special:MyLanguage/SEP_sesam_Release_Versions|4.4.3/4.4.3 ''Beefalo V2'']]|link=[[Special:MyLanguage/SEP_sesam_Documentation#previous|Dokumentation Archiv]]}}<br />
==Einleitung==
==Einleitung==
<div class="boilerplate metadata" id="Additional resources" style="background-color:#ecedf1; color:#8695a7; border: 1px ridge #cdd3db; margin: 0.5em; padding: 0.5em; float: right; width: 35%; "><center><b>Weitere Quellen</b></center>
<div class="boilerplate metadata" id="Additional resources" style="background-color:#ecedf1; color:#8695a7; border: 1px ridge #cdd3db; margin: 0.5em; padding: 0.5em; float: right; width: 35%; "><center><b>Weitere Quellen</b></center>
{|style="margin: auto; margin-bottom:1em; width:100%; border:0px solid grey;"
{|style="margin: auto; margin-bottom:1em; width:100%; border:0px solid grey;"
| rowspan="2" style="padding:0px 10px 0px;" | [[File:SEP_next.png|45px|link=Special:MyLanguage/Error_Messages_Guide]]
| rowspan="2" style="padding:0px 10px 0px;" | [[File:SEP_next.png|45px|link=Special:MyLanguage/Error_Messages_Guide]]
| style="padding:0px 40px 0px 10px; color: grey; font-size: 90%; text-align:left;" | See also: [[Special:MyLanguage/Error_Messages_Guide|Error Messages Guide]]
| style="padding:0px 40px 0px 10px; color: grey; font-size: 90%; text-align:left;" | Siehe auch: [[Special:MyLanguage/Error_Messages_Guide|Error Messages Guide]]
|}
|}


Line 13: Line 13:
[[File:SEP Tip.png|45px|link=Special:MyLanguage/FAQ|FAQ]]
[[File:SEP Tip.png|45px|link=Special:MyLanguage/FAQ|FAQ]]
| style="padding:0px 40px 0px 10px; color: grey; font-size: 90%; text-align:left;" |  
| style="padding:0px 40px 0px 10px; color: grey; font-size: 90%; text-align:left;" |  
Check [[Special:MyLanguage/FAQ|FAQ]] to find the answers to most common questions.
Unter [[Special:MyLanguage/FAQ|FAQ]] finden Sie Antworten auf die häufigsten Fragen.
|}
|}
</div>
</div>
This guide is intended to help you quickly identify and resolve problems and errors during setup, installation and normal operation of your SEP sesam system. SEP sesam often serves as an indicator that there has been a change or event that impacts overall system performance. Changes in SEP sesam backup performance are often caused by system changes or failures.
This guide is intended to help you quickly identify and resolve problems and errors during setup, installation and during normal operation of your SEP sesam system. SEP sesam often serves as an indicator that there has been a change or event that impacts overall system performance. Changes in SEP sesam backup performance are often caused by system changes or failures.
<!--SEP sesam provides two guides to help you resolve any problems you may encounter:
<!--SEP sesam provides two guides to help you resolve any problems you may encounter:
* The ''[[Error Messages Guide]]'' lists error messages alphabetically, provides explanations of the errors wherever possible and suggestions for correcting the problems. Such messages contain an error number that can be used to access this information.
* The ''[[Error Messages Guide]]'' lists error messages alphabetically, provides explanations of the errors wherever possible and suggestions for correcting the problems. Such messages contain an error number that can be used to access this information.
Line 22: Line 22:


{{First steps}}
{{First steps}}
{{anchor|interpret_error}}{{:Interpreting Error Messages}}
{{anchor|interpret_error}}{{:Interpreting Error Messages/de}}
{{anchor|log_level}}{{:Setting Log Level}}
{{anchor|log_level}}{{:Setting Log Level/de}}
For details on how to set a log level for specific backup or restore task in the GUI or globally for SEP sesam kernel modules, see [[Special:MyLanguage/Setting_Log_Level|Setting Log Level]].
{{anchor|installation}}{{:Installation and Configuration Troubleshooting/de}}
{{anchor|backup}}{{:Backup Troubleshooting}}
{{anchor|backup}}{{:Backup Troubleshooting}}
{{anchor|disaster_recovery}}{{:Disaster Recovery Troubleshooting}}
{{anchor|disaster_recovery}}{{:Disaster Recovery Troubleshooting}}
{{anchor|GUI}}{{:GUI Troubleshooting}}
{{anchor|GUI}}{{:GUI Troubleshooting/de}}
{{anchor|network}}{{:Network Troubleshooting}}
{{anchor|network}}{{:Network Troubleshooting/de}}
{{anchor|MS_SQL}}{{:MS SQL Troubleshooting}}
{{anchor|MS_SQL}}{{:MS SQL Troubleshooting/de}}
{{anchor|Exchange}}{{:MS Exchange Troubleshooting}}
{{anchor|Exchange}}{{:MS Exchange Troubleshooting}}
{{anchor|NetWare}}{{:NetWare Troubleshooting}}
{{anchor|NetWare}}{{:NetWare Troubleshooting}}
{{anchor|GroupWise}}{{:Micro Focus GroupWise Troubleshooting/de}}
{{anchor|Oracle}}{{:Oracle Troubleshooting}}
{{anchor|Oracle}}{{:Oracle Troubleshooting}}
{{anchor|Informix}}{{:Informix Troubleshooting}}
{{anchor|Informix}}{{:Informix Troubleshooting/de}}
{{anchor|Lotus_Domino}}{{:Lotus Domino Server Troubleshooting}}
{{anchor|Lotus_Domino}}{{:Lotus Domino Server Troubleshooting}}
{{anchor|Lotus_Domino}}{{:VMware Troubleshooting}}
{{anchor|VMware}}{{:VMware Troubleshooting}}
{{anchor|Citrix}}{{:Citrix XEN Server Troubleshooting}}
{{anchor|Citrix}}{{:Citrix XEN Server Troubleshooting}}
{{anchor|SAP_HANA}}{{:SAP HANA Troubleshooting}}
{{anchor|SAP_HANA}}{{anchor|SAP_Hana}}{{:SAP HANA Troubleshooting}}
{{anchor|SAP_ASE}}{{:SAP ASE Troubleshooting}}
{{anchor|SAP_ERP}}{{:SAP ERP Troubleshooting}}
{{anchor|NetApp}}{{:NetApp Troubleshooting}}
{{anchor|NetApp}}{{:NetApp Troubleshooting}}
{{anchor|MySQL}}{{:MySQL Troubleshooting}}
{{anchor|MySQL}}{{:MySQL Troubleshooting/de}}
{{anchor|BSR_Pro}}{{:BSR Pro for Windows Troubleshooting}}
{{anchor|BSR_Pro}}{{:BSR Pro for Windows Troubleshooting}}
{{anchor|NDMP}}{{:NDMP Troubleshooting}}
{{anchor|NDMP}}{{:NDMP Troubleshooting}}
{{anchor|Hyper-V}}{{:Hyper-V Troubleshooting/de}}
{{anchor|KVM}}{{:KVM QEMU Troubleshooting}}
{{anchor|Si3_dedup}}{{:Si3 Deduplication Troubleshooting}}
{{anchor|Si3_dedup}}{{:Si3 Deduplication Troubleshooting}}
{{anchor|extensions}}{{:Extensions Troubleshooting}}
{{anchor|tape}}{{:Tape and Tape Devices Troubleshooting}}
{{anchor|tape}}{{:Tape and Tape Devices Troubleshooting}}
{{anchor|VSS}}{{:VSS Troubleshooting}}
{{anchor|VSS}}{{:VSS Troubleshooting/de}}
{{anchor|HPE_StoreOnce}}{{:HPE_StoreOnce_Troubleshooting}}
{{anchor|Proxmox}}{{:Proxmox VE Troubleshooting}}


== See also ==
== Siehe auch ==
[[Special:MyLanguage/Error_Messages_Guide|Error Messages Guide]]
[[Special:MyLanguage/Error_Messages_Guide|Error Messages Guide]]

Revision as of 07:35, 16 June 2020

Other languages:

Copyright © SEP AG 1999-2024. 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/4.4.3 Beefalo V2. Frühere Versionen der Dokumentation finden Sie hier: Dokumentation Archiv.


Einleitung

This guide is intended to help you quickly identify and resolve problems and errors during setup, installation and during normal operation of your SEP sesam system. SEP sesam often serves as an indicator that there has been a change or event that impacts overall system performance. Changes in SEP sesam backup performance are often caused by system changes or failures.

Template:First steps Interpreting Error Messages/de Setting Log Level/de For details on how to set a log level for specific backup or restore task in the GUI or globally for SEP sesam kernel modules, see Setting Log Level. Installation and Configuration Troubleshooting/de

Sicherungsprobleme

Fehler bei der Client-Sicherung

Problem 1

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

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

Mögliche Ursachen

Die Ursache für dieses Problem ist sehr wahrscheinlich:

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

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

ps axw | grep sm_sshd

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

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

Problem 2

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

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

SEP Warning.png Achtung
Alle folgenden Befehle erzeugen eine hohe Netzbelastung.

BACKUP SERVER UNIX, CLIENT WINDOWS

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

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

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

BACKUP SERVER UNIX, CLIENT UNIX

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

Anzeigen der gelesenen Daten:

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

BACKUP SERVER WINDOWS, CLIENT UNIX

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

Mit Protokollierung der Sicherungsdaten:

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

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

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

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

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

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

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

Fehlgeschlagene Sicherungen werden automatisch gelöscht.

Problem

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

Lösung

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

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

Problem

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

Mögliche Ursache

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

Lösung

Überprüfen Sie das Bandlaufwerk und die Sicherungsmedien.

Sicherung auf einen Datenspeicher schlägt fehl

Problem

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

Mögliche Ursache

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

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

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

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

Falsche Anmeldung oder Passwort

Problem

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

Lösung

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

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

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

Problem

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

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

Mögliche Ursachen

Dieses Problem kann folgende Ursachen haben:

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

Lösung

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

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

Ausfall der Netzwerkverbindung auf physischen oder virtuellen Systemen

Problem

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

10054 An existing connection was forcibly closed by the remote host

oder

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

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

Mögliche Ursachen

Ursache 1: Virtualisierungslösungen

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

Die paravirtuellen Netzwerktreiber können einige Probleme verursachen:

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

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

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

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

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

Ursache 2: Netzwerk/Port Trunking

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

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

Ursache 3: Firewall

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

Ursache 4: Virenscanner

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

Ursache 5: Fehler auf SEP sesam Server Seite

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

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

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

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

Ursache 6: Task Offloading abschalten

Für VMs

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

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

Auf Windows

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

Auf Linux

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

ethtool -K eth0 tso off

TCP Retransmission

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

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

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

AUF WINDOWS

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

Pfadsicherung auf Windows funktioniert nicht

Problem

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

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

Mögliche Ursachen

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

Lösung

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

WIN32 API error: "1450"

Problem

  • Clientsicherung scheitert mit WIN32 API error: "1450 - Nicht genügend Systemressourcen, um den angeforderten Dienst auszuführen".
  • Die Sicherung eines Clients endet mit der folgenden Fehlermeldung im Sicherungsprotokoll:
sbc-1148: Error:   W2KSS Error: [WIN32 API error: 1450 - Not enough system resources to execute 
the requested service. Cannot store registry key: [SOFTWARE]. RegSaveKey() call failed in BackupRegistry().].

Mögliche Ursache

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

Lösung

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

Fehlgeschlagene Sicherung von OneDrive-Dateien

Problem

SEP sesam kann nicht auf Dateien im OneDrive Remote Storage zugreifen. Wenn Sie versuchen, Dateien in OneDrive zu sichern, zeigt die SEP sesam Protokolldatei die folgende Warnung an:

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

Ursache

OneDrive ist ein Cloud-basierter Dienst von Microsoft zum Speichern, Synchronisieren und Freigeben von Dateien. Es hat einige einzigartige Eigenschaften, die spezifisch für Microsoft Umgebungen sind und der Zugriff auf Dateien ist anders implementiert als bei Standard-Cloud-Lösungen. SEP sesam kann Schwierigkeiten beim Zugriff und der Sicherung von Dateien haben, die in OneDrive, einem Cloud-ähnlichen Remote-Speicher, gespeichert sind.

Lösung

Um dieses Problem zu lösen, sollten Sie den "Offline Mode" verwenden und die Dateien von OneDrive mit dem lokalen Speicher auf dem Client-Gerät synchronisieren. Dies ermöglicht SEP sesam, die Probleme mit dem Zugriff zu umgehen und die Dateien werden vom lokalen Speicher und nicht von der Cloud gesichert. Stellen Sie sicher, dass Sie die lokale Kopie regelmäßig aktualisieren, um die Änderungen im Cloud-Speicher wiederzugeben.

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

Problem

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

Mögliche Ursachen

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

Lösung

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

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

-x "VSS:/DFS Replication service writer"

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

System State-Sicherungfehler (RegLoadKey)

Problem

  • Warnung bei einer System State-Sicherung "Das System kann den angegebenen Pfad nicht finden. RegLoadKey()..."
  • Folgende Fehlerausgabe ist im NOT-Protokoll ersichtlich::
C:\Program Files\SEPsesam\var\tmp\usr_wf_S-1-5-21-220523388-1123561945-839522115-1003].
2020-04-13 02:04:20: sbc-2074: Warning: W2KSS Warning: [WIN32 API error: 3 -
The system cannot find path. RegLoadKey() call failed for
file: [C:\Documents and Settings\nn\ntuser.dat] in BackupUserProfiles().].

Mögliche Ursache

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

Lösung

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

Zugriff verweigert bei einer Microsoft Windows-Sicherung über VSS

Problem

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

Mögliche Ursache

SEP sesam darf keinen Snapshot mit dem aktuellen Benutzer erstellen.

Lösung

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

Länge der Streamdaten übersteigt die Pufferkapazität

Problem

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

Mögliche Ursache

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

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

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

Lösung

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

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

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

Sicherung unter Windows 7 wurde nicht erfolgreich abgeschlossen

Problem

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

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

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

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

Mögliche Ursachen

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

Lösung

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

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

AUF LINUX

SEP sesam Linux Client Fehler beim Sichern

Problem

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

Mögliche Ursachen

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

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

Lösung

  • Um diese Warnungen zu vermeiden und die oben genannten Fehler zu beheben, doppelklicken Sie auf den Sicherungsauftrag, um seine Eigenschaften zu öffnen, und geben Sie unter dem Reiter Optionen im Feld Sicherungsoptionen den folgenden Befehl ein:
-o ignore_finderr=<regex>|ALL
  • Wenn Sie alle derartigen Fehler/Warnungen vermeiden möchten, geben Sie dies an:
-o ignore_finderr=ALL

GVFS Fehler beim Sichern von Linux

Problem

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

Lösung

  • Erstellen Sie eine neue Datei namens /etc/profile.local mit dem folgenden Inhalt:
GVFS_DISABLE_FUSE=1 
export GVFS_DISABLE_FUSE
  • Führen Sie die folgenden Befehle für jeden betroffenen Ordner aus:
    • fusermount -u /home/$USER/.gvfs
    • test with stat /home/$USER/.gvfs


Disaster Recovery auf Linux

Fehler beim Ausführen einer ReaR-Sicherung

Problem

  • Das SEP sesam Client Paket wurde erfolgreich installiert und die Pfadsicherungen funktionieren. Wenn Sie dann Probleme beim Ausführen einer ReaR Sicherung haben, überprüfen Sie das Sicherungsprotokoll auf fehlende Abhängigkeiten.
  • Beispiel:
    There are binaries or libraries in the ReaR recovery system that need additional libraries
    /opt/sesam/bin/sesam/libvirtmod.so requires additional libraries (fatal error)
    	libvirt.so.0 => not found
    

Ursache

  • In diesem Fall fehlt das libvirt-client Paket.

Lösung

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

mkrescue wird im ReaR-System nicht unterstützt

Problem

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

Lösung

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

ReaR-Image bleibt beim Hochfahren hängen

Problem

  • Das System bleibt während des Bootvorgangs hängen, wie in der folgenden Abbildung gezeigt:
  • Rear-hang.jpg

Lösung

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

Das wiederhergestellte System bootet nicht

Problem 1

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

Mögliche Ursachen

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

Lösung

  • Nehmen Sie das Dateisystem /dev/ in Ihre Sicherung auf.
  • Wenn die Rücksicherung von /dev/ nicht möglich ist:
  1. Booten Sie von der SEP sesam LIVE CD.
  2. Erstellen Sie einen Mount auf die ROOT-Partition des rückgesicherten Systems.
  3. Erstellen Sie manuell das /dev/ Verzeichnis.
  4. Erstellen Sie manuell den /dev/console Eintrag mit:
mknod /path/to/target/mount//dev/console c 0 0

Problem 2

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

Mögliche Ursachen

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

Lösung

  • Insbesondere auf RHEL6- oder CentOS6-Systemen sollten Sie nach dem Neustart aus der ReaR-Wiederherstellung die folgenden Schritte ausführen:
    1. Drücken Sie eine Taste, wenn Sie vom Bootloader (GRUB) dazu aufgefordert werden:
    2. Rhelcentos grub1.jpg
    3. Wählen Sie den entsprechenden Bootloader-Eintrag:
    4. Rhelcentos grub2.jpg
    5. Drücken Sie e, um die Befehle für den ausgewählten Eintrag zu ändern:
    6. Rhelcentos grub3.jpg
    7. Fügen Sie selinux=0 zu den Befehlen hinzu:
    8. Rhelcentos grub4.jpg
    9. Drücken Sie Enter, um die Änderungen zu bestätigen und b, um den Rechner mit deaktiviertem SELinux zu starten.
    10. Wenn Sie Zugriff auf das System haben, ändern Sie die Option SELinux in /etc/selinux/config wie folgt:
    11. SELINUX=permissive

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

Es kann kein bootfähiges Betriebssystem gefunden werden

Problem

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

Mögliche Ursache

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

Lösung

  • Das Rücksicherungsprotokoll enthält eine Aussage darüber, ob die Installation des Bootloaders erfolgreich war oder nicht:
2009-12-14 14:48:27: sbc-3500: Info:     Reinstall boot manager
[/sesam/bin/sesam//sbc_grub_auto /mnt/disk/ AUTO]

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

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

Problem

  • Während der Rücksicherung wird folgender Fehler angezeigt:
/dev/sda1 does not have any corresponding BIOS drive

Mögliche Ursachen

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

Lösung

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

Ausgabe:

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

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

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

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

Problem

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

Lösung

fsck.ext3: Dateisystem hat nicht unterstützte Funktionen

Problem

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

Mögliche Ursachen

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

Lösung

  • Reboot aus dem Live-CD-Image, das das Werkzeug debugfs enthält.
  • Anzeigen der Dateisystemfunktionen mit debugfs:
root@recover#: debugfs -w /dev/sda2
debugfs 1.41.1 (01-Sep-2008)
debugfs:  features
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
quit

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

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

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

Falsche Inode-Größe (256)

Problem

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

Mögliche Ursachen

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

Lösung

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

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

Fehlendes Root-Dateisystem

Problem

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

Mögliche Ursache

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

Lösung

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

Fehlende Netzwerkkarten

Problem

  • Das rückgesicherte System findet keine Netzwerkkarten.

Mögliche Ursache

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

Lösung

  • Verwenden Sie YaST und konfigurieren Sie Ihre Netzwerkschnittstellen neu.

Client startet nicht mit dem RHEL6/Debian9-Wiederherstellungsimage

Problem

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

Ursache

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

Lösung

  • Der Client kann manuell gestartet werden mit:
/opt/sesam/bin/sesam/sm_main start


RHEL7-bezogene Probleme

RHEL7 Sicherung schlägt fehl

Fehler 1

  • Die RHEL-Sicherung schlägt mit folgendem Fehler fehl:
ERROR: The LSB package is not installed.

Lösung

  • Installieren Sie das Paket lsb wie folgt:
yum install redhat-lsb-core mkisofs syslinux


Fehler 2

  • Die RHEL Sicherung schlägt fehl mit:
ERROR: Cannot find required programs: mingetty

Weitere Einzelheiten siehe Rear dependencies on RHEL7.


Lösung

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

  1. Editieren Sie
  2.  /var/opt/sesam/var/lib/rear/usr/share/rear/conf/default.conf

    und ab Zeile:

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

    Entfernen Sie die Zeile:

     mingetty
  3. Führen Sie die Sicherung erneut aus.

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

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

Problem

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

Lösung

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

SLES-bezogene Probleme

SM_SSH funktioniert nicht auf dem SLES11 Wiederherstellungsimage

Lösung

  • In diesem Fall, führen Sie
mount -t tmpfs none /dev/shm/ -o rw,nosuid,nodev,noexec
aus, bevor Sie den Wiederherstellungsprozess starten.

Client ist nicht erreichbar nach dem Booten des Wiederherstellungsimages

Problem

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

Lösung

  • Starten Sie den Client manuell mit dem folgenden Befehl in der Rescue-Kommandozeile:
sh /etc/scripts/system-setup.d/59-start-sesam-client.sh

EFI-Boot-Image kann unter SLES11 nicht erstellt werden

Problem

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

Ursache

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

Lösung

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

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

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

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

oder

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

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

Installieren Sie ebiso wie folgt:

rpm -i ebiso-<version>.rpm

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

In diesem Fall ändern Sie

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

Zeile

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

zu

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


GUI Troubleshooting/de Network Troubleshooting/de MS SQL Troubleshooting/de

Microsoft Exchange Server

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

Problem

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

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

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

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

Lösung

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

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

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

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

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

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

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

Exchange Protokolltrunkierungsfehler

Problem

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

Ursache

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

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

Lösung

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

Überprüfen Sie ESE-Ereignisse mit ID:

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

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

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

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

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

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

   vssadmin list writers

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

Exchange Recovery Pro frägt nach einer Lizenz

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


NetWare

Überprüfen der Erreichbarkeit der TSA Dienste

Problem 1

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

Lösung

  • Auf einem native NetWare Server (das sbc_smdr Kommando muss auf einem OES Linux Server mit installiertem sesam-novell-client Paket (bis OES2015) oder auf einem OES2018 Server (sesam-novell-client ist bereits im SLES 12 Client Paket enthalten) ausgeführt werden:
 #> /opt/sesam/bin/sesam/sbc_smdr -D -N "nw1:::admin.admins.mydomain:novell:0" "/NetWare"
 2007-03-21 16:42:50: sbc-3500: Info:     ::/NetWare
 2007-03-21 16:42:50: sbc-3036: Info:     
 # @(#)SESAM BACKUP CLIENT FOR NETWARE FILE SYSTEMS, VERSION: 1.8R3 
 Build: 1.161 20070320 17:31:00 Linux i386 abas #
 2007-03-21 16:42:50: sbc-3074: Info:     Backup start time [20070321164250]
 2007-03-21 16:42:50: sbc-3500: Info:     Starting Session "SESAM SBC_NLM Session" ...
 2007-03-21 16:42:52: sbc-3500: Info:     NW1.NetWare File System 
 "NW1.NetWare File System" d_ 2000.01.01 00:00:00 2000.01.01 00:00:00 4096 - ,
 2007-03-21 16:42:52: sbc-3500: Info:     NW1.Novell Directory 
 "NW1.Novell Directory" d_ 2000.01.01 00:00:00 2000.01.01 00:00:00 4096 - ,

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

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

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

Problem 2

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

Lösung

  • In Abhängigkeit der installierten Dienste sind die folgenden TSA sichtbar:
    • NetWare File System
    • Linux File System
    • GroupWise System
    • Novell Directory
    • iFolder Store
    • Linux Cluster File System
    • NetWare Cluster File System
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"

oder

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

Mögliche Ursache

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

Lösung

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

Meldung 4

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

Mögliche Ursachen

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

Lösung

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

Dateien sind nach der Sicherung gesperrt, der Server friert ein

Problem

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

Lösung

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

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

Problem

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

Lösung

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

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

  • Sicherung der Ressource '/' unter Verwendung der angegeben Anmeldedaten.
tsatest -u root -p unsecure
  • Sicherung der Ressource /home unter Verwendung der angegeben Anmeldedaten.
tsatest --path=/home -u root -p unsecure
  • Sicherung des NetWare Volumes/Verzeichnis SYS:\SYSTEM auf dem Server ACME_SERVER unter Verwendung der angegebenen Anmeldedaten.
tsatest -s ACME_SERVER -v SYS: --path=SYSTEM -u root -p unsecure
  • Sicherung der Ressource '/' unter Verwendung der angegebenen Anmeldedaten und einer Puffergröße von 131072 Byte.
tsatest -b 131072 -u root -p unsecure
  • Backup der Ressource '/' auf dem Server ACME_SERVER unter Verwendung der angegebenen Anmeldedaten. Wird TSATEST auf einem anderen Server als ACME_SERVER ausgeführt, erfolgt ein remote Backup vom ACME_SERVER zu dem Server, auf dem das TSATEST ausgeführt wird.
tsatest -s ACME_SERVER -u root -p unsecure

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


Micro Focus GroupWise Troubleshooting/de

Oracle

Testen der Oracle-Erweiterung mit sbttest unter AIX funktioniert nicht

Problem

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

Lösung

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

Fehler bei der Ausführung einer Sicherung unter AIX

Problem

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

Lösung

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

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

Problem

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

Ursache

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

Lösung

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

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

Problem

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

Ursache

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

Lösung

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

Die Variablen ORACLE_HOME und ORACLE_SID sind in der Benutzerumgebung nicht gesetzt

Problem

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

Lösung

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

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

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

Problem

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

In backint_<SID>.log

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

In sbc_<SID>.log

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

Mögliche Ursachen

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

Lösung

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

Der RMAN-Dateiname ist zu lang

Problem

  • Sie bekommen folgende Warnung:
ORA-19506: failed to create sequential file, name="full_COMP1_1953897796_55938_1.bck", parms=""

Mögliche Ursachen

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

Lösung

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


Informix Troubleshooting/de

HCL (IBM) Domino Server

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

Fehlgeschlagene Aktualisierung vom SEP sesam Server mit dem HCL Domino Erweiterungsmodul

Problem

Die SEP sesam Aktualisierung schlägt fehl, wenn versucht wird, die HCL Domino Erweiterung auf einem SEP sesam Server zu aktualisieren, der auch als Datamover fungiert. Ein Fehler kann während des Aktualisierungsprozesses auftreten, der mit dem Export der $PATH-Variablen aus der sm.ini-Datei zusammenhängt. Während der Aktualisierung exportiert SEP sesam die Variablen aus der sm.ini-Datei, ohne die realen Werte der PATH-Variablen zu ersetzen.

Lösung

Kommentieren Sie die PATH-Variable in der sm.ini-Datei aus. Öffnen Sie die sm.ini-Datei, die sich normalerweise im Verzeichnis SESAM_BIN befindet, suchen Sie die Zeile mit der PATH-Variable und kommentieren Sie diese Zeile aus, indem Sie ein Raute-Symbol (#) am Anfang der Zeile einfügen.

Nachdem Sie die PATH-Variable auskommentiert haben, versuchen Sie erneut, SEP sesam zu aktualisieren. Wenn die Aktualisierung erfolgreich war, können Sie die Änderungen in der sm.ini-Datei bei Bedarf rückgängig machen.

HCL Domino Server Sicherung meldet Wiederherstellungsfehler

Problem

  • Sicherung meldet "Recovery may fail" während der Sicherung der SEP sesam Erweiterung für HCL Domino Server. Während der Sicherung erscheint die folgende Warnung für mehrere oder alle Notes Datenbanken:
sbc-2076: Warning: 
Item [D:\notus03data\mailboxes\mail1\cruoff.nsf] is not logged. 
Recovering may fail.

Mögliche Ursachen

  • Dafür kann es zwei Gründe geben:
  1. Die Transaktionsprotokollierung wurde nicht eingeschaltet oder befindet sich nicht im archivierten Modus.
  2. Die Transaktionsprotokollierung läuft im Archiviert-Modus, ist aber für diese Datenbank in den Optionen der Datenbank ausdrücklich ausgeschaltet.

Lösung

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

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

Unzureichender temporärer Speicherplatz

Problem

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

Lösung

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

Transaktionsprotokollierung nicht aktiv

Problem

  • Die INCR-Sicherungen schlagen fehl.

Lösung

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

Bereits in Arbeit befindliche Transaktionsprotokolle

Problem

  • Diese Meldung erscheint im SEP sesam:
DB Module: [Archiving of transaction logs already in progress.]

Mögliche Ursachen

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

Lösung

  • Um den Backup-Status zu beenden, sollten alle logasio-Prozesse aus dem Notes-System entfernt werden:
 UNIX:     killall -9 logasio
 WINDOWS:  sm_kill logasio
  • Alternativ dazu können Sie den Notes-Server neu starten.

Sicherung meldet falsche Transaktionsprotokollierung

Problem

  • Nach der Rücksicherung der Transaktionsprotokollierung meldet Notes eine falsche Transaktionsprotokollierung.

Lösung

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

Server startet nach einem Notes-Server-Absturz nicht neu

Problem

  • Nach einem Absturz des HCL-Domino-Servers kann der Server nicht ohne Reboot gestartet werden.

Lösung

  • Wenn ein Server während einer Protokollsicherung abstürzt, können logasio-Prozesse aktiv bleiben. Diese Prozesse müssen gestoppt werden. Der Server kann durch Ausführen des folgenden Befehls neu gestartet werden:
 UNIX:     killall -9 logasio
 WINDOWS:  sm_kill logasio

Sicherung mit fehlenden Optionen

Problem

  • Die Rücksicherung von Notes auf einem Linux-Client endet mit:
 "RESTORE STATUS: Restore failed. 2007-05-02 08:52:32:
  sbc-1146: Error:    DB Module: [Notes API NotesInitExtended() failure"

Mögliche Ursachen

  • Die Rücksicherungsoptionen sind nicht identisch mit den Sicherungsoptionen.

Solution

  • Legen Sie die Rücksicherungsoptionen entsprechend des Auftrags fest. Zusätzlich können die Optionen im Rücksicherungsassistenten im Schritt Optionen unter Erweiterte Rücksicherungsoptionen eingestellt werden. Zum Beispiel:
 -v 3 -a USER=nadmin -a NOTESINI=/srv/notedata/notes.ini

Abnormales Beenden des sbc.exe Prozesses

Problem

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

Mögliche Ursachen

  • Wenn ein Sicherungsfehler auftritt, der den SEP sesam Sicherungsclient dazu veranlasst, sich abnormal zu beenden, wird der Fehler von der HCL Domino Server API bemerkt und diese Fehlermeldung jede Minute in ihrer Protokollierung wiederholt.

Lösung

  • Stoppen Sie den Domino-Server zwangsweise, indem Sie nsd -kill ausführen.

Die Rücksicherung von Notes-Datenbankdateien an einem anderen Ort funktioniert nicht

Problem

  • Bei einer Rücksicherung von Datenbankdateien als Notes-Rücksicherung an einem anderen Speicherort unter Notes_Data werden alle Datenbanken übersprungen.

Möglicher Ursache

  • Notes verweigert den Zugriff auf eine bestehende Datenbank mit der gleichen Replica-ID, z.B.:
Item [\JOBSCHED.NJF] not included. Skipped...

Lösung

  • Wählen Sie im SEP sesam Rücksicherungsassistenten einen Speicherort außerhalb von Notes_Data und speichern Sie die Datenbankdatei dort. Damit ist es möglich, die Datei in die Notes-Datenverzeichnisstruktur zu kopieren.


VMware vStorage API

Sicherung

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

Problem

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

Ursache

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

Lösung

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

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

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

Load VDDK library failed: Cannot load: libvixDiskLib.so

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

Lösung Installieren Sie das VMware Virtual Disk Development Kit (VDDK).

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

Problem

  • VMware-Sicherung oder das Durchsuchen des VMware vCenter schlägt fehl mit dem folgenden Fehler:
Error:   VM Exception: [VI SDK invoke exception:javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints].

Ursache

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

Lösung

  • Um die Sicherheitsbeschränkung der virtuellen Java-Maschine zu umgehen, gehen Sie wie folgt vor:
  1. Auf Ihrem SEP sesam Server finden Sie die folgende Datei im Java-Installationsverzeichnis:
  2.  JDK_HOME/jre/lib/security/java.security
  3. Ändern Sie die Zeile
     jdk.certpath.disabledAlgorithms=MD2, RSA > 1024

    in

     jdk.certpath.disabledAlgorithms=
  4. Starten Sie anschließend den SEP sesam Dienst neu.

Segmentierungsfehler bei der VMware-Sicherung auf Linux-basiertem Datamover

Problem

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

Ursache

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

Lösung

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

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

Problem

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

Ursache

  • vSphere 6.5 und 6.7 haben möglicherweise eine langsame Sicherungs-Performance über NBD mit VDDK 6.0.x aufgrund der VMware-Richtlinie zur Abwärts- und Vorwärtskompatibilität für VDDK zur Unterstützung von N-2- und N+1-Versionen.
  • Mit vSphere 6.5 bietet keine der VDDK 6.0.x-Versionen Unterstützung für den SAN-Transport bei Verwendung von Datenspeichern, die mit dem neuen VMFS 6.0-Dateisystem formatiert sind. Folglich schlägt die Sicherung fehl.

Lösung

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

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

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

Problem

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


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

Ursache

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

Lösung

  • Um den SCSI-Bus unter Linux erneut zu scannen, ohne ihn neu zu starten, verwenden Sie den folgenden Befehl, wenn Sie eine neue Platte hinzufügen (X ist die Nummer des zu scannenden SCSI-Hosts):
echo  “- – -” > /sys/class/scsi_host/hostX/scan
  • Verwenden Sie den folgenden Befehl, wenn Sie einen vorhandenen Datenträger erweitern möchten:
echo 1 > /sys/class/scsi_device/device/rescan

Einzeldateirücksicherung

Mount des VMware-Sicherungssatzes unter Linux schlägt fehl

Problem

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

Ursache

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

Lösung

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

Einzeldateirücksicherung funktioniert nicht mit VMware 6.0

Problem

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

Dieses Protokoll wird auch in den vCenter-Ereignissen angezeigt.

Ursache

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

Lösung

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

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

Problem

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

Ursache

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

Lösung

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

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

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

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

Problem

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

Ursache

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

Lösung

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

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


Citrix Hypervisor

Fehler bei der Verwendung von ruhenden (quiesced) Snapshots

Problem

  • Die Verwendung der Methode VM.snapshot_with_quiesce schlägt in Citrix Hypervisor ≥ 8.1 oder in der Treiberversion ≥ 9.0.x.x fehl.

Ursache

  • Die Funktion von VSS mit Quiesced Snapshots von Windows VMs wurden in Citrix Hypervisor ≥ 8.1 und in den Treibern der Version ≥ 9.0.x.x entfernt. Sie werden nur noch in Citrix Hypervisor ≤ 8.0 unterstützt.

Lösung

  • Wenn Sie die Quiesced-Snapshot-Funktion mit Windows-VMs, die auf Citrix Hypervisor 8.0 und früher gehostet werden, weiterhin verwenden möchten, aktualisieren Sie nicht auf die Treiber 9.0.x.x.

CBT-Sicherung schlägt fehl, weil das Citrix Hypervisor TLS-Zertifikat eine falsche IP-Adresse enthält

Problem

  • CBT-Sicherung schlägt mit dem NBD-Client-Verbindungsfehler fehl:
Failed to get NBD client for device '******: NBD client connection error: hostname '****' doesn't match u'******

Ursache

  • Das TLS-Zertifikat eines Xen-Servers enthält die falsche IP-Adresse. Daher kann keine NBD-Sitzung aufgebaut werden.

Lösung

  • Prüfen Sie bei allen Citrix Hypervisor im Pool, ob die IP-Adresse im Zertifikat übereinstimmt.
  • Führen Sie auf dem Citrix Hypervisor, der nicht übereinstimmt, die folgenden Befehle aus:
  1. Erstellen Sie eine Sicherung des vorhandenen Zertifikats unter Verwendung von
  2. mv /etc/xensource/xapi-ssl.pem /etc/xensource/xapi-ssl.pem.$(date -u +%Y%m%d)
  3. Erstellen Sie ein neues Zertifikat
  4. /opt/xensource/libexec/generate_ssl_cert /etc/xensource/xapi-ssl.pem <ip-address or FQDN> 
  5. Führen Sie einen Neustart des XenAPI Service durch
  6. systemctl restart xapi
  7. Führen Sie einen Neustart des NBD Service durch
  8. systemctl restart xapi-nbd 

Die Meldung "Upload to URL ... failed" erscheint während der Rücksicherung, der Fehler "insufficient space" tritt während der Sicherung auf

Problem

  • Die Rücksicherung schlägt fehl mit:
"Upload to URL ... failed."
SR_BACKEND_FAILURE_44: : There is insufficient space to create snapshot on Storage Repository. 

Mögliche Ursachen

  • Es ist nicht genügend Speicherplatz auf dem Standardspeicher verfügbar.
  • Wenn der Fehler "insufficient space" während der Sicherung auftritt, kann dies mit dem Snapshot-Prozess zusammenhängen. Der XenServer konnte keinen Snapshot für die VM erstellen, weil nicht genügend Speicherplatz in Ihrem Storage Repository vorhanden war.

Lösung

  • Verwenden Sie das XenCenter, um einen anderen Standardspeicher auszuwählen, der über genügend freie Festplattenkapazität für die virtuelle(n) Festplatte(n) verfügt.

Weitere Themen

  • Einige Fehler werden von der XEN-API nicht im Detail gemeldet. Weitere Informationen finden Sie im XenServer im Verzeichnis /var/log.
  • In einigen Poolkonfigurationen müssen alle Poolmitglieder ihre Verwaltungsschnittstelle im DNS aufgeführt haben.
  • Wenn die nachstehenden Einstellungen nicht mit dem asynchronen Routing übereinstimmen und Verbindungsabbrüche und/oder Verzögerungen von 3 Sekunden oder 80 Sekunden auftreten, kann es zu offenen Sockets kommen. Dies ist vergleichbar mit zwei Netzwerkkarten, die mit ipv4 für dasselbe Subnetz konfiguriert und an denselben Switch angeschlossen sind.
  • Wenn Sie Cisco-Switches verwenden und das (von Citrix nicht unterstützte) lacp bonding 802.3ad konfiguriert haben, ist es sehr wichtig, dass sich beide Seiten auf den Ausgleichstyp einigen. Der Linux-Standard ist Layer2 und der Cisco-Standard ist Layer3+4.
  • Überprüfen Sie den Bonding-Modus auf dem Host mit cat /proc/net/bond/bond* für den Bonding-Modus:
IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0) or Transmit Hash Policy: layer3+4 (1).
  • Benutzer haben berichtet, dass dieser Befehl und ein Neustart das Problem löst, aber dies kann aufgrund seines ungetesteten und nicht unterstützten Status nicht formell empfohlen werden:
xe pif-param-set uuid=${UUID_OF_BOND_PIF} other-config:bond-xmit_hash_policy=1 
  • In der üblichen Situation, in der 802.1ad mit xmit_hash_policy=1 und STP verwendet wird, müssen auf der Cisco-Seite mehrere Einstellungen gemäß dem Artikel angepasst werden Considerations for Connecting XenServer to the Switch Ports.
  • Die meisten anderen netzbezogenen Leistungs- und Zuverlässigkeitsprobleme können mit folgenden Mitteln gelöst werden Considerations for Connecting XenServer to the Switch Ports.
  • Bei der Verwendung von Thin-Storage-Repositories ist in manchen Situationen ein sr-Rescan erforderlich, um den freien Speicherplatz vor einer Sicherung oder Rücksicherung erneut zu ermitteln.

SAP HANA

Nach der Erstkonfiguration zeigt die erste Testsicherung aus dem HANA Studio Fehler

Problem

  • Nachdem Sie SAP HANA für die Zusammenarbeit mit SEP sesam konfiguriert haben und die erste Testsicherung starten, wird diese mit Fehlern beendet.

Ursache

  • Es könnte ein Problem mit der Groß- und Kleinschreibung von Dateipfaden in den /var/opt/sesam/var/ini/backint_saphana.utl Dateien geben.

Lösung

  • Öffnen Sie die Dateien /var/opt/sesam/var/ini/backint_saphana.utl und vergewissern Sie sich, dass die Verzeichnisnamen in der richtigen Groß- bzw. Kleinschreibung aufgeführt sind.

SAP HANA-Sicherung schlägt fehl, wenn sbc_hana.sh versucht, SAP HANA DB auf einem sekundären System zu sichern

Problem

  • sbc_hana.sh erkennt den sekundären SAP HANA-Server nicht als sekundäres System und versucht, die SAP HANA-Datenbank zu sichern. Die Sicherung schlägt mit Connection refused fehl.

Ursache

  • Die sekundäre SAP HANA DB kann nicht gesichert werden, da sie permanent Daten mit der primären SAP HANA DB synchronisiert. Nur das primäre System kann auf die Datenbank zugreifen, wenn die Datenbank im SYNC-Modus läuft. Daher schlägt der Zugriff auf das sekundäre System und die Ausführung der Sicherungen auf dem Replikationsziel fehl.

Lösung

Nicht genügend Kanäle für externe SAP HANA-Sicherungen

Problem

  • Externe SAP HANA-Sicherungen können aufgrund des folgenden Fehlers nicht mehr durchgeführt werden:
2018-07-26 08:04:35 W007-SBC_COM[  6664]: Timeout reached, drive group HANA has no free streams anymore

Ursache

  • Es sind nicht genügend Kanäle verfügbar, um externe SAP HANA-Sicherungen durchzuführen.

Lösung

  • Überprüfen Sie in den Eigenschaften des Datenspeichers die verfügbaren Kanäle pro Laufwerk (standardmäßig 5) und passen Sie sie auf 20 an.

SAP HANA Sicherungen werden nicht mehr gestartet

Problem

  • Nach einiger Zeit werden SAP HANA-Sicherungen nicht mehr gestartet.

Lösung

  • Verbinden Sie sich mit dem SAP HANA-Server und stoppen Sie den Client:
  1. /opt/sesam/bin/sesam/sm_main stop
  2. ps –ef | grep sm_sbc*
  3. Suchen Sie nach alten sm_sbc*-Diensten und beenden Sie diese Dienste.
  4. Starten Sie den SEP sesam Client erneut mit dem Befehl /opt/sesam/bin/sesam/sm_main start.

Sicherung beendet mit Fehler [447]

Problem

  • Die Sicherung schlägt fehl mit:
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'

Ursache

  • hdbbackint hat nicht die Berechtigung, in das Protokollierungsverzeichnis zu schreiben.

Lösung

  • Führen Sie chmod 755 (Verzeichnis) aus, um das Problem zu beheben.

SAP HANA-Sicherungsfehler - Analysieren Sie die Protokolldateien für die Ursache

Problem

  • Die Sicherung war nicht erfolgreich und wird entweder im SAP HANA Studio oder in der SEP sesam GUI mit einem roten Punkt angezeigt.

Lösung

  • Gehen Sie zu /var/opt/sesam/var/log/lgc und suchen Sie nach der Datei hdbbackint_SID.log oder hdbbackint_SID_log.log. Diese Protokolle enthalten die Logging-Informationen für die Datenverbindungen zum SEP sesam Server und Remote Device Server (falls verwendet).

Auf dem SEP sesam Server/RDS enthält <sesam_install>/var/log/sms die Dateien stpd_pid.log und stpd_pid.com.log mit den serverseitigen Protokollinformationen. Zusätzliche Protokollinformationen auf dem SEP sesam Server können auch in <sesam_install>/var/log/lgc in sm_sbc_com*.log Dateien gefunden werden.

Jobstatus zeigt mehrere laufende Aufträge an

Problem

  • Auch wenn nur eine einzige Sicherung oder Rücksicherung läuft, werden mehrere Aufträge in der Ansicht Jobstatus der SEP sesam GUI angezeigt.

Lösung

  • Dies ist das übliche Verhalten. Bei der Durchführung einer Sicherung bündelt HANA die zu sichernden Daten in mehrere separate Sicherungssätze und sendet diese an den SEP sesam Device Server. Daher werden im Jobstatus mehrere Aufträge angezeigt. Dasselbe gilt in umgekehrter Weise auch für Rücksicherungen.

Zu häufig durchgeführte Protokollsicherungen

Problem

  • Protokollsicherungen werden alle 15 Minuten durchgeführt. Die Zeit zwischen den Protokollsicherungen sollte verlängert werden.

Lösung

  • Öffnen Sie die Sicherungskonfiguration im SAP HANA Studio. Auf der rechten Seite befindet sich ein Feld, in dem das Intervall eingestellt werden kann. Seien Sie aber vorsichtig: Der Protokollbereich wird immer größer. Wenn der Protokollbereich voll ist, wird die Datenbank keine Transaktionen mehr durchführen!

Nach der Wiederherstellung wurde der Hardwareschlüssel geändert

Problem

Lösung

  • Dies ist ein bekanntes Problem, das auch dann auftreten kann, wenn sich die Hardware und der Hostname bei gleicher Konfiguration nicht geändert haben: Neuinstallation, Rücksicherung, Wiederherstellung oder Umbenennung ändern den Hardwareschlüssel. Bitte wenden Sie sich an den SAP-Support. Details finden Sie unter 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 könnte deaktiviert sein

Problem

  • FilerView könnte deaktiviert sein.

Lösung

  • Prüfen Sie, ob FilerView aktiviert ist. Melden Sie sich über ssh an Ihrem NetApp System an und überprüfen Sie mit dem folgenden Befehl, ob Ihr FilerView http aktiviert ist:
options httpd.admin.enable

In Cluster-Umgebungen oder Ontap 8-Versionen mit Vserver:

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

Rücksicherung zeigt Berechtigungsprobleme

Problem

  • Eine Rücksicherung schlägt mit der folgenden Fehlermeldung im Protokoll fehl::
2012-08-20 12:32:27: sbc-2044: Warning: Cannot create item 
[/var/opt/sesam/var/work/mnt/netapp/VOLUME_NAME/restore/]: Permission denied

Lösung

  • Überprüfen Sie, ob das System, das als Datamover fungiert, einen Schreibzugriff auf das NetApp-Volume hat, auf dem die Daten rückgesichert werden sollen.

Falsche Angabe des Volume-Pfads

Problem

  • Normalerweise werden NFS-Freigaben auf NetApp-Systemen unter dem Verzeichnis /vol/ exportiert. Zum Beispiel kann ein Mount für die nfs-Freigabe test eingerichtet werden über: netapp:/vol/test/

Dies ist nicht bei allen NetApp Systemen der Fall. Einige Systeme exportieren das Volume direkt über: netapp:/test/

Lösung

  • Standardmäßig hängt SEP sesam das Volume über die /vol/ Angabe ein. Sie können den volume_path Parameter in den erweiterten Sicherungsoptionen anpassen, indem Sie folgendes angeben:
-a volume_path=/

Sicherung schlägt fehl mit Berechtigung verweigert - Benutzerzuordnung für NTFS-ähnliche Volumes fehlt

Problem

  • SEP sesam greift standardmäßig über NFS auf die zu sichernden Volumes zu. Wenn ein gewünschtes Volume für die Sicherung den Sicherheitsstil NTFS hat, muss eine entsprechende Benutzerzuordnung auf dem NetApp System konfiguriert werden. Andernfalls kann die Sicherung mit der Fehlermeldung Permission denied fehlschlagen.

Lösung

  • Ordnen Sie die Berechtigung für den Administrator-Benutzer auf root zu, wie in der folgenden Abbildung gezeigt.

Netapp name mapp.png



MySQL Troubleshooting/de

BSR Pro for Windows

BSR Pro - Fehlercodes

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

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

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

Problem

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

Mögliche Ursache

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

Lösung

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

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

Problem

  • BSR Pro wird nicht aktualisiert, wenn Sie eine SEP sesam Server, RDS oder Client Komponente einschließlich BSR im stillen Modus aktualisieren, z.B. über die Powershell-Befehlszeile:
sesam-cli-5.1.0.3-windows.x64.exe -Wait -Verb runAs -ArgumentList '/s',/v"/quiet /lvoicewarmup \"C:\tmp\sm_msi_update.lgc\""

Ursache

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

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

Lösung

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

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

BSR Pro-Sicherung scheitert aufgrund eines Snapshot-Sicherungsproblems

Problem

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

Ursache

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

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

Lösung

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

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

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

Problem

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

Mögliche Ursachen

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

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

Lösung

  1. Überprüfen Sie die Namensauflösung auf Client und SEP sesam Server. Beide Namen müssen aufgelöst sein, die Client-IP muss in den Client-Namen aufgelöst sein, und der SEP sesam Server muss erreichbar sein (überprüfen Sie die Route zu ihm - FQDN kann erforderlich sein, um ihn zu erreichen). Als Referenz, siehe Überprüfung der DNS-Konfiguration. Wenn die Auflösung in Ihrem Netzwerk nicht wie erwartet funktioniert, gibt es möglicherweise Probleme mit IPv6 und IPv4.
  2. Fügen Sie den Namen des Kunden zur Namensauflösung hinzu oder fügen Sie ihn zur /etc/hosts auf dem SEP sesam Server hinzu, oder verwenden Sie die GLBV gv_stpd_auth NONE, um die IP-Namen-zu-IP-Adresse-Prüfung auf dem SEP sesam Server zu deaktivieren; im letzteren Fall öffnen Sie eine Shell auf dem SEP sesam Server und führen Sie den untenstehenden Befehl aus. Dieser Befehl ermöglicht es Ihnen, den SEP sesam Server zu kontaktieren, auch wenn die Reverse Name Resolution auf dem neuen Client nicht funktioniert.
  3.  sm_glbv w gv_stpd_auth NONE
  4. Geben Sie den SEP sesam Server mit dem FQDN an. Öffnen Sie die BSR Pro Einstellungen -> Reiter Security und überprüfen Sie in der Tabelle Authentication die Einstellungen. Unter Network path/Server muss ein gültiger sesam:{server} Name oder interface angegeben werden.
  5. Beispiele:
     ''Network path/server''                      ''Port''
     sesam:http://sep_server.mydomain.com   11000
     sesam:sep_server2                        11001
    Information sign.png Anmerkung
    Nur der erste Eintrag wird verwendet, um die Liste der verfügbaren Sicherungssätze zu füllen!

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

Problem

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

Mögliche Ursache

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

Lösung

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

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

Problem

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

Lösung

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

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

Problem

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

Mögliche Ursache

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

Lösung

  • Öffnen Sie die Registrierung in der Befehlsshell mit regedit.
  • Fügen Sie den folgenden Reg-Schlüssel hinzu:
[HKEY_LOCAL_MACHINE\SOFTWARE\O&O\O&O DiskImage\<version>]
"DumpFilePath"="E:\\DUMPS\\"
  • Nach der Änderung wird das LOG in den Pfad E:\DUMPS geschrieben.

SEP sesam Deinstallation der BSR Pro Komponente schlägt fehl

Problem

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

Lösung

  • Nach einer fehlgeschlagenen Deinstallation sind die Informationen des Deinstallationsprogramms wahrscheinlich beschädigt und Sie müssen alle potenziell schädlichen Registrierungsreste beseitigen, um den normalen Betrieb von SEP sesam zu gewährleisten. Es gibt zwei Möglichkeiten, mit den Überresten einer fehlgeschlagenen Deinstallation umzugehen.
  1. Am besten deinstallieren Sie diese Komponenten mit dem Installationsprogramm; installieren Sie BSR Pro zunächst neu, um es zu reparieren, und deinstallieren Sie es erst dann wieder.
  2. SEP Tip.png Hinweis
    Nach einer erfolgreichen und vollständigen Deinstallation der Komponente BSR Pro sollten die unten aufgeführten Schlüssel (siehe Registrierungseinträge) nicht mehr vorhanden sein. Falls einer der aufgelisteten Schlüssel noch vorhanden ist, kann er wie im nächsten Verfahren beschrieben manuell gelöscht werden.
  3. Wenn das obige Verfahren nicht erfolgreich angewendet werden kann, müssen Sie die BSR Pro-Installation manuell entfernen.
  4. Information sign.png Anmerkung
    Die folgenden Schritte beschreiben, wie Sie die Registrierung ändern können. Wenn Sie die Registrierung nicht korrekt ändern, können schwerwiegende Probleme auftreten. Wenn Sie sich nicht sicher sind, was Sie tun, empfehlen wir Ihnen, den SEP-Support unter support@sep.de um Hilfe zu bitten.
    1. Geben Sie im Startmenü/Suchfeld den Text regedit ein und klicken Sie auf Enter. Das Fenster Windows-Registrierungseditor wird geöffnet.
    2. Löschen Sie den Registrierungseintrag:
    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-Sicherung schlägt mit einem Verbindungsfehler fehl

Problem

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

oder

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

oder

Port negotiation failed. (10038)

Mögliche Ursache

  • Die Windows-Firewall verhindert oder blockiert Ihre Verbindungen.

Lösung

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


NDMP

NDMP-Verbindungsfehler während der Sicherung

Problem

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

oder

NDMP error: NDMP_DATA_CONNECT 

Mögliche Ursachen

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

Lösung

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

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

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

Problem

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

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

Ursache

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

Workaround

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

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

Problem

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

Folglich schlägt die Rücksicherung fehl.

Ursache

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

Workaround

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

NDMP auf NetApp

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

Problem

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

Das kann passieren, weil:

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

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

volume show -vserver * -fields language

Lösung

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

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

Problem

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

Ursache

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

Lösung

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

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

Problem

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

Workaround

  • Starten Sie den NDMP-Daemon in Version 3 anstelle der üblichen Version 4 des NDMP-Protokolls, indem Sie die folgenden Befehle eingeben:
ndmpd off
ndmpd version 3
ndmpd on
  • Versuchen Sie dann die NDMP-Rücksicherung erneut.


Hyper-V Troubleshooting/de

KVM/QEMU

Zusammenführen und Löschen von übrig gebliebenen Snapshots

Problem

  • Die Sicherung schlägt fehl und der Snapshot bleibt zurück.

Lösung

Verwenden Sie das Tool virsh, wie im Beispiel gezeigt:

  1. Liste der verfügbaren Snapshots für die Domäne:
  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 diesem Beispiel gibt es einen übrig gebliebenen Snapshot für diese VM.

  3. Liste der virtuellen Festplatten für die Domäne:
  4.  user@hypervisor:~$ virsh domblklist <domain_name>
     Target     Source
     ------------------------------------------------
     sda        /path/to//Sesam_SF20173828282@XXXX.snapshot
  5. Starten Sie für jedes Gerät, das auf einen SEP sesam Snapshot verweist, einen Block-Commit, um den Snapshot zusammenzuführen:
  6.  user@hypervisor:~$ virsh blockcommit <domain_name> sda --active --verbose --pivot
     Block Commit: [100 %]
     Successfully pivoted
  7. Bestätigen Sie, dass das Gerät jetzt auf das ursprüngliche Laufwerk umgeschaltet wird:
  8.  user@hypervisor:~$ virsh domblklist <domain_name>
     Target     Source
     ------------------------------------------------
     sda        /my/original/base.img
  9. Löschen Sie die Metadaten des Snapshots:
  10.  user@hypervisor:~$ virsh snapshot-delete <domain_name> --metadata --snapshotname Sesam_SF20173828282@XXXX
     Domain snapshot sesam_snapshot deleted
  11. Löschen Sie die Snapshot-Datei:
  12.  user@hypervisor:~$ rm /path/to//Sesam_SF20173828282@XXXX.snapshot


Si3 Deduplication

Verbindung zum S3-Datenspeicher kann nicht hergestellt werden

Problem

Si3 NG-Datenspeicher ist möglicherweise nicht in der Lage, eine sichere Verbindung zum S3-Speicher herzustellen, und es tritt der folgende Fehler auf:

Error: Could not access data store. Server Status: 2023-03-30 10:17:10: ERROR Not started due to error: S3 is not connected Server Status: 2023-03-30 10:17:10: ERROR Not started due to error: S3 is not connected

Ursache

Wenn ein Si3 NG Datenspeicher eine Verbindung zu einem Speicheranbieter herstellt, der ein selbstsigniertes Zertifikat verwendet, wird dieses Zertifikat standardmäßig nicht als vertrauenswürdig erkannt, da es nicht von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde. Dies kann dazu führen, dass die Verbindung verweigert wird und die Protokolldateien in /var/opt/sesam/var/log/sms eine ähnliche Protokollmeldung enthalten:

[...default-dispatcher-6] [1;31mERROR[0;39m [36mS3[0;39m - Unexpected error: {}, cause: {}
software.amazon.awssdk.core.exception.SdkClientException: Unable to execute HTTP request: javax.net.ssl.SSLHandshakeException: General OpenSslEngine problem

Lösung

Um dieses Problem zu lösen, verwenden Sie das Dienstprogramm keytool, um das Zertifikat public.crt in den Zertifikatspeicher des Servers zu importieren. Dadurch kann der Si3-Server das Zertifikat des S3-Speicheranbieters erkennen und ihm vertrauen, so dass eine sichere Verbindung hergestellt werden kann.

  1. Besorgen Sie sich das öffentliche Zertifikat. Beachten Sie, dass Sie es über den Browser exportieren können.
  2. Suchen Sie die Datei cacerts auf Ihrem Server. Dies ist der Speicherort Ihres JVM-Zertifikat-Keystore.
  3. Importieren Sie das Zertifikat public.crt mit dem folgenden Befehl in den Zertifikatspeicher der JVM:
auf Linux:
keytool -import -trustcacerts -keystore /var/lib/ca-certificates/java-cacerts -storepass changeit  -noprompt -alias <URL des Speicher Backend Endpunkts> -file /<Pfad zum Zertifikat>/public.crt
auf Windows:
C:\Program Files\ojdkbuild\java-11-openjdk-11.0.15-1\bin>keytool -import -trustcacerts -keystore "C:\Program Files\ojdkbuild\java-11-openjdk-11.0.15-1\lib\security\cacerts" -storepass changeit -noprompt -alias <URL des Speicher Backend Endpunkts> -file <Pfad zum Zertifikat>\public.crt

Probleme mit S3 oder S3-kompatiblem Speicher

Problem

  • Si3 NG-Datenspeicher, die S3 oder S3-kompatiblen Speicher verwenden, können je nach Cloud-Speicheranbieter verschiedene Probleme aufweisen. Diese Probleme können Sicherungen, Migrationen und Replikationen beeinträchtigen. Darüber hinaus kann die Prüfung des Sicherheitsstatus von Si3 NG Fehler melden, die eine ähnliche Ursache haben.

Ursache

  • Einige Cloud-Speicheranbieter (z. B. Wasabi) haben Beschränkungen für die Anfragerate (wie viele HTTP(S)-Anfragen pro Sekunde zulässig sind). Auch bei lokalem Speicher mit aktivierter S3-Option kann der Zugriff mehrerer RDS auf denselben lokalen S3-Speicher viele IOPS (E/As pro Sekunde) erzeugen.

Lösung

  • Sie können die Einstellungen für den betroffenen Si3 NG-Datenspeicher anpassen:
  1. Klicken Sie in der Auswahl -> Komponenten auf Datenspeicher, um die Liste Ihrer Datenspeicher anzuzeigen.
  2. Klicken Sie mit der rechten Maustaste auf den ausgewählten Si3 NG-Datenspeicher und dann auf Eigenschaften.
  3. Doppelklicken Sie auf ein Laufwerk, um den Dialog Laufwerkseigenschaften zu öffnen, und geben Sie dann im Feld Optionen Folgendes ein:
dedup.s3.timeoutInSeconds=1200,dedup.s3.page.workers=2,dedup.maxAsyncRequests=50
Dies erhöht die Timeout-Periode, die Anzahl der aktiven Pageworker und die Anfragerate.

Si3 bleibt im Zustand "Herunterfahren"

Problem

  • Das manuelle Anhalten der Garbage Collection (GC) schlägt fehl und Si3 verbleibt daher im Zustand "Herunterfahren".

Lösung

Si3 Deduplizierung funktioniert nicht mit NFSv4

Problem

  • Si3 Deduplizierung funktioniert nicht mit Network File System Version 4 (NFSv4).

Ursache

  • SEP sesam Operationen, wie z.B. Sicherung, Rücksicherung und Migration, können aufgrund von Java Problemen mit NFSv4 fehlschlagen.

Lösung

  • Um dieses Problem zu vermeiden, verbinden Sie Ihre Sicherungsgeräte über NFSv3.

Reparieren eines beschädigten Si3 NG-Datenspeichers

Sie können den Si3 NG Speicher reparieren, wenn Seiten oder Objekte beschädigt werden.

  1. Bestimmen Sie zunächst das Ausmaß der Beschädigung:
    • Um die Liste der beschädigten Objekte zu erhalten, verwenden Sie:
      sm_dedup_interface -d <datastore> corruptedobjects
    • Um die Liste der beschädigten Seiten zu erhalten, verwenden Sie:
      sm_dedup_interface -d <datastore> corruptedpages
  2. Verwenden Sie den folgenden Befehl, um die Seiten im Verzeichnis /pages durch eine ältere Version aus dem Verzeichnis /pages-trash zu ersetzen:
    sm_dedup_interface -d <datastore> repair pages
    Die Seiten im Papierkorb enthalten alle Chunks, die mit der vorherigen GC gelöscht wurden. Die älteste Version einer Seite hat Vorrang.
  3. Verwenden Sie den folgenden Befehl, um die fehlenden Chunks im Verzeichnis /pages-trash zu suchen und wiederherzustellen:
    sm_dedup_interface -d <datastore> repair start
    Während des Reparaturvorgangs wird eine neue Seite erstellt, die alle Chunks der aktuellen Seite (Seite, die vom Problem der fehlenden Chunks betroffen ist) und alle Chunks, die im Papierkorb gefunden wurden, enthält.

Bereinigung eines nicht wiederherstellbaren Si3 NG Speichers

SEP Warning.png Achtung
Sie sollten die in diesem Abschnitt beschriebenen Befehle nur dann verwenden, wenn der beschädigte Speicher nicht wiederhergestellt werden kann.

Wenn Beschädigungen im Si3 NG Speicher fortbestehen, wurde die ursprüngliche Seitenversion bereits aus dem Papierkorb gelöscht, oder es gab fatale Fehler während der Sicherung oder Rücksicherung. In diesem Fall können beschädigte Seiten oder fehlende Chunks nicht wiederhergestellt werden.

Die Bereinigung kann durch manuelles Löschen von nicht wiederherstellbaren Objekten oder durch die automatische Bereinigungsfunktion erfolgen.

Löschen von Objekten

Wenn es nur wenige nicht wiederherstellbare Objekte gibt, löschen Sie jedes Objekt mit den folgenden Befehlen:

sm_dedup_interface -d <datastore> delete corruted_object_id_1

...

sm_dedup_interface -d <datastore> delete corruted_object_id_Nth

Bei vielen Beschädigungen können Sie alle beschädigten Objekte mit dem folgenden Befehl löschen:

sm_dedup_interface -d <datastore> fsck purge
Garbage collection

Wenn Sie alle nicht wiederherstellbaren Objekte gelöscht haben, führen Sie die Garbage Collection (gc) aus:

sm_dedup_interface -d <datastore> gc start
Automatische Bereinigungsfunktion

Um eine automatische Bereinigungsfunktion zu starten, verwenden Sie den folgenden Befehl:

sm_dedup_interface ... fsck purge auto

Die automatische Bereinigungsfunktion führt die folgende Befehlssequenz aus: PCCK Start -> OCCK Start -> Löschen aller beschädigten Objekte -> GC Start.

Protokolle

Die Protokollfunktion benutzt eine mächtige Logback Bibliothek. Weitere Informationen finden Sie unter Logback Project. Bitte beachten Sie, dass diese Informationen nur für erfahrene Nutzer gedacht sind.

Protokollinformation
  • gv_rw_ini:sm_sds.xml (/var/opt/sesam/var/ini/sm_sds.xml)
  • /var/opt/sesam/var/log/sms enthält zwei Protokolldateien:
    • sm_dedup_server_info-<drive>.log: Protokollstufe INFO und höher.
    • sm_dedup_server-<drive>.log: Protokollstufe DEBUG und höher. Diese Datei kann sehr groß werden.
    • sm_dedup_gc-<drive>.log: Garbage Collection Protokoll.
    • sm_dedup_fsck-<drive>.log: Dateisystemprüfungsprotokoll.
  • Automatische Rotation, wenn die Größe der Protokolldatei 100 MB erreicht.

Dateien und Verzeichnisse

Objekte

Für jeden SEP Sesam Sicherungssatz werden drei Objekte (Dateien) im Si3 NG Store gespeichert:

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

Die Dateien .data und .info sind identisch mit denen eines normalen Datenspeichers. Die Datei .info2 wird für die Daten benötigt, die an ein Si3-Objekt angehängt werden sollen. In diese Datei werden alle Datenbankinformationen geschrieben, die vor Abschluss einer Sicherung nicht verfügbar sind.

Verzeichnisse


Probleme mit Bändern und Bandgeräten

Problem mit Bandlaufwerken

Problem

Es gibt Probleme mit LTO-Bandlaufwerken, die wiederholt Reinigungsbänder anfordern. Zusätzlich misslingen Sicherungen mit I/O-Fehlern.

Lösung

Dafür gibt es zwei mögliche Ursachen:

  • SEP sesam hat Probleme mit der korrekten Kommunikation mit Bandgeräten, wenn die Band-Diagnose-Tools des Hardware-Herstellers noch installiert sind, nachdem der Band-Lese/Schreib-Diagnosetest erfolgreich war. Um zu verhindern, dass die Bandlaufwerke wiederholt die Säuberungsanforderung ausgeben, und um sicherzustellen, dass Sicherungen erfolgreich abgeschlossen werden, entfernen Sie die Band-Diagnosetools sofort nach Abschluss der Diagnosetests. Es gibt zum Beispiel einige Probleme mit verschiedenen Bandlaufwerken LTO5 und LTO7. In unserem Beispiel werden Sie die folgenden Komponenten deaktivieren oder entfernen:
  1. Deaktivieren Sie den HPE Versionskontroll-Agent.
  2. Deaktivieren Sie alle Band-Agenten für HPE Insight Management Agents wie unten dargestellt.

HPE Insight-disable tape agent.jpg

  1. Deinstallieren Sie HP Library and Tape Tools (L&TT) von Ihrem Server, indem Sie Programme hinzufügen/entfernen in der Systemsteuerung des Windows Rechners benutzen.
  • Ähnliche Probleme können durch häufige Hardware-bezogene Probleme verursacht werden. Einzelheiten zur Hardware-Konfiguration und Fehlerbehebung finden Sie in der Dokumentation Ihres Hardware-Herstellers.

Die Rücksicherung misslingt aufgrund eines fehlenden Blocks, der nicht auf Band geschrieben wurde, aber während der Sicherung wird kein Fehler gemeldet.

Problem

(Gilt nur für Windows SEP sesam Server oder RDS, ≤ SEP sesam Beefalo V2) In den SEP sesam Versionen von Tigon bis Beefalo V2, kann u.U. beim Sichern auf Band ein Datenblock nicht geschrieben werden, wenn die Segmentgröße zugleich mit dem Bandende - End Of Media (EOM) erreicht wird. Aus diesem Grund ist eine Rücksicherung von Daten, die diesen Block referenzieren, nicht möglich. Während im Falle eines Pfadarchivs die Daten noch bis zum Erreichen des EOM rückgesichert werden können, schlägt eine vollständige Rücksicherung oder Migration fehl.

Lösung:

  1. Finden Sie heraus, ob Ihre Bänder betroffen sind, indem Sie die unten stehende Prozedur Wie entdecke ich betroffene Sicherungssätze?
  1. Aktualisieren Sie Ihren Windows SEP sesam Server auf eine neuere Version. Wenn Ihr Bandgerät an ein Windows RDS angeschlossen ist, müssen Sie das Update auf diesem RDS installieren.

Wie entdecke ich betroffene Sicherungssätze?

Die folgenden Schritte müssen auf Ihrem SEP sesam Server ausgeführt werden.

  1. Überprüfen Sie den Pfad hinter gv_rw_lis in der Datei sm.ini, ob der Ordner für die Ablage ihrer LIS Dateien geändert wurde. Beispiel mit modifiziertem LIS Ordner - gesetzt auf D:\SEPsesam\var\lis\:
  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.
     1:140479734912:1088:MP_File_Full00001:38956
     1:143030262144:1089:MP_File_Full00001:48605
     <span style="color:red">1:146212528704:0:MP_File_Full00010:1</span>
     10:146212594176:1:MP_File_Full00010:55536
  5. Die dritte Zeile zeigt Folgendes: Auf dem Band mit der ID 1: sind 146212528704 Bytes geschrieben, aber dann wird das Segment 0 angezeigt, was keiner echten Segmentnummer entspricht, sondern durch den Fehler verursacht wurde :1 der eine fehlende Block.

Probleme mit LTO-9 Bändern

Fehler beim Laden eines neuen LTO-9-Bandes

Problem

SEP sesam kann ein neues LTO-9 Band nicht in ein Bandlaufwerk laden. Wenn unkalibrierte LTO-9 Bänder in eine Bibliothek eingelegt werden, können sie nicht ins Laufwerk geladen werden. Während des Archivabgleichs identifiziert SEP sesam die Fächer, die solche Medien enthalten und markiert sie mit einem orangefarbenen Indikator, um zu signalisieren, dass eine Bandinitialisierung erforderlich ist.

Ursache

Einige Bandbibliotheken (z.B. HPE MSL2024 bis G3, 1/8 G2 Autoloader und ähnliche) erlauben es nicht, ein nicht kalibriertes LTO-9 Bandmedium in ein Bandlaufwerk einzulegen. Dies verhindert das versehentliche Einlegen von nicht kalibrierten Bändern in das Laufwerk und trägt dazu bei, mögliche Probleme bei der Sicherung zu vermeiden, während ein neues LTO-9-Band initialisiert wird.

Weitere Informationen unter HPE Support Center: LTO-9 Media Initialization.

Lösung

Für solche Bibliotheken verwenden Sie den Initialisierungsassistenten für neue Medien, um die Initialisierung eines neuen LTO-9-Bands durchzuführen.

Beachten Sie, dass der Initialisierungsprozess für ein Band zwischen 20 Minuten und bis zu 2 Stunden dauern kann. In den meisten Fällen wird er innerhalb von 30 Minuten für ein Band abgeschlossen, in einigen Fällen kann er jedoch bis zu zwei Stunden dauern. Nach dem Start kann der Initialisierungsprozess nicht mehr abgebrochen werden.

Begrenzter oder fehlender Zugang zu neuen LTO-9-Bändern

Problem

Bei der Einführung neuer LTO-9 Bänder kann es bei SEP sesam zu Zugriffsproblemen, Zeitüberschreitungen oder Verzögerungen bei der Sicherung aufgrund der laufenden Initialisierung der LTO-9 Bänder kommen.

Ursache

Einige Bandbibliotheken (z.B. HPE StoreEver MSL6480 und ähnliche) erlauben das Einlegen eines nicht kalibrierten LTO-9 Bandmediums in ein Bandlaufwerk, starten aber den Initialisierungsprozess, bevor das Band zum ersten Mal verwendet werden kann. In diesem Fall kann SEP sesam aufgrund der laufenden LTO-9-Bandinitialisierung Probleme mit der Sicherung haben.

Lösung

LTO-9-Bänder erfordern eine einmalige Medieninitialisierung, bevor Lese-/Schreibvorgänge zum ersten Mal gestartet werden können. In den meisten Fällen ist dieser Initialisierungsprozess innerhalb von 30 Minuten für ein Band abgeschlossen, in einigen Fällen kann er jedoch bis zu zwei Stunden dauern. Beachten Sie, dass der Initialisierungsprozess nach dem Start nicht mehr abgebrochen werden kann.

Um Probleme mit verzögerten oder fehlgeschlagenen Sicherungen auf neuen LTO-9-Bändern zu vermeiden, wird empfohlen, das neue LTO-9-Band mit Hilfe des Archivabgleichs mit der Option Automatische Neuaufnahme zu initialisieren. Dadurch wird die Initialisierung des Mediums vor der ersten Verwendung gestartet.

Es ist wichtig, dass Sie bei der Durchführung des Archivabgleichs nicht die Option Abgleich nur über Barcode verwenden. Mit dieser Option werden Barcodes für Fächer erfasst, ohne dass das Band in das Laufwerk eingelegt wird. Daher wird während des Archivabgleichs keine Medieninitialisierung durchgeführt. Stattdessen wird sie bei der ersten Verwendung des Bandes gestartet.

Alternativ können Sie den Initialisierungsassistenten für neue Medien verwenden, um das neue LTO-9 Band zu initialisieren, bevor Sie es mit SEP sesam verwenden.


VSS Troubleshooting/de

HPE StoreOnce Catalyst

HPE StoreOnce-Sicherungen schlagen fehl

Wenn Ihre Sicherungen fehlschlagen, könnte einer der Gründe mit den HPE StoreOnce-Größenparametern zusammenhängen. Überprüfen Sie in diesem Fall die folgenden Punkte:

  • Wenn Sie für Ihren Catalyst-Speicher entweder eine physische oder ein logische Datengrößenquote definiert haben, prüfen Sie, ob die Grenzen erreicht wurden. Wenn ja, erhöhen Sie die Quote auf die ausreichende Größe. Einzelheiten finden Sie unter HPE StoreOnce Konfiguration.
  • Wenn Sie einen HPE Catalyst-Datenspeicher in SEP sesam erstellt und später die Größenparameter des HPE Catalyst-Speichers geändert haben, z. B. durch Ändern oder Entfernen seiner Datengrößenquoten, überprüfen Sie die Werte in der SEP sesam GUI: Auswahl -> Komponenten -> Datenspeicher, doppelklicken Sie auf Ihren StoreOnce Speicher und klicken Sie dann auf den Reiter HPE Catalyst Speicherstatus. Wenn der Status des Datenspeichers auf fehlgeschlagen gesetzt ist, müssen Sie möglicherweise die Werte für den StoreOnce-Datenspeicherkapazität und den oberen Schwellenwert anpassen, um eine korrekte Berechnung zu ermöglichen und den Datenspeicher wieder funktionsfähig zu machen. Details finden Sie unter Größe und Speicherplatzverbrauch.

HPE StoreOnce Sicherung schlägt fehl mit "553 STOR Failed. Error: Ctl_OpenObject failed, error: OSCLT_ERR_MAXIMUM_SESSIONS. (0)"

Problem

  • HPE StoreOnce-Sicherung schlägt mit 553 STOR Failed. Error: Ctl_OpenObject failed, error: OSCLT_ERR_MAXIMUM_SESSIONS. fehl. Dieses Problem kann auftreten, wenn eine HPE StoreOnce Catalyst-Datensitzung nicht geöffnet werden kann, weil die maximale Anzahl von Sitzungen auf dem HPE StoreOnce Catalyst-Server erreicht ist und daher keine weitere Sitzung gestartet werden kann, bis Ressourcen verfügbar sind. Sie können die Anzahl der freien Datensitzungen in SEP sesam überprüfen, indem Sie die Eigenschaften Ihres HPE StoreOnce-Datenspeichers öffnen und auf den Reiter HPE Catalyst Speicher Status klicken und dann den Wert Free data sessions überprüfen.

Lösung

Es gibt zwei mögliche Lösungen:

  • Der HPE Catalyst-Server unterstützt eine begrenzte Anzahl von gleichzeitigen Datensitzungen. Daher müssen Sie sicherstellen, dass die maximale Anzahl von Datensitzungen für Ihr HPE StoreOnce nicht überschritten wird, oder die maximale Anzahl von Datensitzungen (einschließlich Rücksicherungen) erhöhen, die gleichzeitig ausgeführt werden können.
  • Öffnen Sie SEP sesam und doppelklicken Sie in der Auswahl -> Komponenten -> Datenspeicher auf Ihren HPE StoreOnce Datenspeicher, um die Eigenschaften zu öffnen. Klicken Sie dann unter Laufwerke auf das entsprechende Laufwerk, um dessen Eigenschaften anzuzeigen. Verringern Sie in der Auswahlliste Max. Anzahl Kanäle die Anzahl der verfügbaren Kanäle für gleichzeitig ausgeführte Sicherungs-/Migrationsströme. Standardmäßig ist die Anzahl der verfügbaren Kanäle entsprechend Ihrer SEP sesam Server Lizenz eingestellt (z.B. unterstützt die Standardlizenz 10 gleichzeitige Ströme, so dass 10 Sicherungsprozesse gleichzeitig laufen können).


Proxmox VE

Proxmox VE Sicherung funktioniert nicht mit dem Clientnamen als einfache IP-Adresse

Problem

  • Wenn der zur SEP sesam Umgebung hinzugefügte Knoten nicht korrekt eingerichtet ist und eine IP-Adresse als Clientname verwendet wird, anstatt dass der Hostname des Clients mit dem vom Proxmox Server zurückgegebenen Hostnamen übereinstimmt, schlägt die Sicherung fehl.

Lösung

Proxmox VE Sicherung schlägt mit einem Verbindungsfehler fehl

Problem

  • Die Proxmox VE Sicherung schlägt mit Error connecting to proxmox System: "('Connection aborted.', gaierror(-2, 'Name or service not known'))"] fehl. Dieser Fehler tritt auf, nachdem eine VM auf einen anderen Clusterknoten migriert worden ist. Folglich schlägt die Proxmox VE-Sicherung fehl.

Lösung

  • Stellen Sie sicher, dass jeder Proxmox VE Clusterknoten andere Clusterknoten über DNS oder die Hosts-Datei korrekt auflösen kann.

Dateisicherung eines Proxmox Hypervisor schlägt fehl

Problem

  • Sicherung von /etc/pve/ schlägt fehl.

Lösung

  • Schließen Sie das Verzeichnis /etc/pve/ von der Sicherung aus. /etc/pve/ ist nur eine Dateisystemrepräsentation der Cluster-Datenbank, die sich unter dem Pfad /var/lib/pve-cluster/config.db befindet. Weitere Informationen finden Sie im Proxmox Wiki Artikle. Für Details siehe auch Proxmox Cluster File System (pmxcfs).


Siehe auch

Error Messages Guide