cancel
Showing results for 
Search instead for 
Did you mean: 

Exchange Agent does not over write media

ProjectGuy
Level 3
Partner
Hi, 
 
   I have BE11d sp1 on a dedicated media server with Exchange and SQL server agent installed, for SQL servers and Exchange 2003.
 
   In addition there is a File server with Microsoft iSCSI target creating a virtual 100GB harddisk for the media server.  The drive name is G.
 
   The media server is setup to backup to disk onto a NAS. The Exchange Agent will only support backup to disk to a local folder on the media server.  So I point it to G drive, set it to over write media. Config another job to re-backup everything on G drive to the NAS.
 
   Everything works except that the Exchange Agent does not over write the media.  It keeps insisting on appending and every 2 days the virtual disk run out of space.  The actual Exchange stores is about 25 GB.
 
   Help?
 
19 REPLIES 19

Hywel_Mallett
Level 6
Certified
I would guess that when you backup the Exchange information you are using a media set which is overwrite protected. If so you need to either use another media set, or change the overwrite protection period on the one you are using.

ProjectGuy
Level 3
Partner
Thank you for your speedy reply. I have set the overwrite protection on the B2D folder to 2 hours for a 4 hour backup job.  But there is no improvement.
 
Note: Setting overwrite protection to 0 gives an erratic performance.
 
 


Message Edited by ProjectGuy on 10-23-2007 05:04 PM

J__Bryan_Wehren
Level 3
I am having the exact same issue. It appears to be the IMG folders that are not being overwritten, even though they show that they are able to be overwritten.  It's like they are not following the same rules as the B2D files in the media set.

Scott_Straub
Level 4
This is by design.  See this thread.

Sadly, I think all you can do is use the enhancement request link in that thread and ask to have Exchange B2D media sets follow the same rules the rest of the media types follow. 

I think of this as a bug more than enchancement myself...

Traber
Level 2
The IMG folders don't get overwritten in the same way B2D BKF files do.  I don't have the link to the Symantec support note on hand, but this is "by design".  Basically, the IMG folders are deleted by the Exchange job when the disk runs out of space (based on your disk reserve) and there are "expired" IMG folders available to delete.  Any other backup job will not delete the folders. 

We've found that the only reasonable solution is to have a partition dedicated to the Exchange GRT (IMG) backups.  That way, it can manage all the space itself.

J__Bryan_Wehren
Level 3
That doesn't seem like a very good design in my opinion. They should act like every other b2d file/folder.

Scott_Straub
Level 4

@J. Bryan Wehrenberg wrote:
That doesn't seem like a very good design in my opinion. They should act like every other b2d file/folder.


I don't think it seems like good design in anyone's opinion.  You should go here and submit an enhancment request. This is all we can do until Symantic ranks it higher on their list of to-dos and decides to fix it.

ProjectGuy
Level 3
Partner
ok, I think this is fixed. 
 
Problem Description
Exchange Agent could not over write media in B2D folder daily.  It turns out that the IMG folders were not over written.  I have 62.2GB of data going into a 100GB folder.
 
Fix
Add a reserve space in the "Device, Advanced properties". 1GB or 500MB.  In my case 1GB.  When the IMG folders fill up to 99GB, it flashed a an alert about reclaiming space.
 
"Begin processing to reclaim space from expired media.
Reclaiming space from expired PDS media

Deleted Media Information:
Name = Media created 10/26/2007 9:33:27 AM, Label = IMG000030, Location = g:\IMG000030"
It will over write any expired media in the B2D folder.  Note the old IMG folders will disappear and it appears that Backup Exec is backing up, with no new IMG folders created.  Wait for the job to finish and all the files will get written out.
 
In summary, I think it is due to the way it reads the disk free space.  Not entering a value in the disk reserve space confuses the agent.
 
regards

Scott_Straub
Level 4


@ProjectGuy wrote:
ok, I think this is fixed. 
 
Problem Description
Exchange Agent could not over write media in B2D folder daily.  It turns out that the IMG folders were not over written.  I have 62.2GB of data going into a 100GB folder.
 
Fix
Add a reserve space in the "Device, Advanced properties". 1GB or 500MB.  In my case 1GB.  When the IMG folders fill up to 99GB, it flashed a an alert about reclaiming space.
 


ProjectGuy,

Perhaps you could clear up these questions I have.

On your Exchange B2D Folder device, what are your settings for these options:
    1. Maximum size for backup-to-disk files:
    2. Allocate the maximum size for backup-to-disk files:
    3. Maximum number of backup sets per backup-to-disk file:

What media set are your Exchange B2D jobs part of?  What are the overwrite and append rules for that set?

I tried adding the disk space reserve as you said, but I don't see what this disk space reserve has to do with the IMG folders, since the actual B2D file is a different file altogther.  My maximum size for B2D files on the Exchange folder is 20 MB, while the IMG folders that are created during a B2D job for Exchange are at least 18 GB.

ProjectGuy
Level 3
Partner


@Scott Straub wrote:


@ProjectGuy wrote:
ok, I think this is fixed. 
 
Problem Description
Exchange Agent could not over write media in B2D folder daily.  It turns out that the IMG folders were not over written.  I have 62.2GB of data going into a 100GB folder.
 
Fix
Add a reserve space in the "Device, Advanced properties". 1GB or 500MB.  In my case 1GB.  When the IMG folders fill up to 99GB, it flashed a an alert about reclaiming space.
 


ProjectGuy,

Perhaps you could clear up these questions I have.

On your Exchange B2D Folder device, what are your settings for these options:
    1. Maximum size for backup-to-disk files:
    2. Allocate the maximum size for backup-to-disk files:
    3. Maximum number of backup sets per backup-to-disk file:

What media set are your Exchange B2D jobs part of?  What are the overwrite and append rules for that set?

I tried adding the disk space reserve as you said, but I don't see what this disk space reserve has to do with the IMG folders, since the actual B2D file is a different file altogther.  My maximum size for B2D files on the Exchange folder is 20 MB, while the IMG folders that are created during a B2D job for Exchange are at least 18 GB.


1. 5GB (default was 1GB)
2. Unchecked (default)
3. 100 (default)
 
Media sets, "Overwrite Protection Period" set to 4 hours, duration of backup. Note my B2D files is about 2kb, the IMG folder is 36GB.  The B2D files are 5GB for my other servers.  GRT puts the actual Exchange data in IMG folders.  Almost nothing goes into B2D files.
 
According to the kb 286794 the IMG folders does not totally follow media rules.  Only the B2D files do.  How you want the IMG folders to overwrite, use the reserve space to control.
 
Lets say your Exchange data comes to 18GB and your B2D folder is 50GB.
 
1. You want only 1 media set in your B2D folder.  50-18-5 (a buffer figure for growth) = 27GB.  Set your reserve space to 27GB.  Every day the IMG folder will be overwritten as  18+18 =36, which is larger than 23GB.
 
2. You are not very concern about how many media sets. Set the reserve space to 1GB and you have 49GB of space. That is approximately 49/18  or 2.72 days or every third day it will overwrite.
 
Note BE have some control files and extra transaction logs which comes up to 1GB.
regards

 


Message Edited by ProjectGuy on 10-28-2007 01:41 PM

Scott_Straub
Level 4


@ProjectGuy wrote:

Lets say your Exchange data comes to 18GB and your B2D folder is 50GB.



This is where you lose me.  Where is there a setting that says your "B2D folder" is 50 GB?  You stated your settings and none of them are 50 GB.  It sounds to me like the "B2D folder" you are referring to is really your hard disk partition, which is completely different.


ProjectGuy
Level 3
Partner


@Scott Straub wrote:


@ProjectGuy wrote:

Lets say your Exchange data comes to 18GB and your B2D folder is 50GB.



This is where you lose me.  Where is there a setting that says your "B2D folder" is 50 GB?  You stated your settings and none of them are 50 GB.  It sounds to me like the "B2D folder" you are referring to is really your hard disk partition, which is completely different.





Hi, You are right.  I was referring to the size of the B2D folder which is in a separate disk partition. (Actually mine is an iSCSI target but that is going OT).
 
The rest of calculation still applies. As of this time of writing, I got it over write 3 times on 3 days.
 
regards

Scott_Straub
Level 4


@ProjectGuy wrote:

Hi, You are right.  I was referring to the size of the B2D folder which is in a separate disk partition. (Actually mine is an iSCSI target but that is going OT).
 
The rest of calculation still applies. As of this time of writing, I got it over write 3 times on 3 days.
 


Ok, thanks for clarifying.

I think your solution will work for some people and is pretty much what Symantec expects you to do, but I don't really see it as a solution to the problem described in this thread.  Not everyone has available or wants to dedicate an entire partition to Backup Exec B2D folders...  We want flexibility.

In my case, I just want one or two copies of Exchange, to aid in restore since GRT only works when restored from disk.  Everything else I want on tape.  If I have to dedicate a partition, that means a lot of extra work, since I don't have the luxury of using a new server for Backup Exec--I have to make do with what's already out there.  I would think this is the case for a lot of smaller businesses.

Scott

Calder_Chung
Level 4
Hi Scott,
 
Hope your B2D working fine now, is it ?
 
And can you share us what your configuration for this B2D Exchange backup ?

JRink
Level 3
Scott,
What do you mean GRT restores only work from disk?
 
Are you saying that GRT backups to tape cannot be restored?  I just started using 11d and my GRT Exchange backups are done ONLY to tape because of this stupid IMG B2D problem which don't overwrite properly unless you specify disk space etc. which doesn't work well in my environment.
 
Please clarify, thanks.
JR


Message Edited by JRink on 10-31-2007 08:53 AM

Scott_Straub
Level 4
JRink,

I haven't kept up with all the Exchange GRT issues anymore, as we are planning on dropping Backup Exec altogether.  It may work now, but it's definitely preferable to restore Exchange data from B2D instead of tape, as you have to restore the entire database even if you just want to recover a single message or mailbox. Here's a thread on this.

Ken_Putnam
Level 6

Well, you CAN do individual item restores from tape GRT, but you need enough space to restore the entire Stores backup, from which BE will then extract the item(s) to be restored
 
Nice design, huh?

Scott_Straub
Level 4


@Calder Chung wrote:
Hi Scott,
 
Hope your B2D working fine now, is it ?
 
And can you share us what your configuration for this B2D Exchange backup ?



My B2D jobs appear to be working, but the issue this thread talks about has not been solved.  I am manually deleting Exchange IMG folders once 5 or 6 have been created in order to deal with this situation.

I had another issue where B2D2T was confirmed as broken with GRT backups, but I haven't tried that recently (supposedly it's fixed now) and have been relying on ntbackup dumps of Exchange that go to tape directly with the rest of the normal backup.

Since our environment changed recently and I need to have a second media server at another site, I've began looking into other backup solutions instead of paying Symantec again for something that has been aggravating to use and not very reliable.

Scott

JRink
Level 3
I just want to add my $.02 that this whole thing about BE not overwritting Exchange B2D images as part of the standard media set scheme for overwrite is a complain pain in the a$$. 
 
I ended up having to create a seperate LUN on my SAN to do Exchange B2D backups so I could setup appropriate disk quotas just for this purpose.  Bah.  Lame.
 
JR