Highlighted
Absent Member.
Absent Member.
1595 views

Data Protector Auto DR random failures on w2k3 hosts

We are experiencing some issues with data protector 6.1 on some hosts where the Configuration Backup fails.
The error message is:

[Minor] From: VBDA@onama.ulss17.intra "onama.ulss17.intra [/CONFIGURATION]" Time: 24/05/2010 21.04.22
[81:145]
Automatic DR information could not be collected.
Aborting the collecting of system recovery data.

[Minor] From: VBDA@onama.ulss17.intra "onama.ulss17.intra [/CONFIGURATION]" Time: 24/05/2010 21.04.22
[81:141] \SystemRecoveryData
Cannot export configuration object: (Unknown internal error.) => backup incomplete.

Looking into autodr.log the error always happens (when it does at all) while processing the SOFTWARE registry hive.

I am attaching the autodr log file.

If anyone could help it would very much appreciated.

Thanks in advance,
Umberto
0 Likes
10 Replies
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Hi Umberto,

I saw same error on DP6,and the issue was fixed with patches.


But on 6.1 I never saw, so try this :
stop services
delete everything inside C:\Program Files\OmniBack\tmp
start services and try again.

Regards



Please assign a kudo to this post, if you find it useful.
0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Umberto,

We are having a similar issue.
Did this got resolved and if so what was the resolution?
0 Likes
Highlighted
Absent Member.
Absent Member.

my mistake, I thought I was running DP 6.1 but I am still running 6.0. I will upgrade asap (I'm waiting to renew maintenance) and then let you know if that solved the problem.

After I have upgraded I will award the points.

Thanks for your help,
Umberto
0 Likes
Highlighted
Absent Member.
Absent Member.

Upgraded to 6.11 (with latest patches), but the problem persists.

The autodr.log reports the following:

20110404T190432 INFO filelist File (C:\WINDOWS\system32\imon.dll) not found.
20110404T190432 WARN svclist Converting binary value (DependOnService) to string list.
20110404T190432 FATAL winreg EXCEPTION at src\sysinfo\winreg.cpp(960):
20110404T190432 FATAL winreg class drm::inval_error(2): Invalid data in binary buffer.
*** Stack traceback:
*** 12: class boost::shared_ptr,class std::allocator >,class std::allocator,class std::allocator > > > > __cdecl drm::reg_value::get_reg_binary(void) const -- src\sysinfo\winreg.cpp(952)
*** 11: class boost::shared_ptr,class std::allocator >,class std::allocator,class std::allocator > > > > __cdecl drm::safeboot_services::try_getval_multisz(const class drm::reg_key &,const class std::basic_string,class std::allocator > &,bool) const -- src\core\svclist.cpp(152)
*** 10: void __cdecl drm::safeboot_services::scan_services(void) -- src\core\svclist.cpp(350)
*** 9: void __cdecl drm::safeboot_services::add_safeboot_files(class boost::shared_ptr) -- src\core\svclist.cpp(1148)
*** 8: void __cdecl drm::`anonymous-namespace'::mkrset::save_system_files(void) -- src\coolie\mkrset.cpp(1273)
*** 7: class boost::shared_ptr __cdecl drm::`anonymous-namespace'::mkrset::prepare_drm(void) -- src\coolie\mkrset.cpp(1372)
*** 6: class boost::shared_ptr __cdecl drm::prepare_recovery_set(class boost::shared_ptr,const class drm::upath &) -- src\coolie\mkrset.cpp(1466)
*** 5: void __cdecl drm::`anonymous-namespace'::rs_create_api::operator ()(class drm::command::command_data &) -- src\coolie\coolieapi.cpp(970)
*** 4: void __cdecl drm::command_manager::handle_command(class drm::command::command_data &) -- src\core\cmdmgr.cpp(46)
*** 3: bool __cdecl drm::`anonymous-namespace'::handle_command(class drm::`anonymous-namespace'::api_manager &,class drm::command::command_data &) -- src\coolie\coolieapi.cpp(1236)
*** 2: void __cdecl drm::coolie_interactive(void) -- src\coolie\coolieapi.cpp(1286)
*** 1: void __cdecl drm::coolie(int,char *[]) -- src\coolie\coolie.cpp(173)
*** 0: int __cdecl wmain(int,wchar_t *[]) -- src\coolie\coolie.cpp(276)
20110404T190432 INFO command Result: DRM(-4):SYS(2) ()
20110404T190432 INFO command Command: ri_close (1)
20110404T190432 INFO command Result: DRM(0):SYS(0) ()

0 Likes
Highlighted
Absent Member.
Absent Member.

I have done some more investigation and given the last error happens in svclist while it is decoding the DependOnService registry key I have been digging the registry and found that the service ScardSvr (smartcard) does have a binary value in dependonservice:

DependOnService: 50 6c 75 67 50 c6 61 79

which apparently translates to 'plugplay'.

I have renamed the existing key and created a new one with a multistring value. I'll report if this works tomorrow.

0 Likes
Highlighted
Absent Member.
Absent Member.

I've checked the server with the registry edit today and the issue seems gone.
Now I only have to regedt32 10 other servers 😞
0 Likes
Highlighted
New Member.

Take a look at the "REG" command...
.
0 Likes
Highlighted
Established Member..
Established Member..

Anyone have an update on this? I'm having the same issue.
0 Likes
Highlighted
Absent Member.
Absent Member.

@A_C: as I said I solved by inspecting the autodr.log file in each of the failing servers.

For most of them it was easy because I only had to edit the registry as I wrote above, for one other the issue is caused by a locked file (sfdp.sys or something like that). I will reboot this last server and see it that fixes this last issue.

I suggest you review the OMNIBACK_HOME\tmp\autodr.log file and check for any obvious error.

HTH,
Umberto
0 Likes
Highlighted
Absent Member.
Absent Member.

I solved the problem with deleting the TMP-folger on the cell-server.

I'm using DP 6.11.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.