Impressions of BackupExec 2012

[Bulbous]

Is it just me, or does anyone else absolutely HATE the redesign of Backup Exec? I have worked with BE since version 8, and I have become acutely familiar with the menus, where everything is, and how it works.

This redesign of the UI reminds me of the differences between Microsoft Office 2003 and Office 2007, only much worse. Menus are now hidden behind other menus, and everything has a completely counter-intuitive feel.

At first, I thought that the feeling would pass as I grew more familiar with the product, but in fact my dislike has grown as I have found more issues.

Does anyone else feel the same way?

[ianSinclair]

I can live with a new interface, but I have a specific need.

I need to backup 4 servers, I have a robotic library with 84 tape slots and 4 tape drives.

I need to configure backups of those 4 servers at 9 pm mon-fri

I want the c:\ drivevs all to go on the same tape, so serve1,2,3,4 c:\ on on tape 1

I want e:\ and f:\ to go on tape 2 so 4 e:\ and f:\ on tape 2

How can I do this with the new improoved backup exec ?

Answers would be appreciated, I have logged a techincal support call and they can't do it without partitioning the library and I don't want to to that.

??

Ian

[ianSinclair]

Why make it so complex. here's a group of servers back them up to a tape start at 9pm and run till yuor done, easy.

Designate one server as overwrtire, set the others to append, set this set that , ajust the priority

why make it so fiddly ?

[hazmat09]

Hi Ian, 

Forgive me if you're all ready aware of this, and it does not meet your needs...but in case you haven't used this, it may be helpful.

Can't you just create media sets for your jobs. I have a 24 slot loader and I use bar code labels for the tapes. Since my Servers catch all job is now broken into individual servers. I created a Group called Server Data and placed the relevant servers in the group. On each job I have it pointing to a media set called Server Data. I also created Server groups for SQL, Hyper-V etc. 

I create the same media sets for SQL, Exchange, Hyper-V. I don't care what order the tapes are in as I have the bar codes, and an Inventory takes 20 minutes. We backup to disk then immediately to tape. We like having the ability to keep months of data on site for quick recovery.

Couldn't you simply create a Media Set called "C:\ drive-Job1 Tape1". You would just have to specifiy that media set on those particular "Server" backup jobs. You would do the same thing with the E:\ drive jobs.  Under your "To Tape" job you'll find the Media Set setting under Storage.

To create media sets, you'll find it under the Storage tab - "Tape/Disk Cartridge Media Sets And Vaults" righ click on "all media sets" to create new. Once you've created them there you'll see them as an option in your Job storage options.

I'm not sure you could control to what tapes you want them going to specificly, but this would achieve what you want to do. This feature was in prior versions and is still in 2012. In my case it dumps to tape and labels the tapes with those media set names and the tapes are done in sequence and appended.

The UI was a pain at first, but I tweaked it to achieve basically what I need view wise "which you can save"

Hope that's of assistance to you.

[ianSinclair]

Thanks for the idea hazmat, I did consider that, then I thought why ? At the moment I have one media set called backup media, all jobs use this not problem.

But I have explored the ides,the the problem is this, you have a media set for a job, as you say the jobs are configured to use this media set, so job one writes to media set 1

Server 1 starts its backup, it is an overwrtire job to media set 1, server 2 is an append, so it appends to media set 1, all good, the tapes go offsite, then they come back and we put them in the library, now I have 2 or 3 tapes from media set1 in the Library, job 1 starts and overwrites the media, job 2 starts, if job 1 is still running it will pick one of the returned tapes and overwite it.

Or am I missing something ?

[TTT]

I'm not sure why you called off-site tape "an awful choice" for DR.  I gave specific reasons why duplicating to tape for DR was a valid choice; which of those do you disagree with?  Also, which companies are you talking about?  If their tape duplicates (and tests and documented DR procedures) met their DR requirements then it probably means they went bankrupt for business reasons other than IT.

