My List of Problems With Backup Exec

Question

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.&nbsp; 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.&nbsp; When it works it works, but when it doesn't it's infuriating.&nbsp; On one hand I've seen it perfectly restore&nbsp;complex application&nbsp;servers to pre-crash states.&nbsp; On the other, I've seen it completely unable to perform the simplest tasks.

This article is NOT intended to be a rambling complaint.&nbsp; Instead, I am posting it as an official record of my own experiences with the product.&nbsp; The following issues are not isolated, but rather have been observed across many different platforms and clean installs, and are easily reproduced/encountered.&nbsp; Some are bugs.&nbsp; Others are just bad design.&nbsp; My hope is that the folks over at Veritas will take notice.&nbsp; At the very least, you may find you're not alone&nbsp;regarding&nbsp;one or more&nbsp;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...).&nbsp; 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).

&nbsp;

GENERAL

When modifying a backup job containing multiple target systems, even minor changes (such as job name or scheduling changes) often result in ‘Unable to create the Backup Items’, ‘The method Backup Items was called with invalid arguments’ error messages, forcing you to completely delete and recreate the backup job.&nbsp; This is unacceptable, and is half the reason I rarely group backups for different servers (if I can't update the job later then I'm only asking for trouble).
	Selecting ‘Do not run a delayed catalog operation’ suggests that a catalog operation won't be run.&nbsp; In fact, it merely ensures the catalog operation is run in parallel with the job itself.&nbsp;&nbsp;I understand the need to run the catalog, but this&nbsp;is a highly misleading option.
	VSS provider selections are poorly-implemented, especially in regards to&nbsp;Exchange backup jobs.&nbsp; When backing up (A) Exchange databases on (B) a virtual server, you must select ‘System – Use Microsoft Software Shadow Copy Provider’.&nbsp; If your server isn’t virtual, or if you’re backing up file system and System State data on a virtual server, you must select ‘Automatic – Allow VSS to select the snapshot provider’.&nbsp; This is an incredibly obscure setting that isn’t well-documented.&nbsp; The software knows the Exchange server is virtual, and it knows what I'm backing up.&nbsp; Why can't it just use that information to select the best VSS provider?
	The jobs don't offer nearly enough granular control over different resources.&nbsp; For instance, I can't set up one Exchange backup job to back up 5 databases in full, and another 3 as incrementals.&nbsp; It's all or nothing.&nbsp; Added flexibility in the job design would be nice.

JOB MONITOR FILTERS

Filters are a good idea, but they inevitably disappear without any explanation.&nbsp; This happens on both servers and client-side installations.
	The filters are poorly designed insofar as their categorization options.&nbsp; For instance,&nbsp;you can build a filter to show you either&nbsp;(A) active or&nbsp;(B) pending backup jobs, but you can't build one filter to show you both.

MICROSOFT EXCHANGE

You cannot perform granular Exchange restores from an incremental Exchange backup, even with GRT enabled.&nbsp; This seems to be a bug. [NOTE: Per comments added to this thread below, it has been pointed out that incremental GRT backups are not supported when using deduplication, but for B2D backups they should work fine. &nbsp;In my environment, while (A) I can verify that they do work when run against B2D storage devices, the (B) GRT process&nbsp;operation often fails for one or more database, rendering those emails non-restorable from a GRT standpoint, and thus rendering the GRT function itself useless. &nbsp;After observing this over a long period of time in my environment, my best estimates are that while incremental GRT backups to B2D fail the GRT processing phase for between 40%-50% fo the databases backed up, whereas the failure rate drops to aroung 10% of databases when those same backup jobs are switched from incremental to full.]
	Incremental Exchange backups often hang backup jobs, specifically in regards to the cataloging operation.
	There are no safeguards in place to prevent two jobs from backing up the same Exchange database at the same time.&nbsp; While not a bug, this would be a welcome improvement.
	Exchange backup jobs often report as having completed successfully, but examination of the job logs shows that one or more backup selections were not processed for GRT.&nbsp; Why do the jobs report a successful completion if the GRT aspect failed?
	The option to use the search function to find objects backed up as part of an Exchange GRT backup&nbsp;(versus manually navigating databases/mailboxes/etc...) is not present after cataloging old media. &nbsp;Not sure if this is a limit tied to data restores from tape versus hard drives, or if it is related to reintroducing old media and cataloging.
	The Exchange search options are not very useful. &nbsp;You can search for message title, size, and modified time (I assume this is the date/time the message was created), but you cannot search for things like recipients (TO, CC, BCC), sender, or message body. &nbsp;As a result, finding that one email lost amidst tens of thousands can become a very tedious task. &nbsp;Expanding on the current search options would be a welcome addition.

SCHEDULING

Every incremental/differential job must be directly tied to a corresponding full job.&nbsp; This robs you of tremendous flexibility when it comes to running a full backup once a week, with multiple incremental backups on multiple schedules throughout the week.&nbsp; It also means that if you want to back up a specific piece of data on a server you must back it up fully and incrementally/differentially outside of the usual backup job.
	No way to link backup jobs outside of some fancy PowerShell commands, and even then, the GUI doesn’t indicate that the jobs are linked.&nbsp; The app does a great job of visualizing different stages of a single job, but it would be great if it included the ability to link completely unrelated jobs and present this visually as well.

DUPLICATION

LTO duplication jobs behave very erratically. &nbsp;Consider the following scenario: You have a tape library with three tapes (let's call them tapes A, B, and C). &nbsp;Each tape has been partially written-to but still has plenty of free space, and each is still appendable. &nbsp;Your goal is to copy the data off tape C over to either tape A or tape B, in order to consolidate data and use fewer tapes for that particular backup set. &nbsp;You browse the backup sets on tape C, highlight all the entries, then right-click and choose the duplication option. &nbsp;[PROBLEM 1] - Backup Exec doesn't allow you to target a specific LTO tape as the destination. &nbsp;Alright, I'll admit&nbsp;this is more of an annoyance than a problem, but it still complicates the ordeal and leads directly into...[PROBLEM 2] - Backup Exec will load the source tape, but then it might grab *ANY* tape as the target tape. &nbsp;So you don't know if your backups are going to be written to tape A or tape B. &nbsp;Worse, it *MIGHT* even be written to another tape, possibly one not written to at all, even when you've told the job to append to an existing tape first. &nbsp;This logic results in lots of wasted tape space.

DEDUPLICATION

There's no way to enable client-side deduplication on a single job containing multiple servers.&nbsp; To use client-side deduplication you must separate every server into its own job.
	Deduplication databases have a habit of not mounting after reboots, forcing numerous service stops/restarts, each of which can take 30-40 minutes.&nbsp; Or they don’t mount at all.&nbsp; Either way, this introduces huge amounts of downtime during something as simple as a reboot.&nbsp; For those of you thinking the database or the backup server must be bad, I have observed this over several years across multiple backup servers and numerous deduplication databases.
	Client-side deduplication works intermittently at best.&nbsp; A job may utilize client-side deduplication one day, then fail the next, then run successfully the day after that.&nbsp; Veritas techs have told me to just use server-side deduplication, since client-side deduplication doesn't do much anyway and the errors aren't worth the effort, but if this is the case why does the app offer client-side dedup at all?
	After importing an old deduplication database, you cannot write to it.&nbsp; All you can do is read from it.&nbsp; Why?&nbsp; Does this mean every time you build a new backup server and migrate a deduplication database you have to start building a new database from scratch?&nbsp; That's a huge waste of space that some admins can't afford. &nbsp;Not only that, but because Backup Exec only allows you to have one deduplication database at a time, the act of importing an old database shoots you in the foot, preventing you from backing up to a new deduplication database while you reference an old database.

RESTORES

After cataloging old media, the old server name appears in the ‘Backup and Restore’ server list.&nbsp; However, you cannot initiate restores from here - the option is present but it's grayed-out.&nbsp; Instead, you must manually browse to the loaded media, find the backup set in question, and perform a restore from there.&nbsp; It makes no sense to add the server into the server list if you can’t use it, especially since when I'm done restoring I have to go in there and blow away the server anyway.&nbsp; It's a useless feature that adds more work and can lead you to believe you can't restore the server at all.
	The Exchange GRT search function is only available when you right-click a server from the server list page and perform a restore from there. &nbsp;If you right-click the backup media itself (a must if you've recently cataloged old media), the search function doesn't exist.
	Backup Exec provides no way of restoring Exchange mailbox data directly to a PST file. &nbsp;The only way to do this is to install the backup agent to a client system (probably a PC) with a copy of Outlook, adding the system into your servers list, then perform a restore from Exchange to that client system. &nbsp;Not only does this mean you need a secondary PC in play to achieve the export, but the requirements that the version of Outlook be 2010 or earlier means that you need a specific PC. &nbsp;In my case, my team of techs have Outlook 2010, 2013, and 2013, depending on which tech you're talking about, and that means my 2010 tech is the only person whose PC supports this function. &nbsp;So every time I restore to PST I have to make sure he's around and plugged in, with no intention of rebooting any time soon or leaving the office. &nbsp;It's stupid to have to involve any client PC in the first place, but to further limit us by restricting versions of Outlook is insane.

SERVICES

Backup Exec services don’t always start properly.&nbsp; Often you must configure them for a delayed start.&nbsp; This has been observed across multiple backup servers and multiple clean installs of Backup Exec.&nbsp; Oddly, this problem rarely arises immediately upon install, so there may be mitigating factors.

STORAGE DEVICES

Pending jobs claim available read operations against disk storage.&nbsp; For instance, let's say you have a 1 tape drive and 1 B2D store.&nbsp; The B2D store allows 4 read/write operations at a time.&nbsp; Now let's say you have 5 jobs queued up to copy data from the tape drive to the B2D store.&nbsp; You'd think that since you have just 1 tape drive, you'd only use up 1 of your read/write operations, allowing Backup Exec to run other jobs against the B2D store in the meantime.&nbsp; You'd be wrong.&nbsp; Instead, Backup Exec eats up all 4 of the read/write operations for the B2D store, claiming each for one of the pending tape-to-B2D jobs, even though only 1 can run at a time because you only have 1 tape drive.&nbsp; This bottlenecks all your other jobs.&nbsp; Admittedly this is probably a rare circumstance, but in my environment I have to copy data from tapes to a B2D store, and the read/write limits combined with Backup Exec's poor way to reserving the operations means that all my other jobs just sit there waiting until the tape drive finishes its jobs first.
	Backup Exec only allows you to create one B2D storage device per drive letter. &nbsp;This is a rediculous limitation.

LICENSING

When inputting new license keys into the software, the license count doesn’t appear next to the product name.&nbsp; Instead, you must proceed to the next screen of the wizard, then use the Back button to return to the first page.&nbsp; Only then can you verify that the new license keys incorporated the correct counts.&nbsp; This is just sloppy.&nbsp; If the wizard can immediately detect the new license types based on the key, it should be able to detect the count as well.&nbsp; Instead, it makes you think your keys are bad unless you happen to go back in the wizard after you've proceeded to the next step.
	License counts can easily get screwed up, even when you’re adding the proper keys.&nbsp; Backup servers can 'lose' licenses for no good reason.&nbsp; This is more common during upgrades, but it should never happen at all.

BACKUP AGENTS

Remote agents will occasionally become unresponsive, resulting in failed backup jobs.
	When backing up Exchange databases directly to LTO tapes, jobs will report as failed better than 90% of the time, resulting from a disconnect between the Backup Exec server and the remote agent.&nbsp; However, the job itself seems fine and the data is restorable.&nbsp; Backing up Exchange databases to non-LTO mediums don’t result in these errors.

bob_gruett · Answer

Just realized I can edit my original posting instead of adding to it. &nbsp;I will continue to do this in lieu of adding new comments as I remember/encounter more problems with the software.

maurijo · Answer

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...

&nbsp;

About this one:

You cannot perform granular Exchange restores from an incremental Exchange backup, even with GRT enabled.&nbsp; 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.

&nbsp;

Please keep adding to this list and let's hope that Veritas notices :)

amrish_be_pm · Answer

Thank you Bob, appreciate your perseverence and enthusiasm in&nbsp;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.

Regarding,

&nbsp;"Selecting ‘Do not run a delayed catalog operation’ suggests that a catalog operation won't be run.&nbsp; In fact, it merely ensures the catalog operation is run in parallel with the job itself.&nbsp;&nbsp;I understand the need to run the catalog, but this&nbsp;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&nbsp;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.&nbsp;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.&nbsp;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.

Note:

Before the full catalog operation completes, instead of using the Search wizard, you must browse the backup sets to select the individual items that you want to restore. The Search wizard is available after the full catalog job is complete.

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.

Note:

Before the full catalog operation completes, instead of using the Search wizard, you must browse the backup sets to select the individual items that you want to restore. The Search wizard is available after the full catalog job is complete.

&nbsp;

Regarding,

"You cannot perform granular Exchange restores from an incremental Exchange backup, even with GRT enabled.&nbsp; 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.

- Amrish

bob_gruett · Answer

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:

BACKUPS/RESTORES

When creating any backup job using the job wizard, Backup Exec is very good about not letting you give a new job the same name as an existing job. &nbsp;In fact, if you try you'll get some red text telling you that's not allowed, which is good because you're prevented from causing a problem and you're also informed as to why. &nbsp;However, if you create a duplication job by navigating to a media set, right-clicking and selecting the Duplicate option, you don't get the wizard. &nbsp;Instead, all you get is a single window containing some basic job properties such as job name, schedule, verification, target media, etc... &nbsp;In this case if you give a new job the same name as an existing job, you [A] don't get a proactive warning at all, and [B] when you attempt to click OK to submit the new job you get the very cryptic "Unable to insert the {0}", "Unknown reason: {0}" error. &nbsp;The problem here is that&nbsp;the error tells you nothing useful, and even if you DO know what it means, then if you rename the job you still run the risk of getting the error again because you have no way of knowing if the new job name is also taken (unlikely I know, but still a possibility).
	When backing up a VM, Backup Exec throws up a window recommending that you back up the target system by means of the VMware/ESX/Hyper-V host system. &nbsp;However, in order to retain the ability to granularly restore files/folders, the target system's drives must all support GRT. &nbsp;The problem is that Backup Exec doesn't check this proactively, and instead only tells you this after a job completes with exceptions. &nbsp;If Backup Exec is going to be so pushy about using this feature, then the app should at least scan the target drives to ensure the server in question supports this feature with full GRT.
	When backing up a system by means of the Windows agent, you can later run a restore targeting files, folders, and System State data. &nbsp;However, when backing up a system by means of the VMware/ESX/Hyper-V host system, then even if you have GRT enabled you cannot perform a restore of any System State data. &nbsp;While I won't get into why this is such a poor design here, I will say that Backup Exec's refusal to warn you about this is unacceptable. &nbsp;If Backup Exec is going to give me two different methods of backing up a system (and especially if it pushes one method over the other), then it better also give me absolutely clarity in terms of what restore features might not be available for either option.&nbsp; The last thing I need is to take the app's recommendation and start backing up entire VM snapshots, and then discover I can't restore a registry.

&nbsp;

DUPLICATION

A file/folder restore of a system which was backed up by means of the VMware/ESX/Hyper-V host with GRT enabled requires that the Windows agent be installed on the target system ahead of time. &nbsp;This isn't a big deal, but it's not documented anywhere, and the fact that VM GRT backups can be taken without an agent may lead an administrator to be surprised when he/she can't restore the granular data without also installing another piece of software. &nbsp;Not really a problem, but some proactive warnings about this might not be a bad idea within the application.

dca-it · Answer

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!

Forum Discussion

My List of Problems With Backup Exec

Related Content

Backup Exec 2015 - List of revisions

.VMX files not listed when creating backup list using VMware agent

Backup Exec 16 SDR problem

Server List Not Refreshing in Backup Exec 15

Need to remove old server from backup list.