On Monday, February 21st, I posted a blog about Backup Strategies for File Servers and Exchange Servers. Here’s my first follow on post based on my experience with Backup Exec 2010 R2. This is not a super detailed “review”, but my first impressions of the product in my test environment.
Overall, I like Backup Exec 2010 R2. It is fairly simple to use. I’m pretty sure this product works very well in the SMB space and even in the larger companies where there isn’t massive complexity. One of the things I didn’t spend time on, but looked interesting was the ability to create backup policies that helped to configure a full backup policy that makes it easy to perform a set of tasks such as Full Backup once a week, Differentials for the rest of the week, Full backup on the last day of the month, rotate media, etc.
I setup my test environment with one Domain Controller and one Exchange 2010 Server. I wanted to configure Backup Exec 2010 R2 to backup data on the Domain Controller (treating it like a file server) and to back up the Exchange 2010 Server. Before I installed the trial edition, I thought I would have a quick chat with a sales person at Symantec so I knew what options I would need (even though the trial enables everything). I explained to the sales rep that I was going to install Backup Exec 2010 on a dedicated Backup Server and then remotely backup the File Server and the Exchange 2010 Server. Then I asked, “What would I need to purchase in order to accomplish this?” According to the sales rep via a chat session, I needed one license of Backup Exec, one Windows Server Agent and one Exchange Backup Agent.
In my test environment, I could not select anything on the remote server if I did not install the Remote Agent to the remote server. I’m not sure if that is something that I need to license separately, but I will have to confirm with someone who really knows the product better than me.
Either way, the installation of Backup Exec 2010 R2 (BE2010) was very straight forward. Since I didn’t already have SQL on my server, the installation automatically installed SQL Server 2005 Express (not sure why it doesn’t install SQL Server 2008 Express or even R2). After installation, I created some folder structures on my hard drive as shown below.
I thought it would make sense to separate the backups of the file data from the Exchange database and I separated out the full backup from the differential backups.
Backup To Disk Folder (Device Configuration)
In BE2010, I created a Backup to Disk Folder using the Wizard.
The first option allowed me to allocate the maximum size for the files or not. In other words, do I immediately create a 4 GB file (as an example) or start small and allow it to grow as needed. This option is similar to creating a VHD in Hyper-V as dynamic or fixed. For my test, I accepted the default of “No”. I would think performance would be better to immediately allocate the file, but it was hard to test in my lab since I had such small backups.
The second option allowed me to set the maximum size of the backup files. To me, it would make more sense to present me with this option before the previous one, but oh well. The wizard defaults to 4 GB and so I left it at that. In a production environment, I would evaluate the size of my backups and then set this accordingly.
For the third option, I am asked to set the maximum number of backup sets. This defaults to 100, but I changed it to 30. I’m guessing for larger environments, this setting will actually be important. For my lab where I created distinct folders for each data type and the fact that I only have Exchange Server, I don’t think this will have much of an impact for me.
For the maximum number of concurrent jobs, the default is 1, but I changed to 3 (figured I would test this later). Once again, since I chose to separate data types apart in each folder, I would only be performing one backup job to this folder at any given time.
The Low Disk Space Threshold setting defaults to zero which means this option is disabled. If I set this to any other number, the Folder would be suspended from being used once the available disk space reached the number specified. I tested this out by changing this to be just under the maximum available and ran a backup job. The job started, but then was suspended the moment the available disk space threshold was reached. So long as I freed up space shortly after, I was able to resume the backup job. However, for fun, I left it alone for a day before clearing up space and the backup job failed to resume from suspend mode.
Before the folder was created in BE2010, I got the final summary screen and had to click next to finish creating the folder.
The next piece in the process was creating a Selection List for what I wanted to backup as it related to Exchange. I selected the database on my Exchange Server (PHX-MBX-101). I wish there was an easier way to select a remote server versus “walking” the AD tree. This process was slow and took about 4 minutes from the time I clicked on PHX-MBX-101 before the tool refreshed and gave me the option to select the database on the server.
I then created a backup job to back up my Exchange Server. I didn’t like the way the Wizard presented me options, so I opted to create the backup job manually. The process is straight forward in that I chose the Exchange Database Selection, selected the Device and Media, set the options specific to Exchange backups and set the backup schedule. I included the below screen shots that shows the Exchange specific settings as I want to point out that the Exchange Settings defaults to using Backup Exec GRT to enable restoring of individual mailboxes. I left this on, but did also test with this option off. I will go into that a bit more later in this post.
I went ahead and created a job for performing a Full Data Backup as well so that I could run multiple jobs at the same time. I then forced both jobs to run immediately.
The results of the two backup jobs are shown below.
Notice that the job rate for the Exchange backup was considerably slower than the job rate for the file backup. I then deselected the GRT option in the Exchange Settings and reran the Exchange Backup job. Without this option selected, the job rate was five times higher and the size of the backup was also smaller.
In my test environment, the database was quite small so it really doesn’t make a difference one way or another. In a production environment, I would have to evaluate the value of having individual mailbox recovery over size and speed of backup. To verify, I initiated a restore job to see what was selectable from an Exchange restore and you can see below that the backup with the GRT option enabled allows me to restore individual mailboxes versus the entire database. In fact, I can get as granular as an individual folder within the mailbox. Pretty nice feature so long as the size of the backup and the speed is within my tolerance.