GRT Backup to Disk retention has been odd previously.  On 11D7170 the IMG folders would not start to be overwritten until the drive was out of space.  We skipped 12 and went to 12.5, so if you are using 12 I do not know how it acts but I know it works correctly in 12.5. 

Which version of BE are you currently running?

Hello,

This KB might be very helpful to you...

http://support.veritas.com/docs/286794
Granular Restore Technology (GRT) used with a Backup-to-Disk (B2D) device results in the disk or the reserved disk space being filled up with overwriteable image (IMG) folders before the oldest IMG media will be overwritten

Hope this helps...

 Hi Guys, thank you for replies!

@Lively: I have 12.5 but from its behaviour it seems that the rule "overwrite only on disk full condition" is yet on.. Do you confirm me that on your system IMG supports are overwritten without the full disk condition reached?

@Dev T: I've already read that kb.. I had not any of these condition except the one where it says to avoid putting in the same disk device GRT backups with others backups.. I have an unique job that backups data and Exchange.. So the destination is unique..

I have received a mail from Symantec for the free update to BE 2010... Do you suggest to update?

Thank you again!

Francesco

The later versions of GRT try to erase at least one IMG at the start of every backup set that might start a new IMG. Obviously they can ONLY erase an IMG if it's overwrite protection has been exceeded, but a) the erase does not have to wait for the disk to fill and b) the same IMG name is not reused a new one is created.

Older versions of BackuP Exec did need the disk (or the idks reservation to fill.

Bear in mind that if you backup an Exchange server  with 3 information stores and a Virtual Machine and A domian Controller (all with GRT enabled) that it will create 4 IMG folders not  one.

Also be aware that overwrite protection is taken form end of job so if you set 7 days and expect it to be overwritable and a job with a weekly restart time then it won't be as you have to take into account the length of time the job takes. But by the time you come in the next morning it will be overwritable so it looks puzzling when you try and work out what caused a job to not use (or not remove) a piece of media

Also, look at the Global Overwrite Protection setting

Tools\Options\Media Management

verify that the setting for "Use Overwriteable media in the target media set before scratch media" is selected not "use scratch media  before ..."

This seems to be a massive software limitation.

After going through this for days with Symantec Enterprise Support (who basically ruined our configuration in the process), we were finally told to refer to this: http://seer.entsupport.symantec.com/docs/276904.htm
This is a complete joke.
Solution 1 - with our GFS rotation, we will run out of drive letters, solution 2 - who wants to mount the disks every time you change them? Poor pathetic software development IMO.

I am escalating to customer service as my client wants their money back, as we both agree this functionality is basic.

Apparently we must be so bleeding edge, what with wanting to backup Hyper-V guests, MS Exchange, etc. to an external disk.  I've certainly had no issues doing this with competitors products, but seems to be all too hard for Symantec.

In the meantime, I will have to write a script to delete old IMG folders manually each time a backup is run.  I was under the impression that by spending thousands licensing an enterprise backup product, I wouldn't have to code just to get it to work, or manually intervene every day.

In my experience, the IMG folders NEVER get overwritten, when when the disk is full.

For those who want to work around this ridiculous system limitation, here is the code I concocted in VBScript:

Option Explicit

Const intDaysOld = 2
Dim objFSO : Set objFSO = CreateObject("Scripting.FileSystemObject")
Dim objFolder : Set objFolder = objFSO.GetFolder("F:\")
Dim objSubFolder
For Each objSubFolder In objFolder.SubFolders

If objSubFolder.Name <> ("VERITAS") and objSubFolder.Name <> ("TEMP") and objSubFolder.Name <> ("$RECYCLE.BIN") and objSubFolder.Name <> ("System Volume Information") Then
If DateValue(objSubFolder.DateLastModified) < DateValue(Now() - intDaysOld) Then
objSubFolder.Delete True
'WScript.Echo objSubFolder.Name
'WScript.Echo objSubFolder.DateLastModified
End If
End If
Next

There may be more elegant ways to do this, but I couldn't be bothered.  Please note this will delete any folder older than 2 days on your disk. Adjust to your requirements.

For info - smartinet-sm's issue with removable Disks and IMG folders may not be the same issue as the original poster of the problem (who does not mention removable IMG) As such my description of how IMG erase should work in the later  versions of Backup Exec is valid - but may not be valid with removable B2D locations.

Hi guys.. After several months I have been trying (sorry for eventually bad english syntax-verb forms, I'm italian) this backup software I can say I'm NOT satisfied at all.. It's much graphically simple and intuitive as not functional and stable!! It works well just with tapes. The b2d functionality it's been developed with... feet!! To have a security copy of backups I worked around with manual duplicates! I'm really exhaust  from illogical errors, IMG folders problems and so on!! There's another post of mine about another IMG error issue!! Moreover.. IMG auto-deletion after disk full, or threshold (set by me to rightly avoid 0 free space on my storage!) reached, works one time each ten!!! Other nine times exits with a insufficient disk space error (but WHERE??? Not true at all!)!!!

Once again Symantec has disappointed me at all!! Since I'm under maintenance agreement I can upgrade to BE 2010 but as we use to say here in Italy... I would not fall from the pan to a coal!!!

Sorry for this polemic post but after moths of head-against-walls this is lecit!!!