Showing results for 
Search instead for 
Did you mean: 
Using a custom SQL instance with Backup Exec installs.


Oh, where do I has been a little while since my last post, and that is primarily because I volunteered for a new role within our department. My role now allows me to focus 100% of my time on issues that matter to you, and that is exactly what I have been doing since the beginning of the year! It is an awesome opportunity for me (and my peers who joined me), so that you will ultimately reap the benefits of our labor. I can say that there have been many long nights and weekends invested so far, and I know that the final results will yield many satisfied customers. That means more to me than you will ever know! It is the sole reason I volunteered, and it is what motivates me every day. Thank you for being a loyal customer!

So, part of my efforts recently led me to a topic which I have not covered before. That topic is using a custom SQL server instance with Backup Exec. We have supported it for many years now, but there are some impacts you should consider when using your own instance for the Backup Exec database. Let me list them and then I will elaborate further.

SQL Express Instance (BKUPEXEC)

Custom SQL Instance

Installed by the installer

Installed by the user

Upgraded by the installer

Maintained by the user

Memory limit set by installer

Memory set by the user

Network access configured by installer

Network access configured by user

Data paths are default and share same disk

Data paths set by the user

Backup of SQL files created by maintenance

Backup managed by the user.

Firewall rules added by installer

Firewall rules configured by the user.

Express database size limit (4GB currently)

DB limit dependent on SQL version used.

Patched via Windows Update

Patched by Windows Update

Secure folder by default

Default inheritance on folders


SQL Express Instance Installed by Backup Exec
As the chart above shows, the Backup Exec installation program does a significant amount of work to get the instance configured and setup for use. This is primarily to make the installation easy and simple. However, there are limitations to the performance set by Microsoft on the SQL Express instance. This is one of the main reasons why the Backup Exec installation program allows users to target a custom instance. The drawbacks to using a custom instance is that much of the work is left to the user to configure, manage, and patch the instance. When the Backup Exec installation program creates an instance, it uses (SERVERNAME\BKUPEXEC) where SERVERNAME is the name of your server. The installation program expects that this instance is ours and we will manage it. Your instance should be anything other than a local instance called BKUPEXEC.

Memory Limit Set by the Backup Exec installation program
I know that many times users have upgrade failures and support installs an instance like "BKUPEXEC1", then installs the product and targets that instance. The Backup Exec installation program expects that the user will maintain and manage this instance. I am afraid this information is not well understood by some of the support members, and is done merely as a workaround to get the product installed. The upside is that it gets the product working for the user, but there are consequences for that choice that may not be obvious. One such consequence is that the Backup Exec installation program will not set the memory limit for the instance, so the SQL instance is left to consume as much memory as it deems necessary. When the Backup Exec installation program configures an instance, the installer will configure the SQL maximum memory limit to 25% of the available RAM. User-defined instances are left to their default configuration, or user-defined configuration.

Windows Update Patching and Upgrades by the Installer
Patching will typically be done via Windows Update. In addition, upgrades for Backup Exec almost always ship with the latest version of SQL Express available at the time of release. The Backup Exec installation program embeds the latest SQL Express installation program which also includes any released service packs to date. When performing a Backup Exec upgrade, if the instance of "BKUPEXEC" is not at the current service pack revision, the Backup Exec installation program will upgrade the instance during the product upgrade.

The Backup Exec installation program has one view of the installed SQL instance. If the instance is on the local machine and is named "BKUPEXEC", then it is an instance we installed and we should manage it. If the instance is local with any other instance name, then the user created it and it is their responsibility to manage and maintain it. If the instance is on a remote server with any instance name, then it is also a user created instance and their responsibility to manage it. This includes upgrading the instance with service packs and security updates, etc.

Secure Folder by Default
When the user selected SQL instance is on the same server as Backup Exec, the Backup Exec database resides in our data folder. That data folder is ACL restricted to administrators, backup operators, and the system account only. There are security reasons behind this restriction. When the SQL instance exists on a remote server, the database file paths are managed by the user and should have their permissions restricted accordingly. Many times users have read permissions to these paths because of inheritance defaults from higher level directories. If users have access to the computer or these paths, it is recommended that you remove any user read access and simply limit it to administrators, backup operators and the system account only! The installation program also queries user-targeted SQL instances for the database paths. This is because some users will put the BEDB(MDF) on one disk, and Logs(LDF) on another disk for performance reasons. When using a remote SQL Server instance, the Backup Exec installation program will place the Backup Exec database files in those configured folders by default.

