NetWorker: Die Wiederherstellung schlägt mit "NDMP Service Error: Format kann nicht identifiziert werden."

Die Symptome hängen mit zwei Hauptproblemen zusammen:

1. Der Backupadministrator achtet nicht gut auf wiederkehrende NMDP-Header-I/O-Fehler. Diese NetWorker-Warnung enthält einen VNX-Fehler und sollte ernst genommen werden
2. Die beiden Produkte (NetWorker und VNX) betrachten die Beschädigung des NMDP-Headers als trivialen Fehler. Der Sonderfall des Backups wird neu gestartet, die Beschädigung erreicht einen Punkt, der beim Versuch, die Daten zu lesen, nicht automatisch behoben werden kann.

Die für die Recovery erforderlichen Dateien erstrecken sich über mehrere Backups (vollständig + differenziell + inkrementell) und mehrere Volumes.

Die NDMP-Saveset-Recovery und die dateiweise (durchsuchbare) Recovery schlagen mit eng zugehörigen Fehlern

fehl: Durchsuchbares Recovery-Fehlerprotokoll:

42744:nsrndmp_recover: Tape server paused: reached the end of file
42897:nsrndmp_recover: Opened the tape device : c208t0l0
42870:nsrndmp_recover: Continuing recover from the next volume
42619:nsrndmp_recover: NDMP Service Error: Cannot identify format.  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
42617:nsrndmp_recover: NDMP Service Log: server_archive: emctar vol 1, 0 files, 61440 bytes read, 0 bytes written
42738:nsrndmp_recover: Data server halted: Error during the restore.
42856:nsrndmp_recover: NDMP data server has an internal error.
42871:nsrndmp_recover: Error during File NDMP Extraction.
42840:nsrndmp_recover: NDMP recover failed.
42880:nsrndmp_recover: Error during NDMP recover
16279:winworkr: NDMP retrieval: child failed with status of 1
42897:nsrndmp_recover: Opened the tape device : c208t0l5
Mover listen address is NULL(NDMP_ADDR_LOCAL)

Der Saveset-Recovery-Fehler tritt nur beim kompletten Backup auf. Backups anderer Ebenen können mithilfe der Saveset-Recovery wiederhergestellt werden.

root@NW-server# nsrndmp_recover -s NW-server -c NAS-host -S 1011119015 -v off -m "NAS-host::/root_vdm_1/users/recover_emc" "/root_vdm_1/users/VDI_Users/v009/project/Plan04.2012"
42879:nsrndmp_recover: Peforming recover with no file mark dependency..
05/31/16 17:25:50.504040 NDMP Service Debug: The process id for NDMP service is 0xc4bd90b0
42787:nsrndmp_recover: Performing recover from NDMP type of device
05/31/16 17:26:01.269862 NDMP Service Debug: The process id for NDMP service is 0xc4bd90b0
May 31 17:26:02 NW-server root: [ID 702911 local0.alert] NetWorker media: (waiting) waiting for LTO Ultrium-5 tape VN0116L5 on NAS-host
95555:nsrmmd: ndmp tape mtio failed, I/O error
42850:nsrndmp_recover: Failed to load volume 1111782299 fnum 3 <<<<<< cannot load File Number 3
42855:nsrndmp_recover: Failed to load the tape.
42871:nsrndmp_recover: Error during File NDMP Extraction.
42840:nsrndmp_recover: NDMP recover failed.
42880:nsrndmp_recover: Error during NDMP recover
root@NW-server #

Das wichtigste Symptom ist, dass der Scanner nicht in der Lage ist, die erforderlichen Backup-Volumes zu durchlaufen, er stoppt vorzeitig, bevor Daten gelesen werden!

root@NW-server # scanner -vvv -p "rd=NAS-host:c208t0l5 (NDMP)"
8909:scanner: using 'rd=NAS-host:c208t0l5 (NDMP)' as the device name
05/31/16 17:29:08.919423 NDMP Service Debug: The process id for NDMP service is 0xda018d60
9040:scanner: Opened c208t0l5 for read
8968:scanner: Reading the label...
8969:scanner: Reading the label done
8936:scanner: scanning LTO Ultrium-5 tape VN0116L5 on rd=NAS-host:c208t0l5 (NDMP)
96367:scanner: volume id 1111782299 record size 262144 bytes
created 5/24/16 21:00:35 expires 5/24/18 21:00:35
8973:scanner: setting position from fn 0, rn 0 to fn 2, rn 0
05/31/16 17:29:09.073276 NDMP Service Debug: The process id for NDMP service is 0xda018d60
9040:scanner: Opened c208t0l5 for read
05/31/16 17:29:09.201476 NDMP Service Debug: The process id for NDMP service is 0xda018d60
9040:scanner: Opened c208t0l5 for read
8761:scanner: done with LTO Ultrium-5 tape VN0116L5 <<<<<<<< No Errors , no mention of any file after File number 2 !!

Die Verwendung der NW-Debug-Flag-Datei: /nsr/debu/ndmp_auto_pos hat weder beim kompletten Backup-Saveset noch bei der durchsuchbaren Recovery geholfen.

Fehlerhaftes NDMP-Volume-Format, das durch eine Beschädigung des NDMP-Headers verursacht wird, erzeugt manchmal fehlerhafte Dateinummern (z. B. automatischer Backupneustart):  

