cancel
Showing results for 
Search instead for 
Did you mean: 

BE2010 R3 - Excruciatingly long backup window. Looking for tips/tricks for optimally setting up jobs.

matthew_austin
Level 2

Hi Folks, I'm running BE 2010 R3 with all the updates through SP3 on a single media server.  Remote agents are all up-to-date.  

Good, bad, or ugly I'm going to lay out the current setup we have, and I'd like to get feedback on how to better set this up, or decide if this is just as good as it gets.  

Our weekly full backups consist of two jobs.   

Job #1:  Windows servers.   We have about 25 windows servers on this selection list.  It backs up system state, disk drives, and any sql databases.  The job is about 2.8TB, with about 3.6 million files and 500,000 or so directories.   It takes about 40 hours to run. 

Job #2:  Filer backup.  This just backs up all our network shares from our filer via smb.  This job is about 2.4TB, with 2.8 million files across ~250,000 directories.  It takes about 60 hours to run.  

We have a quantum superloader 3 with 8-tape magazine and a single LTO4 drive.  I find this infuriatingly slow.   Basically we start backing up at 11AM on Friday, and it doesn't finish until sometime on Tuesday.  

I got some improvements by bumping the block size up to 256KB but I think now it might have to do with how the jobs are set up.  

Symantec suggested I set up 25 different jobs, one for each server, but I'm not entirely sure how you would work out the scheduling of those, it seems like it would be impossible to stagger the time windows for so many different backup jobs.  Then, glancing through the best-practices guide, it seems like they also recommend splitting the servers down into jobs that segregate out system state, sql backups, etc.   At this point I'm just rather lost, and looking for some guidance.  It's a pretty simple and straightforward setup, by comparison to what many people have, but even this feels a little beyond my scope.  

Thanks in advance for any tips or tricks, comments, criticism, etc, I will gladlty take whatever I can get. 

Best, 

Matt

 

ETA - Is there a reason my comment replies are being sent to a moderation queue?  Seems like an unnecessary hurdle with a b2b customer when replies to the topic can't even be posted in a timely manner.  

2 ACCEPTED SOLUTIONS

Accepted Solutions

CraigV
Moderator
Moderator
Partner    VIP    Accredited

Hi Matthew,

 

I think the advice to split your backups up into 25 different jobs is actually poor, especially on a single-tape drive.

Even doing this would ensure your backups would take a long time to complete. It wouldn't matter if they were split up...they'd still process snapshots of System State, files, applications etc sequentially. So sidd2009's inference that it will help is wrong in my mind.

I split my backups off from each other, but had 2 GFS policies using BE 2010 (R1/R2/R3). Simply put...files and System State in 1 policy and selection list; databases in another. And I made sure that when the daily files/SS job ran, the database job kicked off after that and appended to the same tape. I never had an issue restoring data from multiple tapes or media sets, as the 2 sets of policies targetted the same media set. Problem solved.

This MIGHT have helped in your case if you had multiple tape drives in your autoloader as you would be able to split the jobs up a bit, and target those tape drives at the same time possibly cutting your backup speeds down substantially.

Upgrading to BE 2012 with SP2 isn't the answer either...there were a lot of functional aspects of BE 2010 R3 that were stripped from BE 2012 which would see you more frustrated with the application than ever. BE 2012 R2 is supposed to be adding this functionality back, so rather wait for that. I certainly wouldn't advise you to upgrade unless absolutely necessary.

Disk-based backups are a good idea. These should speed up backups a bit...not sure how much. Duplicating to tape (do NOT backup the output!) should see faster speeds there too as the tape drive will stream at the fastest speed of the drive.

Otherwise consider INCR/DIFF backups on the larger resources?

Thanks!

View solution in original post

Grayc
Level 4
Certified
Matthew, I'm in a similar position with my backup setup and wanted to share my experience on your idea to move to disk backups. If you start doing backups disk-to-disk-to-tape, do not schedule the duplicate jobs in BE2010. Instead set them up to run immediately after the disk-to-disk backup is done. At first, I set up my backups to disk to run over the weekend and the duplicate jobs were scheduled to run from Monday through Wednesday. Unfortunately, right from the get-go, none of my scheduled duplicate jobs ran. Instead they "Failed" because they could not find the backup set/selection list to duplicate to tape. This prompted me to try the other feature where the disk-to-disk backup immediately upon completion, duplicates to tape. I changed one of my jobs and had instant successful results. After that all my BE2010 jobs were re-configured in this fashion. As for upgrading to BE2012 R2, I recently upgraded. It is server-based which is kinda nice but if you have a company project residing on multiple servers, and they request a one-two backup jobs to backup their specific files, good-luck! I was able to do that in BE2010 but in BE2012 that's a no-go. I had to upgrade to BE2012 because I have a couple of RH Linux 6 servers, which BE2010 does not handle.

View solution in original post

7 REPLIES 7

Siddhant_Saini
Level 6
Accredited Certified

Hello Matt,
Splitting the backup jobs in such a setup would be THE first thing to do. Every remote server's System State/other resources backup would take up time processing the snapshots based on the resources available on that remote server.

The only problem with splitting the backup jobs will be that you'll have to depend on two to three backup sets(based on one backup for System State, second for SQL, thrid for files/folders etc.) at the time of a restore. 