You've also interchanged BC and DR.  BC is much more than backup-to-disk with replication to another site.  DR = complete loss of equipment and rebuilding from backups.  BC = sustaining operations during an outage/disaster. BC requires a second fully-racked datacenter (or, at least enough servers and storage to meet SLAs) that performs transaction-based replication.  Some people just have a remote SAN that stores replicated data- that's not BC. Where are the servers?

Even though I have BC, I still perform full DR tests from duplicated tape (wipe servers and SAN and rebuild from tape)- in fact, I'm doing one now with BE2012 - which is why I require my backup software to have tape capabilities. I wonder how many people here have performed full DR tests?

[Keith_W__Hare]

Robnicholson said:

If you are serious about business continuity, then backup-to-disk should be where it's at with replication to another site.

The concept of replication to another site assumes two resources:

• Another site
• A high speed network connection to that mythical other site

As strange as it may seem, there are a number of small and medium size businesses that have only one site. For businesses with a single site, tape is still the most cost effective mechanism for getting backups offsite.

Keith

[robnicholson]

>I wouldn't agree. Tape is good for offsite recovery if you're budget conscious, and can accept a day's lag to getting up and running again in a disaster, and with VMs the restore is beautifully simple.

Of course it depends upon the business but these are worrying stats (stats = take with pinch of salt?):

http://www.bostoncomputing.net/consultation/databackup/statistics/

For tape to be a suitable DR scenario, you need redundant hardware on standby. Last time I checked but a robotic tape loader wasn't cheap. And of course, you need to catalog your tapes if you don't have the off-site catalog you mention (really, really wish BE included catalogs on every tape).

And 77% of test restores failed? That doesn't fill me with confidence.

All of this though is about insurance and how much one spends on this aspect. Should one be budget conscious in this area?? False economy maybe?

Cheers, Rob.

[robnicholson]

For businesses with a single site, tape is still the most cost effective mechanism for getting backups offsite.

The cost of getting backups off-site isn't really the problem is it? It's most the effective way for getting the data BACK in case of disaster where most plans for wrong.

I just don't trust tape anymore. We've got a Quantum Superloader 3A with 16 slots. The business requested a restore from the monthly backup a year ago (over 3 LTO-3 tapes). Catalogs were long gone - it took over 24 hours to get the file back and one of the tapes was really struggling to restore. This was the the same tape unit. Probably the heads going out of alignment.

Now whilst tape is great for long term potential archive storage like this, I don't want to be faced with a bad tape in case of a DR situation.

Cheers, Rob.

[robnicholson]

You've also interchanged BC and DR.  BC is much more than backup-to-disk with replication to another site.  DR = complete loss of equipment and rebuilding from backups.  BC = sustaining operations during an outage/disaster.

I agree sort of.

Business continuity is as you say sustaining operations during an outage/disaster of typically a limited number of systems (e.g. single server failure, internet going down) and therefore to a certain extent, DR is business continuity on steroids when all of your systems fail (e.g. due to fire) and you have to trigger all your BC procedures at the same time.

So consider your DR procedure for rebuilding a file server. That's identical to your BC procedure if just that single server failed (and had to be replaced).

What the evidence points towards is that even planning to rebuild in terms of DR is, for some businesses, a non-starter because of the time taken to rebuild means they go out of business.

These series of blogs (from Unitrends) give some food for thought:

http://www.unitrends.com/blog/the-ghosts-of-backup-past-the-tape-era/

Considering 12TB SATA-3 external disk enclosure costs £500 and IMO is more reliable for DR purposes (archive is a different requirement), then I'm not sure for a small business that tape is a cheaper or more reliable option.

What I do know though is that BE dedupe isn't really designed for keeping an on-site dedupe disk system and periodically updating another disk enclosure for use off-site.

Cheers, Rob.

[TTT]

Good point re: catalogs.  I back up the BE server itself; when doing a DR test, step #1 is to restore the BE server (page 639 of admin guide, "manual DR of local computer") to get those catalogs back.  Of course we have to check the tape report to find out what tape BE was dupe'd to first, then inventory/catalog (and restore from) that tape; it's not as efficient as if we had the catalogs already available from an offsite share.

