Posted by: David | October 19, 2011

Backup Exec Best Practices for getting Reliable backups

Any Sys-Admin worth their salt should understand the importance of backups. Within the last 10 years of working in the industry I have come across a multitude of backup products some good some aweful however the one I have probably come across the most is Backup Exec.

Currently on Version 2010, Backup Exec is from my experience one of the most widely used products in the SMB sector. However its not without its nuances. I have put together this post to share my experiences of the product and what I deem to be the best way to configure your backups to ensure that your backups are reliable a easy to troubleshoot.

The most common mistake (in my mind) I see when it comes to the configuration of this product what I like to call “The One Job Fits All” approach. This is where when the application is installed someone has gleely clicked next all the way through the application installation and the configuration and then thrown all their selections in to the one job to have done with it. Now this approach will work so I am not saying it is wrong, but it will most likely to contradict Symantec’s Best practices.

So if it does work why change it, well reliability is my main reason from wandering away from the “The One Job Fits All” approach, and another is ease of troubleshooting. From experience I have found that where everything is backed up under one job, these fail more often and have a much lower reliability then when you split out your jobs and match up with Best Practice.

So how do I configure my jobs:

First off, if you have more than one server seperate them out in to their own jobs, they can all still run everynight but have a seperate job for each server, then should there be a problem with a server this doesnt make it look like you have lost a whole days worth of backup, but just backup for one job.

Second, seperate out your file jobs from your database jobs, if you read the Best Practices for AOFO and SQL you will see that Symantec’s reccomendations for these jobs are that they should not be configured under the same job. So if you have a server that has SQL or SQL Express that you wish to backup split these out in to seperate jobs. Have your file job with AOFO enabled and then move the SQL selections in to a seperate job with the SYSTEM State and maybe exchange.

Then there is Exchange, this should not be included in a file jobs where AOFO is enabled, especially if you are using the GRT option. If you configure a backup job with Exchange, GRT and AOFO its not going to work, and you will find that although Exchange is backed up you will not be able to restore individual mailboxes or emails. This is because the Snapshots taken for AOFO will stop the information store being backed up in “full” mode, this will in turn stop the GRT technology from allowing you to restore individual items.

So taking in to account all of the above I have put together a little scenario to show how this should work:

EGSRV01 – File / Print / DC
EGEXC01 – Exchange
EGSQL01 – SQL Server
EGAPP01 – Application Server with SQL Express

For the above scenario I would set up my backup jobs as follows:

EGSRV01: Job 1: File Job with AOFO enabled, Job 2: System State job (AOFO Disabled)
EGEXC01: Job 1: File Job with AOFO enabled (Making sure exchange database files have been excluded), Job 2: Exchange Server and System State (AOFO Disabled)
EGSQL01: Job 1: File Job with AOFO enabled (Making sure SQL database files have been excluded), Job 2: SQL Server and System State (AOFO Disabled)
EGAPP01: Job 1: File Job with AOFO enabled (Making sure SQL database files have been excluded), Job 2: SQL Server and System State (AOFO Disabled)

Scheduling of jobs:

When scheduling multiple jobs to run overnight you need to take care with the media overwrite settings, you should make sure the first job scheduled to run is set to overwrite media and then all other jobs are set to Append and terminate if no over-writeable media available. If you do not do this you will end up overwriting the other backups taken that night. If I have multiple jobs scheduled I set up the first job to run 10-15 minutes before the rest of the jobs which are all scheduled to then start at the same time. You also need to make sure the job end time for all subsequent jobs is set to the time of your entire backup window.

Additionally to this if you are using media overwrite protection on your media sets you should make sure that your append period is long enough to cover the backup window.



%d bloggers like this: