cancel
Showing results for 
Search instead for 
Did you mean: 

Questions on full restore of Window 2008 Servers

Eamonn
Level 3

Hello,

 Since we do not currently have BMR configured in our enviroment (and adding it will require a long approval process, so we need an alternative in the meantime) we have been doing some testing on system restore following the document below:

http://www.symantec.com/business/support/index?page=content&id=TECH56473

When we've tested on our 2003 boxes everything works great.

However we've been running in to issues with the 2008 boxes.

Basically restoring C: (and any other drives), and the Shadow Copy Compenents works, but when we try to restore the System State issues come up.

When you look at the job you'll find the following at the end:

03-Jan-2012 3:03:30 PM - restored image client01-test_1325115199 - (file read failed(13)); restore time 00:03:15
03-Jan-2012 3:03:40 PM - Warning bprd(pid=3960) Restore must be resumed prior to first image expiration on 2/4/2012 3:33:19 PM
03-Jan-2012 3:03:49 PM - end Restore; elapsed time: 00:04:45
the restore failed to recover the requested files(5)

And the following the the TAR log:

<2> ov_log::V_GlobalLogEx: ERR - beds_ss_access::V_Write:FS_WriteObj() Failed! 0xE000848F:Insufficient disk space.

 

Checking the servers we're restoring to their C: drives are full now, often as low as 15MB of free space.

For the latest test, prior to the restore 13.8GB of 33.8GB was free. (Small disk space for C: is common around here as there are over 500 servers/VMs and only some much disk space to go around).

Once I restored C: it dropped to 11.9GB, as expected as many files will require a reboot before being able to replace the current files.

Shadow copy restored and drive space barely changed.

System state fails, with the above errors.

Looking at the drive now on 28MB of space is free.

When I check the backup of the system state we are restoring from it's ~14GB in size, which will lead to a failure as the majority of (if not all of) the system state will need to wait for a reboot before being able to replace the current files, so the entire ~14GB will need to sit in a temporary location first.

 

So the issue is on the 2008 boxes the system state is often going to be larger than the available C: drive space, whereas in 2003 the system state was much smaller.

 

My question is, is there any way around this?

Should we be making adjustments to the backup or restore proceedures to use this method?

Or is the only answer to have larger drives put in place/implement BMR?

Thank you in advance for any information you can provide.

 

1 ACCEPTED SOLUTION

Accepted Solutions

Nicolai
Moderator
Moderator
Partner    VIP   

You need to ensure there is 20G free before starting the restore. During the restore Shadow Copy Components are copied to the C: (active shadow copy components is not overwrite) drive and then upon reboot activated. 

We had the same issue some time ago. There is nothing you can do about it, because it's all Windows API's Netbackup is calling. 

We have ensured all our 2008 have large C: drives and it's written into the DR procedure to check free space before performing total system restore.

When we reach 7.1 we will have BMR enabled. Restoring Shadow Copy Components seem always to be a little fragile. 

View solution in original post

2 REPLIES 2

Nicolai
Moderator
Moderator
Partner    VIP   

You need to ensure there is 20G free before starting the restore. During the restore Shadow Copy Components are copied to the C: (active shadow copy components is not overwrite) drive and then upon reboot activated. 

We had the same issue some time ago. There is nothing you can do about it, because it's all Windows API's Netbackup is calling. 

We have ensured all our 2008 have large C: drives and it's written into the DR procedure to check free space before performing total system restore.

When we reach 7.1 we will have BMR enabled. Restoring Shadow Copy Components seem always to be a little fragile. 

Eamonn
Level 3

Thank you, that was what I thought.

Tested with the exact same system with more space allocated to C: to bring it up to 20GB (from the ~13GB it had), and sure enough it restored without issue.