[BE_KirkFreiheit]

Thanks hazmat09.

One of the key drivers for the changes we made in Backup Exec 2012 was the desire to unify our Backup Job model.  In prior releases, we had standalone backup jobs and backup policies -- which you could use to bundle a group of jobs like fulls, differentials, and duplicate/copy jobs.

Backup Exec was able to monitor/track changes between jobs far more reliably with policies because each subsequent backup job used exactly the same selection list (or lists).  Standalone full/differential jobs required more attention to get the selections to match -- you had to either notice the selection list dropdown on the selections page (we learned this often wasn't noticed), or make your selections exactly the same in each backup job.  It could be tedious, and was error-prone.  But, after talking with many of our customers, we learned that policies and their benefits were not as widely used/understood as we hoped  -- so making standalone jobs remained a common use pattern.

As you experienced, some backups (especially standalone jobs) don't migrate well into the new backup model.  Thanks for putting in the effort to get things working in your environment; we're actively looking for ways to make this process smoother but sometimes recreating jobs is the best thing to do, unfortunately.

It sounds like you were using policies -- but I'm not sure your differential was part of your policy in 2010.  With 2012, it should look and feel like you've got an easy-to-understand staged data flow.  It's great to hear that absorbing all the change in methodology has given you that benefit.

One little detail: had your Duplicate stage been schedule by time, instead of "Immediately after", you could get away with just one Duplicate task and set it to copy "All backups".  That's a new feature -- the automatic selection of all backups (Fulls + Differentials in your case) but it does require a time-based schedule (for example, doing all of your tape duplication one day a week).

Thanks for the input on modifying next run -- sounds like just putting your jobs on hold solved all but the last issue.  We're getting very useful feedback on changes we made to the scheduler and I'll see what I can do to get that scenario addressed in the future (holiday scheduling).

[TTT]

Business Continuity encompasses DR, not the other way around.  BC is the Ultimate (going above and beyond the IT department), with no downtime allowed (as per SLAs which are usually based on priority, resources, and cost).  DR has a much lower TCO to implement/maintain than BC.

So consider your DR procedure for rebuilding a file server. That's identical to your BC procedure if just that single server failed (and had to be replaced).

Perfect example!  My procedures aren't identical.  My BC procedure for my file server is do nothing.  Redundancy, transactional replication, and duplicate hardware between my datacenters yields me five 9's availability for that resource.

If one of my file servers did fail (e.g. corrupt registry), I'd restore it- not DR it- from local disk-based backup, and resync the replication. 

For total loss (DR), my procedure is acquire/rack/stack/configure hardware, then restore the enterprise from tape.

Your $800 disk array would not facilitate DR unless the techs unplug it every night and transport it off site.

I believe you made the assumption that I only rely on tape.  Tape has two remaining benefits: It is (1) a low cost way to have off-site backups in order to (2) mitigate the risk of loss-of-site.  Wow this went way off topic from BE2012 :)

[GregOfBE]

Concerning the copy server settings job. It is not showing up in the BE 2012 job history in the GUI.

Here is a workaround:

Use the powershell command line interface (BEMCLI) - available from the start menu. Issue the following command:

get-bejobhistory -JobType CopyJob | Select -Last 1 | Get-BEJobLog

This will show the job log for the latest copysettings job that you ran.

Also, this will show all of the times it ran:

get-bejobhistory -JobType CopyJob

And this will show any still running:

get-bejob -JobType CopyJob

Sorry this was omitted. We'll  need to do something about that.

[Keith_W__Hare]

Wow this went way off topic from BE2012 :)

This discussion thread is not really off topic. One of my criticisms of BE2012 is the increased difficulty of managing backups to tape. This thread articulates why backup to tape is still important.

Keith

[TTT]