Database Size Limit (4GB)
SQL Express 2005(The current version with Backup Exec 2012) has a database size limit of 4GB. This is typically sufficient for a backup server that operates independently. However, if you are using the Central Administration Server Option (CASO) with Managed Backup Server, you may need better performance and a larger database to scale out. You may also want a larger database if you wish to retain more history than the defaults. In cases like these, a user-defined SQL instance may make sense.

Firewall Rules Added by Installer
When the Backup Exec installation program installs and configures a default instance, firewall rules will be automatically added for our SQL Express instance. If it is a user-defined instance, these rules are not added and if required, should be added by the user. These rules typically are required when running with the CASO and managed Backup Exec server option, and are not usually required without it.

As you can see, the Backup Exec installation program does a bunch of work for you, but there can be times when you want something different for a good reason. Such as a SQL Express 2008 instance, because it is your company standard, or you want performance gains obtained with SQL Server instance that is native on an x64 server. Whatever your reason, there are pro's and con's for choosing the non-default instance. I hope this blog offers some insight for customers who may ask themselves this question. If you have feedback for our team, we welcome it!




Hi Nick. Thank you for that article. It is an eye opener and educative. Much appreciated.

I have a couple questions that maybe you can help me with and are as follows:-

1. What is the best way to backup my BE database/server?

    a. What selections do I pick?  SQL Instance or database location folder, or both?

    b. Local db dump, then later backup by the BE application?

2. For Exchange 2010 server backup that has separate drives for the mail store and the logs (e.g. D:\ ; E:\)

   what is the best selection method to avoid redundant file backup. For examle, in the Selection Browse list, I am presented with the drives on which the logs and the db reside and also the Information Store option.

Do I need to select both the drives and the Information Store option or can I just select the db location and the logs location or vice versa?

I hope my questions are clear and make sense. Any advice is greatly appreciated. Thanks.

Hi Alex,

Good questions which we have seen before. I'll answer them the best I can.

1. What is the best way to backup my BE database/server?

​When backing up your server and database, you can create a new backup job by clicking the backup button. In the backup selections dialog select the check box next to your server in the list. This will put a check-mark next to all of the local disks, System State, Shadow Copy Components and SQL Databases on the local machine. Your Backup Exec Server license for will allow you to protect all of these these items on the local server.

Internally we will handle duplicate files while processing the file systems. For example, we know not to try to backup our SQL BEDB database as a file. We will instead back it up later in the job using our SQL agent. Because you are using our SQL agent, you do not need to dump the DB using SQL's tools to get a flat file for backup protection. Our SQL agent will back it up while the database is online.

2. For Exchange 2010 server backup that has separate drives for the mail store and the logs (e.g. D:\ ; E:\)

So, for Exchange 2010, you can use the steps above to select the entire server, but to specifically answer the question for your insight, this is what thinking will serve you the best, but uses the most disk/tape space.

You know that Exchange has a mail store on say D: and the logs lets say are on E:. You should select those disks to get any flat files that do not get protected by our Exchange Agent. In addition, you should also protect the Exchange stores via our Exchange Agent(Separate add-on license) to get any live/active data such as the online store and the active logs. In addition, you also need to backup the system drive for files that the Exchange installer put there(For Disaster Recovery purposes), as well as the System State for included Registry, COM components and Active Directory items.

Its best if you can always backup the entire server. When possible use our application agents for protecting SQL, Exchange, Sharepoint, Active Directory, etc. They will back up the data while in use. Without the agents you have to stop the applications services and protect those applications as regular files. This decreases uptime for those items and is unnecessary with our application agents.

I am assuming you do not have Exchange DAG's configured, but merely a simple installation. I hope this helps. Thank you for your question!


Hi Nick,


I've a client who has a 19GB SQL Database,

I've created a new full backup job.

after a few minutes sql backup completes with AOFO exceptions, however, the job size is only 2GB. 

is this ok.?




Hi Rogelio,

On its surface, I would say that 2GB of a 19GB file indicates a problem. However, this assumes a normal tape backup using our SQL agent. If you are using our DeDuplication option, and have backed it up before, this could be normal. Without more details, its difficult to say for sure. Our forums are a great resource for questions like this.

Hope this helps,

Hi Nick,

We are getting ready to migrate from a single stand alone 2010 media server to a CASO envrionment (one central admin server and a media server in DR. The servers will be able to see ech other. Can you provide guidance or provide a best practices document on migrating the existing SQL DB (custom instance) to the new envrionment please?

Is it just a matter of pointing both BUE servers to the exisitng SQL DB?

With respect to catalogs, I believe the replicated DB would be our best option.

Thanks for any best practices or procedures you can point me to.




Hi Rick,

I am working on a reply. I'll try to have that for you hopefully tomorrow. I want to check some of my facts before posting any information which could be inaccurate.


Many thanks Nick!

Hi Rick,

If Backup Exec is currently a stand-alone media server and you decide to extend it to be a part of a CASO/MMS (Central Admin Server Option/Managed Media Server) configuration, it is a simple install configuration change.

In the Backup Exec User Interface, there is an option under the tools menu to "Install options and licenses on this Backup Exec Server". Click that and the Backup Exec installer will launch. You will need to add a "Central Admin Server Option" (CAS) license, then click next and add (a checkbox) that option in the list of features to install dialog. This will be the server which will be the "Management" server for job administration, roll up reporting, etc.

To add any Managed Media Servers, to an existing "Central Admin Server" all you need to do is run the Backup Exec install and select the "Managed Media Server" (MMS) option checkbox. Then progress through the install until you get to the dialog that asks you where your existing CASO server is. Provide the NETBios name of the server and click next. The install will add this server as an MMS to the CASO for delegated jobs, etc. Once this completes you will be able to delegate jobs from your CAS to your MMS.

Your question also asks for best practices on setting up a disaster recovery site with CAS/MMS. So, there is a best practices document on this configuration here( This was the information I was waiting for from a colleague. Look for an upcoming blog from him on the subject as well.

Does this answer your quesitons?

Thanks Nick,

What I was looking for was a path to migrating from a single MMS to a new MMS and new  CASO server. I wanted to retire the exisiting MMS after migrating to the 2 new servers (one CASO & one MMS) both new DL380 G8's. I was looking for a best practices:

1. Prepare to move jobs from the exisiting MMS to the new envrionment.

2. Then point the new servers to the exisiting stand alone DB.(cutover and go live to the new envrionment)

The CASO server would live here in production and the new MMS server would be in DR.

Thanks Nick for any additional comments you may have.


Hi Rick,

I thought there was some underlying server migration questions in your original post. This helped me understand your goal much better. Thank you for the clarification.

So, this blog on server migration gives some best practice information about migrating an existing installation to a new server/hardware. That will help you get Backup Exec installed on the new server. Once that is done, then you will need to get the CAS option installed to make the server a central management server. Once you have that done, then you will run install on the other server and tell it to become a "Managed Media Server (MMS) using my steps above. This will get your servers into the CAS/MMS roles. Finally, your last step is to retarget your jobs to run on the MMS is so desired.

Now, if you are using DeDupliation and want to OpDupe between the CAS/MMS servers, then this document should dictate your configuration.

Hope this helps,

Hey Nick,

Thanks for the last posting. This is helpful and sets me on the right path. Much appreciated!

We currently backup to Exagrids and that's where the DeDuplication takes place so, we will not need to configure within BUE.

This definitely helps!


Thank you for sharing such a great article !

So I guess for the builtin BE SQL Express Database maintenance, the following option is the safest and optimal ?


Hi John,

I did not get notified about your question by the system, so let me give you a quick answer now that I have seen it! The product defaults are usually the best settings for many reasons. They get the most testing, and the engineers select them based on what should be the optimal experience for the customer. I do not understand what you mean by "Safest". If you mean least number of bugs, I would say yes due to the proportionate amount of testing the defaults receive. I hope this answers your question.

@Nick yes, that's what I'd like to know.

Thanks John, I will leave that as default.