Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are restoring just the public folders database using Backup Exec 9.1.

The main EDB and STM files restored okay. However, the byte count has stalled and now there are tons of .IFS files in the database folder. 40-60 to be precise.

They appear to be rotating every few minutes, with incrementing names such as:


I am worried about doing anything, as this has taken over 7 hours to restore 70GB worth of public folders - plus another 4 hours doing this. Should I cancel the restore, should I try mounting the database manually, do nothing?

Note - although the database was mounted okay before we had the server crash (due to a failed disk) I am concerned that maybe the size of the database has fallen over the 75GB limit, which might be causing this?

  • pub1.edb = 53.6GB
  • pub1.stm = 24.79GB

Any suggestions on next steps?

EDIT - Restore has now been running for over 23 hours. Further note, there are 5 transaction log files in the temp folder, with restore.env at 1KB.

share|improve this question
For information on the .ifs files see this KB You can delete them as long as the IS isn't running. – ITGuy24 Feb 22 '10 at 21:16
Thanks, had a read of that a while ago. While BackupExec says it is busy restoring, I'm reluctant to stop the IS unless I'm told otherwise (with a good explanation behind doing so.) – Kez Feb 22 '10 at 21:53

While I've never had to restore the entire PF database, and certainly not with a version of BE as old as 9.1, my advice would be to let the job run. If it fails, it will fail and you'll be able to use the error codes in the job history to troubleshoot. Exchange restores (especially one of 75GB) generally take quite a bit longer than file restores as there's much more going on "under the hood".

share|improve this answer
It's that "under the hood" bit I'm interested in. I get the feeling maybe BackupExec has done its bit and has passed control over to Exchange to do the rest, i.e. to replay the log files or something? Could the size of the database cause the replaying to get "stuck"? I guess back to my "what's causing it" really. Kudos for beating expertsexchange by the way. – Kez Feb 22 '10 at 22:00

Does 9.1 have SGMon? the logging tool.. it will be in the program directory, you can actually see it working if the status stops updating.

It will show you all the "under the hood" you can take!

share|improve this answer
Ooh, it does appear to have that command, but all it's doing is scrolling lots of meaningful rubbish (unable to find a single hit on Google). VxSvc: MegaThreadCommand: 22 success (lots of these and a few others, 109, 110). Thanks. – Kez Feb 23 '10 at 8:50
If you have a support contract with Symantec, you can email the log and get them to explain it. Found this: Which suggests to "patch windows till it works" & isn't very inspiring. – Grizly Feb 23 '10 at 14:18
up vote 0 down vote accepted

Urgh. Yet another whole day lost, speaking to Microsoft Exchange support.

We had to kill off all the BackupExec services to release locks on the files and then perform a hard recovery on the restored files using eseutil.

Painful, but all up and running again.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.