OES Linux and HP Dataprotector OID_AddEntryIfNotThere - Unable to map GUID to DN using NCP errors

  • 7000112
  • 16-Apr-2008
  • 27-Apr-2012

Environment

Novell Open Enterprise Server 1 (OES 1)
Novell Open Enterprise Server 2 (OES 2)
Novell Cluster Services 1.8.4
HP OpenView Storage Data Protector 5.5, 6.0, 6.1

Situation

Running a backup job using HP Data Protector causes the server to crash.

The backup causes a faulty archiver ID to be set, and which causes the GUIDtoDN lookup to fail. The large amounts of failed GUIDtoDN lookups is to much for ndpapp to handle and hence causes ndpapp to crash


When new files are being copied to a volume we see the following archiver ID.

server:/home/user # grep archiver guid.txt
<archiver><name><![CDATA[Unknown User]]></name><id>00000000-0000-0000-00-00-000000000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>00000000-0000-0000-00-00-000000000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>00000000-0000-0000-00-00-000000000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>00000000-0000-0000-00-00-000000000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>00000000-0000-0000-00-00-000000000000</id></archiver>


Next, we run a backup using Data Protector, we find archiver GUIDs similar as below.

server:/home/user # grep archiver guid.txt
<archiver><name><![CDATA[Unknown User]]></name><id>00000100-0000-0000-00-04-170022003200</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>01004c4c-0000-0000-00-00-000417002200</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>317e5845-422e-5441-00-01-000000000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>48494e4d-7e45-2e31-45-58-450001000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>4558452e-0100-0000-00-00-000000041700</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>58452e31-0045-0001-00-00-000000000417</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>58452e31-0045-0001-00-00-000000000417</id></archiver>


It turns out that virtually all of the GUIDS are (or parts of) filenames and are bogus ID's :

For example :
3. guid=57494E324B2F434F4F4B4945532F3037
57494E324B2F434F4F4B4945532F3037   WIN2K/COOKIES/07
3. guid=38000000380000003A00000077000000
38000000380000003A00000077000000   88:w
3. guid=002C00340041002F6D656469612F6E73
002C00340041002F6D656469612F6E73   ,4A/media/ns
3. guid=767363695B325D2E7478740000000000
767363695B325D2E7478740000000000   vsci[2].txt
3. guid=767363695B325D2E7478740000000000
767363695B325D2E7478740000000000   vsci[2].txt


With OES2 SP1 the error also shows as OID_AddEntryIfNotThere - Unable to map GUID to DN using NCP eDir  in /var/log/messages during the time frame when the backup is running

Resolution

A fix has been checked in to the 'libtsafs.so.0.0.52' module and has been released to the public.

Bug Number

352610

Additional Information

With this fixed module it is required to run a full backup.

The full backup ensures that all files that were previously populated with the bogus archiver GUID's are reset to 00000000-0000-0000-00-00-000000000000 again.