Video Screencast Help

Improve Backup to Disk Implementation

Created: 08 Mar 2011 | 6 comments
BernardJL's picture
1 Agree
0 Disagree
+1 1 Vote
Login to vote

One of the recurring problems we are always facing with Backup Exec (2010 R2) is the way :"backup-to-disk" files and folders are handled.

Here are the features we would like to see improved:

1.  Have the ability to switch to another "backup-to-disk" device when the current device in the pool is full.

Currently, we have backup jobs fail when free space goes below the threshold.  We get the incessant "please insert more media" messages all night long.  And it does not even tell us which "backup-to-disk" folder has the problem.  The same pool has another folder with plenty of space on it.  Why not close/update the current file and open media on another device? 

2.  Have the ability to select a "backup-to-disk" device based on the amount of free space.

Currently, there is a defined algorithm for using/re-using files based on "scratch media" vs "over-writable".  The algorithm should easily be able to determine the "backup-to-disk" folder with the most space, and then go through its routine to select a file or create a new file.  This would also alleviated the problem you have in point one above.

3.  Improve the restore selection tools.  Add a "search for file" feature.

When doing incremental backups, and asked to restore a particular file, it can take hours.  It appears you must work your way backwards to locate the newest backup of the file.  With the database back-end you have, why can't there be a search function to look for a particular file and show what media and what date that file was backed up. 

4.  Improve the way "backup-to-disk" files are cataloged/indexed.

One of the frustrating things about "backup-to-disk" is the seemly overly complex process necessary to move the actual data to another location.  This is more common than you think.  Adding a new larger disk for a "backup-to-disk" device should be as simple as copying the "B2D" files.  Instead the basic answer given is you can't do it, and at best you can try some detailed process to do it.  Even worse is that you cannot copy B2D files from an older backup disk and add it to another one.  Your knowledge base articles gives many reasons why this is so.  But these are disk files and moving them should not be such a project.

You have a nice product, but having these simple issues over time, have reduced the value proposition of your product.  Hopefully, these will addressed in a forthcoming release.

Comments 6 CommentsJump to latest comment

pkh's picture

1.  Have the ability to switch to another "backup-to-disk" device when the current device in the pool is full.

Currently, you have this capability.  Click on the Advanced tab in the B2D folder properties and then enable the low disk space threshold and BE will span to the next device in the pool

Login to vote
BernardJL's picture

pkh, thanks for the response. 

We do use the "low disk space threshold" on all of our "backup-to-disk" folders.

You are correct to a point.  Just about every other day we get the message "Please insert over-writable media into the robotic library using the import command."

All of our backups are to "backup-to-disk-folders" that are contained in a pool.  We do not have a "robotic library". 

Symantec tells us this is because we ran out of space during a backup operation to one of the "backup-to-disk" folders.  They said once a backup starts on a device it will not close the file and move to another folder.

In particular, backup jobs that create an "IMG" file, like for the granular backup of our exchange mail stores.  These will not move to another folder even if the space on the current folder hits the low threshold. 

Like yourself we expected the process to work exactly as you describe.  However, it appears not to work that way under all conditions.

Again, thanks for feedback it is appreciated.

Login to vote
pkh's picture

I am not sure about "img" files, but it definitely work for .bkf files.  The job just create a .bkf file in the next B2D folder in the pool and continue.

Login to vote
Colin Weaver's picture

For information if your backup to disk contains GRT selections (so creates an IMG folder instead of BKF files) then this cannot span. An IMG folder would contain files such as an Exchange EDB file or VMware VMDK files and these have to be directly mountable (by a Backup Exec Process) for individual file/item restore purposes - so cannot be split across locations.

A BKF file is basicially a file based container for the MTF format so can span - but can't provide GRT functionality.

A tape provides GRT fuinctionality by re-assembling the IMG folder in a temporary staging area, however if we did this with BKF files a) it would slow the on disk restore down and b) the disk space requirements would increase.

Login to vote
BernardJL's picture

Colin, thanks for the response, we apppreciate it.

You comment underscores what we were thinking was the issue for these IMG files.  We use the "Granular Recovery Technology" (GRT) when doing a backup of our Exchange information store.  This allows us to recover individual mailboxes or items.  And that leads to the disk space allocation issue.

The design of GRT leads to the limitations you outlined and we noted earlier. 

However, there are other ways that this functionality could be implemented to get around these limits. 

Perhaps Backup Exec continues forward with a old paradigm on the design grounded in their legacy of tape functionality. 

As you pointed out, with a physical tape the GRT function is provided by re-assembling the image on the disk. 

In the case of a backup to disk,  the files are already on disk. Even if they were spread across folders, it would be possible to not move the data but create a virtual IMG file that maps over the volumes.  Not only would that remove the limitations, it might even improve restore performance since the data is not confined to one drive.

That's just one idea based on your comments.  I am sure the Symantec design team could come up with a more elegant solution given different design goals and paradigm.

We hope that Symantec and the Backup Exec team will provide an improved solution for disk media characteristics (random access, modifiable, etc.) as opposed tap media characteristics (sequence access, non-modifiable, etc.)

Thanks again, for your comments, we appreciate the time you took to help us out.

Login to vote
BernardJL's picture

We have been in a state getting Backup Exec 2012 up and running.  This new version has removed a number of useful features.

As this thread indicates the previous versions of Backup Exec will move to another device in a "backup to disk" folder pool if the current device becomes full.

But Backup Exec 2012 will NOT do this. 

Per our support case we had, Symantec informed us Backup Exec 2012 will NOT use another folder even if the current "backup to disk" folder is full and there is more room on another drive.  The job will stall, request more media and that is the end of that backup job.

Losing this feature has now caused us the added expense of purchasing addition disk space to provide the necessary "pad" to reduce this issue.

In addition, Symantec indicates we should consider NOT USING a "backup to disk" pool but to direct backup jobs to specific folders.

This leads to: a) More intervention by our administrators and b) wasting backup disk resources.

At this point be sure to consider the cost impact of implementing Backup Exec 2012.

Login to vote