cancel
Showing results for 
Search instead for 
Did you mean: 

Back-up Exec 12.5 Restore job is insanely slow

Pete_Continenta
Level 3

The situation is this - I have a Dell PowerEdge Server running Back-up Exec 12.5, doing daily, weekly, monthly backups (the production server).

I have a cloned Dell PowerEdge Server - exactly the same configuration (the Disaster Recovery server).

Both servers are able to read/write RDX removeable hard disk cartridges with 320GB capacity in native format (no compression).

To test my DR capability I am trying to restore some files/folders from the production weekly (Full) back-up disk to the clone server.

To achieve a restore on the clone server I have to go through these steps:

- Run an Inventory job on the removeable disk cartridge.

- Run a Catalogue job on the removeable disk.

- search the catalogue for the folders/files I want to restore.

- start a 'restore' job using the folders/files I've found in the catalogue.

Here's the problem:

Running the back-up on the production server takes about 6 hours (writes about 300GB of data).

Running the Catalogue job on the clone server takes over 24 hours.

Running the Restore job on the clone server, to restore about 6.5GB of data, ran for 16 hours and was only 10% complete - so it's going to take about 160 hours to restore 6.5GB of data!!

I'm a compete novice with Back-Up Exec - I MUST BE DOING SOMETHING WRONG. Can anybody outline for me the steps, switchs, flags, settings, I need to adjust to make this work?

 

Thanks in advance - Pete

1 ACCEPTED SOLUTION

Accepted Solutions

Steve-Young
Level 6
Employee

Your steps sound about right but there is a pattern.  Both the catalog and restore are "reading" data from the RDX vs Backup writing to the RDX. Its possible that WIndows and BE can write to RDX fast but read it back slow.

Have you tried copying one of the BKF files on RDX to your servers C: drive to see if you see the same slow transfer of the file copy in WIndows? Then copy the file back from server to rdx.

 

I dont think somebody would have disabled Fast File Restore Registy key which would make a restore and catalog slow.  The reg key should be set to 1.

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

 

 

 

View solution in original post

5 REPLIES 5

lmosla
Level 6

Is Backup Exec updated to the latest service pack?

Steve-Young
Level 6
Employee

Your steps sound about right but there is a pattern.  Both the catalog and restore are "reading" data from the RDX vs Backup writing to the RDX. Its possible that WIndows and BE can write to RDX fast but read it back slow.

Have you tried copying one of the BKF files on RDX to your servers C: drive to see if you see the same slow transfer of the file copy in WIndows? Then copy the file back from server to rdx.

 

I dont think somebody would have disabled Fast File Restore Registy key which would make a restore and catalog slow.  The reg key should be set to 1.

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

 

 

 

Pete_Continenta
Level 3

Thanks for the feedback.

Service Pack - the clone dates from April. The DR server is not on the WAN so can't install patches. In a 'real' disaster situation the clone would be on the WAN so that's not an issue in the 'live' situation, but I can't address it in the test situation.

I checked the registry keys - Use Fast File Restore is switched on.

I'm re-running my test. In an attempt to eliminate disc fragmentation - I did a format disc on the RDX removeable hard disk before running the backup. And, I've switched off anti-virus on the clone server so it won't interfere with the restore speed.

If that doesn't work I'll try copying the B2D files to the hard drive and doing the restore from there - as you suggest. Problem with that is I have very little spare disc room on hard drive - certainly not enough to contian a full back-up.

I'll post the results of my test when available. Any other suggestions?

Thanks - Pete

Pete_Continenta
Level 3

The catalogue job did about 25GB in 55 minutes. Pretty good.

The restore job has done 762,052 bytes in 40 minutes!! It is never going to finish.

Help!

Pete_Continenta
Level 3

Thanks for your help - this issue is closed now.