Build 7071, GRT, and filling drives

[Howard_Brown]

I just installed build 7071 last week, and was hoping that the claim that the issue with filling up drives was fixed were true. It doesn't seem to be.

This isn't just for Exchange B2D backups, either. It appears that Sharepoint Portal Server 2003 GRT backups also fill the drives up.

I don't really have the option of using three separate drives/partitions to do my backups, nor is it economical complexity wise (change management, documentation) for me to create three separate policies that run three separate jobs to disk, then duplicate those jobs to tape. I already am forced to manually spin my Exchange B2D jobs to tape (by backing up the IMGXXXXXXX folder as a file), because it does not duplicate the correct IMG folder - it just duplicates the same one over and over if I use a policy. Note that I was forced to stop using CPS Exchange protection for a similar reason. It just didn't work as advertised.

I haven't a clue what it is backing up/duplicating with Sharepoint - I can only glean that it is creating an infinite number of IMGXXXXXXX folders by looking in the B2D folder in Windows. Does the duplicate job actually duplicate the IMG files as well, or only the B2D? It says it is backing up Sharepoint, but it doesn't say how/what it is backing up in the log.

It seems that a job configured to make full backups of Sharepoint and/or Exchange using GRT (that is, make individual items restorable from the backups - be it SPS or Exchange), as well as configured to overwrite, continue to create IMG* folders ad infinitum. The only thing that it ever over-writes is the B2D files, never the IMG files.

If I delete any image files to free up space, I have to re-create the jobs. Why?

Because if I uncheck the box in the selection for a deleted/old directory in the selection list it just adds an entry to EXCLUDE the directory, rather than removing it from the selection list entirely. Even if I take the "pdeudo-media" IMG file offline, add it to retired media, and then delete it.

What to do? 

[Howard_Brown]

Tap, tap, tap...

Is this thing on?

I am starting to run out of disk space again. Maybe I need to re-state the issue.

A GRT Job (either Exchange 2003 or Sharepoint Portal Server 2003, no CPS) set to "Overwrite" does not overwrite on B2D folders.

Instead, it perpetually creates IMG* folders (where * is an incremental number) below the B2D folder which eventually fill up the drive the B2D folder is on, which results in job failures (well, duh).

A policy created duplicate job does not spool the IMG* folder to tape, but appears to repeatedly try to duplicate the same backup job every time.

It is necessary to create a manual backup job and selection list, and modify the selection list every day in order to archive the GRT backup.

Manually moving the virtual media to Retired Media, then deleting that media, and finally deleting the folder(s) on disk, while freeing up drive space, forces one to re-create the "pseudo-duplicate" job, because removing a selection from the selection list simply excludes that selection - the job fails because (even though I am not trying to back it up) the folder that was "excluded" by un-checking it from the selection list no longer exists.

I can only assume that a normal backup job would have this same problem (since this is a normal backup job). If I create a selection list, then delete a folder from disk, then de-select that folder from my selection list, the job will fail with "invalid selection" because unchecking a box forces an exclude - it does not REMOVE the selection from the list.

What the?

[Ken_Putnam]

GRT jobs do not follow the same rules as standard B2D folders   see http://support.veritas.com/docs/286794  

basically, GRT jobs WILL  fill the hard drive either using all space or up to the reserve set for that b2d folder before they will overwrite existing GRT data (following OPP rules for the associated media set)

[Howard_Brown]

Alrighty then...

Following the document:

1. Establish B2D devices dedicated to GRT backup operations, separate from non-GRT backup operations.

Added a separate physical device with 500GB of storage. Partitioned it in two sections, one 186GB the other 300GB. Created a B2D folder for Sharepoint Portal Server on the 186GB partition. Created a B2D folder for Exchange on the 300GB Partition. These are both used EXCLUSIVELY for their respective GRT operations.

2. Avoid using the option to "Allocate the Maximum size for backup-to-disk file" for B2D devices dedicated for use in GRT backup operations.

I am not using pre-allocation on either B2D folder.

3. Avoid using a "disk space reserve" for B2D devices used in GRT backup operations unless overwriteable IMG folders will be available.

I did not configure any reserve on either partition.

4. Avoid filling up a drive that hosts a B2D device used in GRT backup operations unless overwriteable IMG folders will be available.

The full Exchange backup requires no more than 50GB (as of today). The Sharepoint backup requires no more than 10GB (as of today). I have confirmed that the job itself is configured to over-write, the media set is over-writable, and all the media is marked "Overwritable" when I look at the "devices" (the B2D folders).

5. Avoid running an Inventory job on a B2D device that has IMG media.

The failures occur during backups, not inventory jobs.

Both jobs fail, even though the Sharepoint partition is nowhere near full, with insufficient disk space errors. The Sharepoint job fails on the duplicate portion of the policy. The Exchange job does not duplicate, since Symantec has not as yet provided a fix for (yet another) bug with Exchange GRT Backups and duplicate jobs (whether by policy or stand-alone jobs).

Reclaiming Disk Space for Backup Operations

The following conditions will trigger a GRT backup operation to automatically reclaim space on a drive:

The drive containing the IMG media becomes full or the B2D disk space reserve has been met.
- AND -
IMG media has expired within the Media Set selected in the Backup Job.

Both of these conditions are met by my configuration in that:

1) The drive (partition) has become full.

2) The media is set to allow overwrite (Overwrite protection period is set to "none")

The Sharepoint B2D GRT Folder does not show "Low Disk Space", however, the following error was logged (the job failed to DUPLICATE to tape, because of "Low Disk Space"):

Job ended: Wednesday, May 09, 2007 at 5:13:22 AMCompleted status: FailedFinal error: 0xe000848f - Insufficient disk space.Final error category: Resource ErrorsFor additional information regarding this error refer to link V-79-57344-33935
The Exchange job also failed, with similar resource errors:

Job ended: Wednesday, May 09, 2007 at 2:20:01 AMCompleted status: FailedFinal error: 0xe000848f - Insufficient disk space.Final error category: Resource ErrorsFor additional information regarding this error refer to link V-79-57344-33935
Backup- \\host.domain.com\Microsoft Information Store\First Storage Group 
V-79-57344-33935 - The backup-to-disk folder that was specified for this job ran out of disk space. The backup set has been deleted, and the backup-to-disk folder has been paused.Either free some disk space, or specify a different backup-to-disk folder for the job. Before other jobs can use this folder, you must clear the Pause state. On the Devices view, right-click the folder and click Pause to remove the check mark.

Any better answers from somebody that is actually using this setup? Symantec KB articles are useless...

[kidputer]

This is the worst bug I have ever seen called a feature.
If you cannot delete the media, eventually it will fill up the drive even if you partition it and even if it is large.
I just wasted a week of my life trying to make space on a drive, even reformatted the drive, still Disk full error.
Fianlly I just uninstalled the software and reinstalled it, recreated all my backups, and here is the key, I backed up my database.
When the backup disk gets full just reformat the drive and restore the database, presto, bug fixed.
Oh and don't forget to rename your catalog folder to catalog.old
BTW-I hope they fix this bug soooooon because it is a real headache.

[dweb]

Howard,

Did you ever resolve this?  I am facing the same issue using GRT backups to local disk with Exchange.

Despite the availablity of overwritable media, and the job being configured to do so, it just won't do it.

David