I've used Backup Exec for years at numerous employers on numerous platforms, in both virtual and non-virtual environments, backing up everything from app servers to file servers, SQL servers to Exchange server, domain controllers and VM snapshots. I've used Backup Exec v7, v9, 2010, 2012, and 2014 across every major version of Windows Server from 2000 through 2012 R2.
Backup Exec is the monster I love to hate. When it works it works, but when it doesn't it's infuriating. On one hand I've seen it perfectly restore complex application servers to pre-crash states. On the other, I've seen it completely unable to perform the simplest tasks.
This article is NOT intended to be a rambling complaint. Instead, I am posting it as an official record of my own experiences with the product. The following issues are not isolated, but rather have been observed across many different platforms and clean installs, and are easily reproduced/encountered. Some are bugs. Others are just bad design. My hope is that the folks over at Veritas will take notice. At the very least, you may find you're not alone regarding one or more issues you've encountered yourself.
NOTE: Having said the above, it's possible that some issues are unique to my environment (that is, my network, my Active Directory domain, etc...). Many of these problems have been observed across domains, and all of them have been observed across multiple backup servers, but I won't rule out the possibility that some of these are unique to my domain (if that's possible).
JOB MONITOR FILTERS
Well this is an impressive list... I'm only 2 years into the backup world but my full time job exists of solving backup exec / netbackup issues so I have seen a LOT.
I can recognize alot of your problems already...
About this one:
You cannot perform granular Exchange restores from an incremental Exchange backup, even with GRT enabled. This seems to be a bug.
That only happens when you do GRT incremental to deduplication storage, this is not best practice accoring to Veritas. If it is actually a bug or not..I don't know. I can only confirm that if you do full GRT to dedupe and your incremental ones to regular B2D it works fine.
Please keep adding to this list and let's hope that Veritas notices :)
Thank you Bob, appreciate your perseverence and enthusiasm in listing the problems you are facing with Backup Exec. Just wanted you to know that we are looking at these and would be reaching out to you on these shortly, as we pick these up.
"Selecting ‘Do not run a delayed catalog operation’ suggests that a catalog operation won't be run. In fact, it merely ensures the catalog operation is run in parallel with the job itself. I understand the need to run the catalog, but this is a highly misleading option."
We are looking at how to reword and put it forth so that it is less confusing for the customers. At present I will be not able to commit on the release in which this will be fixed, but you should find this resolved shortly in the product.
Have you tried working with BE 15 FP4? Behavior of certain "Delayed Catalog" options have changed as below,
Do not run a delayed catalog operation. Instead, run a quick catalog operation as part of the backup job
Select this option if you want to run a quick catalog operation for GRT-enabled backup jobs.
If you select this option, the catalog operation runs as part of the backup job and collects only the minimum required catalog information.
You cannot use the Search wizard to search the backup sets for granular data. However, you can browse the backup sets. If you want to restore granular data from the backup sets, Backup Exec browses the backup sets for granular data as you browse for items that you want to restore. If you select this option, the time to browse granular data at the time of restore is slightly longer.
Delay the catalog operation and run a full catalog as a separate job immediately after a backup job finishes
Select this option to run the full catalog operation immediately after a backup job finishes. The catalog operation runs as a separate job. This option is the default setting for GRT-enabled backup jobs.
For Exchange and SharePoint Agent for Windows based backups, the full catalog operation runs immediately after all full backups. It runs once every 24 hours for all incremental backups and differential backups.
For Hyper-V and VMware backups, the full catalog operation runs immediately after all full, incremental, and differential backups.
Delay the catalog operation and run a full catalog as a separate job according to the following schedule
Select this option to run the full catalog operation as a separate, scheduled job. Then select the start time and the days of the week on which you want the full catalog operation to run.
If you schedule the full catalog operation, it runs only for the most recent backup set since the last catalog operation. In this situation, only the most recent backup set since the last catalog operation can be used for granular recovery.
"You cannot perform granular Exchange restores from an incremental Exchange backup, even with GRT enabled. This seems to be a bug."
This was a defect we discovered prior to BE 15 FP4, and depends on the "Delayed Catalog" option you had selected for the backup job and the timing of you trying to restore the incremental backup. If you had selected the option "Delay the full operation" and run the restore from the incremental backup job, this used to fail if the catalog operation didn't complete. This has been fixed in BE 15 FP4 and now you can restore from incremental backup jobs at all times post backup completion.
Thanks Again for the above list and I or somebody else from the team will respond back on the thread as and when we are able to resolve the issues listed here.
It appears this forum no longer allows you post updates to original postings, so here are four additional items I've been fighting with recently:
Bob I feel your pain!
I've used BE 2010 R3 (albeit very briefly) and am struggling to get 2016 working smoothly. Veritas Support seem to be utterly useless on the most part and incapable of accepting that the application has bugs.
Your list has given me some things to look out for though so thanks for your long-suffering vigilance!