Jump to content
MaraDE

Writing the snapshot takes a long time

Recommended Posts

We have Restrospect Small Business Server Premium V7.5.387 running on a Windows 2003 Server. This server is backing up itself with two local drives (c: and d:) an the exchange server.

 

The backing up of the data drive (d:) and the exchange server works fine and it just takes minutes to finish this process. When it comes to the system drive (c:), the backing up time is ok, but the snapshots takes a very long time (several hours) to be written.

 

The snapshot is really large (~200 MB) and I compared it to the one from drive d: which contains dramatically more files and folders than the system drive, but this snapshot is round about 30 MB big.

 

Then I created several subvolume folders for each local folder in the root directory of the system drive and started a backup with the subvolume folders and guess what, then the complete backup process finished in a few minutes including the snapshot.

 

The question now is, what is going on here? Why does the backup of the local drive takes such a long time, whereas the backup of the subvolume folder finishes in several minutes?

 

Edit: By the way, It has nothing to do with the tape drive. Backing up to disk also ends up in a slow writing of the snapshots.

 

Regards,

Oliver

Share this post


Link to post
Share on other sites

I've found the solution to this problem:

 

Our virus scanner caused all the trouble while scanning the file setupapi.log during Restrospect was writing the snapshot. After excluding that file from scanning, everything worked fine.

 

But one questions remains: Why does the problem only occur, when Retrospect backs up the whole drive. Backing up the data via subvolume folder, what means that the setupapi.log is also backed up, doesn't end up in taking so long until the snapshot for that specific subvolume folder containing the file is successfully written.

 

Greetings,

Oliver

Share this post


Link to post
Share on other sites

This fix worked for me as well. I am running 7.0.326 and it used to take 7+ hours for the snapshot on one client machine. Now it takes 35 minutes. Thank you for finding the problem.

 

I'd still like to know how you found it.

Share this post


Link to post
Share on other sites

Which anti-virus program are you using? What does that software vendor say about scanning that file?

 

http://www.windowsitpro.com/article/articleid/40200/what-log-files-does-windows-xp-create-during-installation.html

setupapi.log-XP writes information to the setupapi.log file each time a .inf file executes, including any errors. XP writes the setupapi.log file to the %systemroot% folder.

Share this post


Link to post
Share on other sites

Thanks for the quote.

 

I am using ESET Smart Security 3.0. I haven't tried to find out what the vendor says because that problem is solved and I have another pressing one right now. However, searching ESET's KB for setupapi.log returned no hits.

Share this post


Link to post
Share on other sites

I had the same problem using Retrospect Multi Server Win 7.5.387, when it was on the Backup Source of the hard drive on which I have both WinXP SP2 and Retrospect svr installed. It copied all files over just fine, but "Building Snapshot..." appeared hung for >6 hours and no disk activity.

 

I am using ESET NOD32 Antivirus 3.0.566.0, a very poweruser-friendly scanner that, up until now, has never given me any trouble.

 

Upon doing the following steps, much disk activity occured and in 30 seconds, Retrospect moved on to the next Backup Source, and everything works fine now:

 

1) Double-click ESET icon in SysTray

2) Navigate to Tools -> 'Entre entire advanced setup tree...' -> 'Antivirus and antispyware' -> Exclusions property sheet

3) Hit "Add...", and type in C:\WINDOWS\setupapi.log

4) Commit change and close the dialog(s)

 

I will pass this on to ESET. I hope this helps others having this problem.

 

-Jeff

 

PS : I have 'Software data compression' and 'Media Verification' both ENABLED.

Edited by Guest

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×