Greg thank you!  That worked perfectly- I found the log and now I can see that yes, the job failed, and it even lists the reason ("Final error: 0xe00081e2 - An unexpected database exception occurred.").

Now I have something to go by!  Thanks!

[Amit_Walia]

Hi

I run Product Management for Backup Exec. We are reading all the comments, yours and you peers on this forum and take each and everyone of them very very seriously (and personally).

Our product means a lot to us. Its our life. It is what we come to work everyday to improve and travel 100's of thousands of miles around the work to test and validate.  It is tough to see our customers share unhappy comments about it and you can be sure that we took a risk with a new UI but it was a very calculated risk, one that we tested and tested again with 100's of customers and partners until we got their buy-in. Change is never easy but we took every effort to make sure the changes were worthwhile through direct engagement with users. 

UI aside, there are changes we can release in a service pack with more planned for that will help address some of your specific concerns.

I would like to invite you and a group of other peers on this thread to share your feedback in person  at our HQ. We will also and share with our process for gathering feedback and testing the UI. In addition we will share our plans for modifications to make sure what is planned meets your needs.  The trip will be paid for by Symantec.

I thank you for being with us over the years. If we have made changes that have caused them frustration, we want to hear from you and bring you into the process of guiding and developing the product.

Our team will be reaching out to you to arrange the post launch "Feedback Summit".

~Amit

[GregOfBE]

My post was intended to address the fact that the original poster had all of their jobs set to overwrite media and I was focused on that issue.

However, you raise important points. This situation varies. Some people who have multiple drives in a library want to spin as much tape as possible and so (if 2 drives) having 2 sets of tapes spinning is OK for them in which case they would target the library instead of the individual drives. In that case, when all drives are spinning, and a job finishes, the media remains in the drive and is not dismounted for a timeout period (default 30 seconds). If another waiting job is targetted at that library and the same media set and is set to append, it will append to that tape. As the other drive completes a job, same with that. So you essentially have a "concurrency" of the # of drives - if you target the library. You could of course target a pool too or use partitions.

But you also have the choice of targetting a single drive with multiple jobs in which case you can land multiple servers on that tape/tape family.

Having said all of this, I've encounterd multiple perspectives. We've encountered very large customers who prefer to break up their jobs per-resource (C:, DB Instances, etc.) and pump as much data as possible to multiple drives/tapes. They set up their media sets appropriately and have as much concurrency as possible. While other customers want fine grain control. It really seems to vary from one shop to another. So its not as clear cut as saying "Large customers" want multi-server jobs.

[GregOfBE]

If you are targetting the entire library in the jobs, yes that is true assuming there are multiple overwritable media in your library in that same media set. But you could target 1 drive for the C:\ jobs and another drive for the E:\ jobs. In that case, only when the first C:\ job is done, will the next one start running and because it is set to append, it will continue on that same tape (assuming your append period in the media set is long enough). And you don't have to guess how long each job is: They will wait until they have their target device available before they begin - in the state "Ready".

Having said that, this is one area of weakness because you didn't have to specify 1 drive before - you could target the library or a pool and once 1 drive was "chosen" the rest would follow. We understand that limitation and are considering ways to address that.

[pkh]

 I have the bar codes, and an Inventory takes 20 minutes.

Since you are barcode label, you don't have to do a inventory.  A scan does the same thing, i.e. identify the tapes.  A scan will be done in about a 1 minute.  I have NEVER done an inventory since I started using barcode lables.

[Bulbous]

Tape backup is not dead. In fact, tape backup is the only possibility for off-site backup in areas where internet access is slow or unreliable - which includes rural and remote areas of North America and elsewhere.

If the migration process was streamlined in such a fashion such that tape backups were plotted out in 2012 as they were in 2010, this transition would be much easier to digest. But as it stands, it is an incredible shock to the system.

I am an incredible supporter of Symantec, and I have approximately 120 different products registered as a consultant. I don't want to leave Symantec behind - but I also do not want to feel left behind by Symantec.