If you are fine with splitting the backup jobs then you might as well upgrade to Backup Exec 2012 with Service Pack 2! It would ultimately end up in creating server based backup(as compared to one backup job that would accomodate all the servers in its Selection List) thus improving the performance(time window) of the backup jobs. 

matthew_austin
Level 2

I'm willing to give it a shot, but I'm still trying to wrap my head around how it should be set up.  

Would I have three jobs like so:  

1) Weekly System State Backup

2) Weekly SQL backup

3) Weekly files/folders backup

that use my 25-Server selection list? 

Or would there be 75 jobs, one for Server #1: System State, one for Server #1 SQL backup, one for Server #1: Files/folders backup, and so on down the line?  

Another thing I can't wrap my mind around is scheduling even 25 different jobs, as it seems like it would be impossible to schedule those properly.  By that I mean when I set up a job to run every 1st, 2nd, 3rd, 4th, and 5th friday, it has time-window where it can't start sooner than X time, or end later than X-time. 

I'm really reticent to give BE2012 a shot, I really haven't heard good things about it when I read third-party commentary on it.  But if starting over would be worth it, I can discuss it with my IT director.  

matthew_austin
Level 2

Thank you for approving the reply.  I think my most immediate action will be to straighten things up in 2010R3, at which point I'm going to request 7-10TB of storage space to set up backup to disk folders that we then offload to tape for the offsite requirement.  Meanwhile, I'll be researching 2012 sp2 in more depth.   

The question about setting up the jobs is something I'm concurrently researching while waiting for clarification here as well.   Thanks for your input!

Best, 

Matt

CraigV
Moderator
Moderator
Partner    VIP    Accredited

Hi Matthew,

 

I think the advice to split your backups up into 25 different jobs is actually poor, especially on a single-tape drive.

Even doing this would ensure your backups would take a long time to complete. It wouldn't matter if they were split up...they'd still process snapshots of System State, files, applications etc sequentially. So sidd2009's inference that it will help is wrong in my mind.

I split my backups off from each other, but had 2 GFS policies using BE 2010 (R1/R2/R3). Simply put...files and System State in 1 policy and selection list; databases in another. And I made sure that when the daily files/SS job ran, the database job kicked off after that and appended to the same tape. I never had an issue restoring data from multiple tapes or media sets, as the 2 sets of policies targetted the same media set. Problem solved.

This MIGHT have helped in your case if you had multiple tape drives in your autoloader as you would be able to split the jobs up a bit, and target those tape drives at the same time possibly cutting your backup speeds down substantially.

Upgrading to BE 2012 with SP2 isn't the answer either...there were a lot of functional aspects of BE 2010 R3 that were stripped from BE 2012 which would see you more frustrated with the application than ever. BE 2012 R2 is supposed to be adding this functionality back, so rather wait for that. I certainly wouldn't advise you to upgrade unless absolutely necessary.

Disk-based backups are a good idea. These should speed up backups a bit...not sure how much. Duplicating to tape (do NOT backup the output!) should see faster speeds there too as the tape drive will stream at the fastest speed of the drive.

Otherwise consider INCR/DIFF backups on the larger resources?

Thanks!

matthew_austin
Level 2

Craig, thank you for your thoughtful reply.  I'm still digesting everything, It's sounding like we're maybe poorly equipped, hardware-wise, with only one LTO-4 tape drive.  With backup to disk, I was  thinking maybe I could set up concurrent jobs (that's probably not the right term in backup parlance) to hopefully get throughput up, and i think that would really help, depending on which servers they are.  Some of our servers back up 50-60GB in 10 minutes, while others, the transfer rate is as low as 400MB/min.  

This gets a little intimidating for someone like me, since I'm not a bona-fide sysadmin.  I'm just a lowly help desk manager who has also been tasked with administering backups, image deployment, and our managed antivirus.  Each of these has had a bit of a learning curve, but I think backups have been my biggest struggle so far.  

Grayc
Level 4
Certified
Matthew, I'm in a similar position with my backup setup and wanted to share my experience on your idea to move to disk backups. If you start doing backups disk-to-disk-to-tape, do not schedule the duplicate jobs in BE2010. Instead set them up to run immediately after the disk-to-disk backup is done. At first, I set up my backups to disk to run over the weekend and the duplicate jobs were scheduled to run from Monday through Wednesday. Unfortunately, right from the get-go, none of my scheduled duplicate jobs ran. Instead they "Failed" because they could not find the backup set/selection list to duplicate to tape. This prompted me to try the other feature where the disk-to-disk backup immediately upon completion, duplicates to tape. I changed one of my jobs and had instant successful results. After that all my BE2010 jobs were re-configured in this fashion. As for upgrading to BE2012 R2, I recently upgraded. It is server-based which is kinda nice but if you have a company project residing on multiple servers, and they request a one-two backup jobs to backup their specific files, good-luck! I was able to do that in BE2010 but in BE2012 that's a no-go. I had to upgrade to BE2012 because I have a couple of RH Linux 6 servers, which BE2010 does not handle.

CraigV
Moderator
Moderator
Partner    VIP    Accredited

Good piece of information...pity I can't thumb's up the reply...yes

I think you meant you upgraded to BE 2012 SP2...BE 2012 R2 is in Beta from early next year which will see the return of a lot of things removed from BE 2012. This is 1 of the reasons given for no further development on certain support for BE 2010 R3 (check the Beta page for further information).

Thanks!