NetWorker: Odzyskiwanie kończy się niepowodzeniem z komunikatem "NDMP Service Error: Nie można zidentyfikować formatu"

Objawy są związane z dwoma głównymi problemami:

1. Administrator kopii zapasowej nie zwraca należytej uwagi na stale powtarzające się błędy we/wy nagłówka NMDP. To ostrzeżenie NetWorker niesie ze sobą błąd VNX i należy je traktować poważnie
2. Dwa produkty (NetWorker i VNX) traktują uszkodzenie nagłówka NMDP jako trywialny błąd. Szczególny przypadek ponownego uruchomienia kopii zapasowej powoduje uszkodzenie osiągające punkt, który nie może być automatycznie rozwiązany podczas próby odczytu danych

Pliki wymagane do odzyskiwania obejmują wiele kopii zapasowych (pełne + różnicowe + przyrostowe) i obejmują wiele woluminów.

Odzyskiwanie zestawu zapisów NDMP i odzyskiwanie Plik po pliku (do przeglądania) kończą się niepowodzeniem z blisko powiązanymi błędami

Dziennik niepowodzeń odzyskiwania z możliwością przeglądania:

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)

Niepowodzenie odzyskiwania zestawu zapisu występuje tylko w przypadku pełnej kopii zapasowej, kopie zapasowe innych poziomów można odzyskać za pomocą odzyskiwania zestawu zapisu.

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 #

Najważniejszym objawem jest to, że skaner nie jest w stanie przejść przez wymagane woluminy kopii zapasowych, zatrzymuje się przedwcześnie przed odczytaniem jakichkolwiek danych!

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 !!

Użycie pliku flagi debugowania NW: /nsr/debu/ndmp_auto_pos nie pomogło w przypadku pełnego zapisania kopii zapasowej ani odzyskania z możliwością przeglądania.

Nieprawidłowo sformułowany format woluminu NDMP spowodowany uszkodzeniem nagłówka NDMP generujący czasami błędne numery plików (np. automatyczne ponowne uruchomienie kopii zapasowej):  

Kontrola dzienników NW pokazuje, że każda kopia zapasowa jest połączona z błędem we/wy podczas zapisywania nagłówka NDMP. Jest to stały problem, który występuje przy każdej kopii zapasowej, jest to wskaźnik do spójnego uszkodzenia.

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'

Inspekcja dzienników NAS pokazuje, że rozmiar bufora urządzeń NDMP jest ustawiony na wartość mniejszą niż rozmiar bloku urządzenia skonfigurowany w NW. Domyślna konfiguracja NetWorker ustawia rozmiar bloku urządzenia dla urządzeń LTO-5 na 256 K, ale rozmiar bufora urządzenia NDMP (NDMP.bufsz) wynosi 128 K. Ta część jest powiązana tylko z nagłówkiem NDMP, ponieważ rozmiar bloku danych jest konfigurowany na serwerze NAS przez parametry konfiguracyjne PAX (domyślnie 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

Dziennik VNX pokazuje powiązany komunikat w czasie tworzenia kopii zapasowej:

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

Nie jest to uważane za problem z kopią zapasową, ponieważ strumień danych nie został uruchomiony, ale powoduje uszkodzenie nagłówka NMDP (patrz: NDMP: 3: Sesja 384 (wątek ndmp384) TAPE_WRITE, size(262144) > ndmpMaxBufSize (131072)Set NDMP.bufsz >= 262144 i uruchom ponownie), co rozwiązuje ten problem, ustawiając rozmiar bufora urządzeń NDMP na 256k. Korekta ta nie rozwiązuje jednak problemu z kopiami zapasowymi, które zostały już zapisane.

Powyższe uszkodzenie nagłówka NMDP może występować bez powodowania problemu z odzyskiwaniem, ale w przypadku ponownego uruchomienia kopii zapasowej zarejestrowany numer pliku w bazie danych nośnika NW jest nieprawidłowy. Spowoduje to unieważnienie automatycznego pozycjonowania taśmy, a tym samym serwer NAS zareaguje, że istniejące dane w tej pozycji nie mogą zostać rozpoznane jako prawidłowy strumień danych NDMP (błąd usługi NDMP: Nie można zidentyfikować formatu)

Mamy więc do czynienia z dwoma rodzajami uszkodzeń:

1. Błędy we/wy nagłówka NDMP spowodowane niespójnym ustawieniem rozmiaru bloku między NetWorker i VNX. Ten typ uszkodzenia jest pomijany przez funkcję automatycznego pozycjonowania i może istnieć przez wiele lat i nikt tego nie zauważy. Pod warunkiem, że w każdym zestawie zapisów są zarejestrowane odpowiednie numery plików.
2. Po ponownym uruchomieniu kopii zapasowej wiele nagłówków i stopek NDMP jest zapisywanych sekwencyjnie, a serwer NW przegapi właściwy numer pliku, w którym rozpoczyna się następna kopia zapasowa, co unieważnia automatyczne pozycjonowanie przy użyciu debugowania automatycznego pozycjonowania wyłączonego NDMP (/nsr/debug/ndmp_auto_pos) jest bezużyteczne w tym przypadku, ponieważ interfejs MTIO (Tape Management Interface) przestanie odczytywać, gdy napotka podwójny znacznik pliku (spowodowany uszkodzeniem nagłówka NDMP C1)