Improve Backup to Disk Implementation
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.