Recovery of Windows System Drive always failing with status 5

[Nova]

I am following http://seer.entsupport.symantec.com/docs/295342.htm. for W2K3 The newly built client is of the same client version as used for the backup. System patch level is the same, exact same hardware (being rebuilt in place). The full backup used for the restore was exit status 0. As directed by the document, only C:\drive has been restored as the first step. The exit status is 5. The end result is that 3 files were not successfully restored, but below are a few of the more relevant lines from the bpbrm log. The bprbrm log contains: 13:41:22.769 [8661] <8> bpbrm main: from client clientName: WRN - System needs to be rebooted for registry file to take effect: C:\WINDOWS\system32\config\default 13:41:24.463 [8661] <8> bpbrm main: from client clientName: WRN - System needs to be rebooted for registry file to take effect: C:\WINDOWS\system32\config\SAM 13:41:26.144 [8661] <8> bpbrm main: from client clientName: WRN - System needs to be rebooted for registry file to take effect: C:\WINDOWS\system32\config\SECURITY 13:49:03.926 [8661] <2> bpbrm main: from client sdssdevs1.tcsa.ad: INF - TAR RESTORED 159208 OF 159211 FILES SUCCESSFULLY 13:49:03.977 [8661] <2> bpbrm main: from client sdssdevs1.tcsa.ad: INF - TAR KEPT 0 EXISTING FILES 13:49:03.977 [8661] <2> bpbrm main: from client sdssdevs1.tcsa.ad: INF - TAR PARTIALLY RESTORED 0 FILES 13:49:03.977 [8661] <2> bpbrm main: from client sdssdevs1.tcsa.ad: INF - TAR EXITING WITH STATUS = 5 - the restore failed to recover the requested files The document does not even metion an exit status 5 code. I would expect that the above 3 files. I guess there is nothing more than can be done but to go ahead and run the w2koption -restore -same_hardware 1 and proceed with System State restore (I have been down this path and ended up with less than stellar results, so Idon't have the greatest confidence). I was really wondering if anybody here can offer an opinion on whether the tech doc I reference is the best guide to the disaster recovery of W2K3 system. thanks to any and all who read this -;)

[Rajesh_s1]

Download the Microsoft hotfix from the KB article # 940349 and install it on the destination client and reboot the server once .  This hotfix will resolve the VSS issues .

Then try for a small file restore and then proceed with your actual recovery .

Note: Please be careful on the destination client name while carrying out the DR .

Restore completely C:\ drive on the destination client and then restore the system state backup (Don't forget to check on overwrite option) . Once both the restores successfull reboot the machine and check.

[zer0sig]

Are you sure those files weren't copied? From the looks of that error, they were copied, but Windows would not read them because Windows will not reread a registry file like that when it was not placed there by Windows itself, e.g. by RegEdit or certain applications that are shoehorned into Windows via certain APIs. I would check the Created and Modified dates on those files to ensure that in fact NetBackup did NOT restore them.

[Nicolai]

FYI - Sometimes a status code 5 is shown to indicate a reboot is necessary.

[Rajesh_s1]

From BPBRM logs 3 files saying reboot is required , that is correct a reboot is required to take new files into effect. But actually these are not the files which are making your restore to failure . Please verify the logs on the activity montior you can able to see which files are not able to restore .  Ofcourse when you are overwriting on the system files it requires reboot to take new files into effect .

Fallow my steps which i mentioned earlier , restore may successfully happen . I had the similar issues earlier while doing DR , but when i started applying hotfixes and doing restore then in many instances restore was happening successfully .

[Nova]

zer0sig - thanks for the input. Those files were definitely all laid down by Netbackup. Have checked that with the Windows admin guy, and everything was by the book.

[Nova]

Rajesh - Well, I did look harder at the verbose tar log from the client and actually found the 3 files not restored. I was not searching on the correct term 'create'. From what I understand, they are 'special' cache files.

1:31:13.625 PM: [1140.412] <2> tar_base::V_vTarMsgW: WRN - can't create file: C:\WINDOWS\assembly\GAC_32\System.EnterpriseServices\2.0.0.0__b03f5f7f11d50a3a\System.EnterpriseServices.Wrapper.dll (WIN32 3: The system cannot find the path specified. )

1:31:16.125 PM: [1140.412] <2> tar_base::V_vTarMsgW: WRN - can't create file: C:\WINDOWS\assembly\GAC_MSIL\IEExecRemote\2.0.0.0__b03f5f7f11d50a3a\IEExecRemote.dll (WIN32 3: The system cannot find the path specified. )1:31:13.625 PM: [1140.412] <2> tar_base::V_vTarMsgW: WRN - can't create file: C:\WINDOWS\assembly\GAC_32\System.EnterpriseServices\2.0.0.0__b03f5f7f11d50a3a\System.EnterpriseServices.dll (WIN32 3: The system cannot find the path specified. )

I did not have verbose logging on bpbrm on the Master, so did not find anything in there.

The server is now doing a continuous reboot, although it is exactly the same hardware and OS.  Something to do with Windows security perhaps. I don't know Windows deeply enough to know. The failure to restore the above 3 files should not cause this, should it?

P.S. thanks for  the tip on the VSS hotfix. I will check on it.

[Nova]

Nicolai - after the restore of system drive C:, System State was laid down, making sure that w2kiption for same hardware was run (restoring registry keys for same hardware), but that is when the continuous boot thing started.

[Nova]

It appears that we are now dealing more with a Windows issue (the continuous reboot), than a Netbackup restore issue. The exit code status 5 is explained by the 3 files indicated in tar log.
That was rather non-observant of me to not find the log entries for them the first time around, and I am sorry for mis-using your time. But it did help me

The following doc refers to an error that briefly flashes by as server comes up
http://seer.entsupport.symantec.com/docs/262411.htm
but since lots of care was taken to be sure the hardware was the same and w2koption for same hardware was run, it must be something not quite right with the registry restore.

We're going to try it again from a slightly older backup, and cross our fingers.

I really appreciate the input given here. I try to give  back here too, but it seems there are so many knowledegeable contributors that by the time I see it, there is nothing more I can add.

Cheers.

[Nicolai]

use the  w2koption.exe -restore -same_hardware 0 , even if it's same hardware. But is not a guarantee it will work.

Good Luck.

[Nova]

Restarting the client prior to reboot was missed I think first time around. Whether or not it was the difference maker, the restore worked fine.

I did not want to deviate from using the w2koption.exe -restore -same_hardware 1, since it is the exact same machine.

thanks

[Rajesh_s1]

HI Nova,

What's the current status , is the resore worked fine ?

Still you are facing issue ?

Regards,
Rajesh