The Size of Backup to Disk Files are Stunted.

[BernardJL]

After running Backup Exec 2010 R2 with all fixes applied for some time, we have noticed that the backup to disk files are identified as "full" even if they are not anywhere near their maximum size.  We are ending up with backup's that span 10 or more "bkf" files when the backup to disk folder has plenty of space.  Any one of them could have been expanded to hold the complete backup.

So what is going on here?  Is there some parameter we are missing?

Here is the operational data:

A backup to disk folder:  "Folder D"

Maximum size for backup-to-disk files:  100GB

Maximum number of backup sets per backup-to-disk file:  1

Low space threshold:  2GB

We ran a backup of a small machine to backup:  Drive C; Shadow Copy Components; and System State.  It ended up using the following files:

B2D001895 - Contains: Shadow Copy Components and C: - Used 1.2GB / Total Capacity 89.7GB 

B2D007009 - Contains: System State / Shadow Copy Components - Used 26.6MB / Total Capacity: 2.0GB

B2D007010 - Contains:  System State - Used 12.4GB / Total Capacity 14.1GB

B2D007011 - Contain:  System State - Used 1.0 GB / Total Capacity 3.0GB

B2D007013 - Contains:  System State - Used 8.6GB / Total Capacity 10.6GB

B2D000093 - Contains:  System State - Used 609.6MB / Total Capacity 2.4GB

So what is going on here? 

-- Why are these files showing a wide range of sizes?

---This complete backup could have fit into one file since we have set the maximum to 100GB. 

---Do the backup-to-disk files somehow keep the size they had when first written to?

---What to do about this?  If they keep getting smaller each time we use them we are heading to a real problem.

---Making every backup-to-disk file allocate its maximum size would be a waste of disk space.

Any help or advice would be greatly appreciated.  We have tried to look at the forums and knowledge base but nothing seems to be related to this development.  Thanks in advance.

[Ken_Putnam · Accepted solution]

Maximum number of backup sets per backup-to-disk file:  1

In BackupExec speak, a "backup set" is one volume, or one database or one share.  Set this parameter up a ways, say 10 or 20 and the BKF files should fill up before creating a new one

[BernardJL]

Ken, thanks so much for the quick response.  We will give that a try to see what happens.

We had set the number to one because as you noted that would put "one volume or one database or one share" in each folder. 

So in the example backup we gave, we were backing up three things: " Drive C", "System State", and"Shadow Copy Components".  So our thinking was that would be at most three files.  It is not clear to us why it broke apart the "System State" and placed it in those other files. 

In any event, we will take your advice increase the number of backup sets per file and see what happens.

Thanks again for the quick response.

[BernardJL]

Ken, we have had one day of implementing your change and we did notice that the backup jobs were now contained in one "B2D" file.  So it looks like what we were seeing was that there are more "backup sets" in one job than we thought.  So that lead to multiple "B2D" files being created of small size.

While you are on a roll perhaps you can clarify a point for us on these "B2D" files. 

Will allowing multiple backup sets per file create a situation where other backup jobs could be added to the same file? 

We did not want overlap, as it were, where "Job A" uses the file and then "Job B" adds to that file.  We have set our "Append Period" to zero on the media sets we are using hopefully to prevent this.

Your thoughts are appreciated.

[Ken_Putnam]

Will allowing multiple backup sets per file create a situation where other backup jobs could be added to the same file?

Only if the job uses the same media set as the one already on/in the BKF file

We have set our "Append Period" to zero on the media sets we are using hopefully to prevent this.

In this case, even if the second job does use the same media set, a new BKF file will be created when the second job starts

[BernardJL]

Ken, thanks for that quick clarification.  It looks like we are on the road to recovery.

We really appreciate you sharing your knowledge and hope we are able to return the favor some day.

Thanks