Die Überprüfung der NW-Protokolle zeigt, dass jedes Backup beim Schreiben des NDMP-Headers mit einem I/O-Fehler gekoppelt ist. Dies ist ein konsistentes Problem, das bei jedem Backup auftritt. Dies ist ein Hinweis auf eine konsistente Beschädigung.

70896 05/01/16 12:18:05 0 0 2 1 23177 0 NW-server nsrd NSR info NAS-host:/root_vdm_1/userdata saving to pool 'NDMPPool' (VN0050L5)
42597 05/01/16 12:18:05 2 0 0 1 23990 0 NW-server nsrmmd NSR warning ndmp header: I/O error   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
71193 05/01/16 12:18:05 0 0 0 1 23177 0 NW-server nsrd NSR info NDMP Save Notice: NAS-host:/root_vdm_1/users NDMP save running on 'NW-server'

Die Überprüfung der NAS-Protokolle zeigt, dass die Puffergröße der NDMP-Geräte auf einen Wert eingestellt ist, der kleiner ist als die in NW konfigurierte Geräteblockgröße. In der NetWorker-Standardkonfiguration wird die Geräteblockgröße für LTO-5-Geräte auf 256 KB festgelegt, die NDMP-Gerätepuffergröße (NDMP.bufsz) beträgt jedoch 128 KB. Dieser Teil bezieht sich nur auf den NDMP-Header, da die Datenblockgröße auf dem NAS durch die PAX-Konfigurationsparameter konfiguriert wird (Standard 60k).

2016-05-25 17:30:37: NDMP: 3: Thread ndmp533 DartTapeInterface: tape read error: tape read block size (262144 bytes) > 131072 bytes (NDMP.bufsz (128 KB) x 1024)
2016-05-25 17:30:37: NDMP: 3: Thread ndmp533 set parameter NDMP.bufsz (in KB) to 256 or larger to resolve this error
2016-05-25 17:30:49: NDMP: 3: Thread ndmp535 DartTapeInterface: tape read error: tape read block size (262144 bytes) > 131072 bytes (NDMP.bufsz (128 KB) x 1024)
2016-05-25 17:30:49: NDMP: 3: Thread ndmp535 set parameter NDMP.bufsz (in KB) to 256 or larger to resolve this error
2016-05-25 17:30:50: NDMP: 3: Thread ndmp536 DartTapeInterface: tape read error: tape read block size (262144 bytes) > 131072 bytes (NDMP.bufsz (128 KB) x 1024)
2016-05-25 17:30:50: NDMP: 3: Thread ndmp536 set parameter NDMP.bufsz (in KB) to 256 or larger to resolve this error

Das VNX-Protokoll zeigt zum Zeitpunkt des Backups eine zugehörige Meldung an:

1466097048: NDMP: 3: Session 236 (thread ndmp236) TAPE_WRITE, size(262144) > ndmpMaxBufSize (131072) Set NDMP.bufsz >= 262144 and reboot

Dies wird nicht als Backupproblem betrachtet, da der Datenstrom nicht gestartet wurde, sondern führt zu einer Beschädigung des NMDP-Headers (siehe: NDMP: 3: Sitzung 384 (thread ndmp384) TAPE_WRITE, size(262144) > ndmpMaxBufSize (131072)Set NDMP.bufsz >= 262144 and reboot), wodurch dieses Problem gelöst wird, indem die Puffergröße der NDMP-Geräte auf 256 KB festgelegt wird. Diese Korrektur löst jedoch nicht das Problem der bereits geschriebenen Backups.

Die obige Beschädigung des NMDP-Headers kann vorliegen, ohne das Recovery-Problem zu verursachen, aber im Falle eines Backupneustarts ist die registrierte Dateinummer in der NW-Mediendatenbank falsch. Dadurch wird die automatische Positionierung des Bands aufgehoben und der NAS antwortet, dass die vorhandenen Daten an dieser Position nicht als gültiger NDMP-Datenstream erkannt werden können (NDMP-Servicefehler: Format kann nicht identifiziert werden)

Hier gibt es also zwei Arten von Beschädigungen:

1. NDMP-Header-I/O-Fehler, die durch die inkonsistente Blockgrößeneinstellung zwischen NetWorker und VNX verursacht werden. Diese Art von Beschädigung wird durch die Funktion zur automatischen Positionierung umgangen und kann jahrelang bestehen, ohne dass es jemand bemerkt. Solange die richtigen Dateinummern bei jedem Saveset registriert sind.
2. Wenn ein Backup neu gestartet wird, werden mehrere NDMP-Kopf- und -Fußzeilen sequenziell geschrieben, und dem NW-Server fehlt die richtige Dateinummer, mit der das nächste Backup beginnt, wodurch die Verwendung des NDMP-deaktivierten Debuggings für die automatische Positionierung (/nsr/debug/ndmp_auto_pos) ist in diesem Fall nutzlos, da die Bandmanagementschnittstelle (MTIO) den Lesevorgang beendet, sobald eine doppelte Dateimarkierung auftritt (verursacht durch C1 die NDMP-Header-Beschädigung)

In diesem Fall gibt es keine Möglichkeit, die Daten im automatischen Modus wiederherzustellen. Für den manuellen Modus muss das VNX-Tool ndmp verwendet werden, um das Header-Volume des Backups zu testen und die Dateinummer für den NDMP-Datenstream anzugeben. Diese Dateinummer, um mit dem Lesen der Daten zu beginnen, dieser Schritt erfordert ein Eingreifen des VNX-Supports.

Verweisen Sie auf diesen Wissensdatenbank-Artikel, wenn Sie sich an den Dell Support wenden.