Newbie Question - Setting up backup scheme

[Jeffrey_Hahne]

I have inherited a copy of Backup Exec and a company to protect with it. I am looking for clues as to Best Practices for a Backup and Restore strategy. I have one server and a few desktops. I am hoping that strategy concept could be translated into "do this, then ...". I have read all the white papers but they lack the "how to" I need to apply BE to the problem.

Thanks

[Keith_Langmead]

The problem with something like this is there is no definitive right answer, it all depends on what you're running on your network, what kind of hardware you have, the backup media, finance, backup window and how quickly you NEED to restore the data after a failure. If you give some more information about your setup we might be able to advise.... but in general...

If you've got just one server I'll assume you're running the SBS version of Windows, and hopefully the SBS version of Backup Exec, in which case you want to make sure that you backup the server completely to allow you to restore any part of it in a disaster.

For the desktops there is the desktop and laptop option (DLO I think) which might be worth looking at, but I personally wouldn't bother. Better to educate the users that anything important should be stored on the server, and anything which they can afford to lose should go on their desktop. General rule of thumb I use with my users is that if I came along tomorrow and replaced your desktop without telling you, is there anything you have saved on your current machine (other than IE favorites etc) which you couldn't do your job without. If the answer is yes then that data should have been saved on the server in the first place.

Is the current copy of backup exec already installed and running, or do you just have the license but it hasn't actually been installed?

--- Disclaimer ---
Please excuse any bad grammer, spelling and punctuation cause by Christmas cheer!

[Jeffrey_Hahne]

Thanks for the feedback. I have a general concept of backup and restore like you described.

BE is installed and running. There is 1 job setup (essentially, backup the world to tape) that takes about 13 hours to run. Even I know this is unacceptable.

So after reading white papers, part of the manual, and such, I am looking to do a more segmented approach and use some disk then back that up. What I am missing is the BE concept of operations so I can make decisions about how many 'disk' devices I may need or how to select 'older' backups to move to tape. There are about 2 pages in the manual concerning how BE works (out of 1300 or something).

Can you recommend something with a bit more detail?

[Keith_Langmead]

Like I said, gimme more information and I'll see what I can do.

How much data are you trying to backup, do you have any kind of SAN/NAS, do you have enough disk storage on the server or elsewhere to make a complete backup of your system before it goes to tape, what type of drive and media are you using, what type of data are you trying to backup (eg just files, Exchange, SQL etc?).

You mention moving "older" backups to tape, but this is generally a bad idea since you lose the ability to do any kind of disaster recovery restore if the only backups you have on tape (which are obviously the only ones which you'd have off-site) are out of date, and the up to date information is on a hard drive which might well be trashed along with the rest of the server if it dies.

[Shraddha_Dhaval]

Hello,

Can you please update us on the issue?


Thanks.

[Jeffrey_Hahne]

Thanks again for the feedback. More details as requested.

I have about 16 gb (current job selections) to backup from the server itself and 4 other machines. I have a server hosting BE with 100+ gb space and with an 80 gb tape drive attached. The company runs 7 days but the office with the tape drive is only 5 days per week. So I need to run backups 7 days but only change tapes Mon - Fri. I still have research to do to see what is really changing in these machines so I can make decisions about full or incremental backups.

I am still looking for where I can find 'Best Practices' information hopefully with those practices shown 'as implemented with BE'.

Thanks

[Keith_Langmead]

Well if it's taking 13 hours to backup just 16GB of data to tape I'd say your first order of business is to resolve the problem with your backup speed, as that's way slower than you should be seeing. Things which could cause slow backups are faulty tapes, a faulty drive, wrong drivers or firmware. Try updating the drivers and firmware on your drive and see if that makes a difference. Also if you're currently using software compression on the backup jobs consider turning it off and seeing what difference it makes, since you've got plenty of space on the tapes to backup all your data without needing to compress it.

After that I'd probably go with two backup jobs, one for Monday to Friday which will go onto tape each night, and then Saturday and Sunday using backup to disk. Obviously the weekend jobs won't be much use in a disaster, but it's better than nothing and at least covers you if someone deletes something over the weekend. Just make sure to exclude your B2D folder from your backup jobs!

You could look at doing incrementals instead of full backups each day, but 1) it'll make restoring a lot harder, and 2) once you've got the backup speed issue resolved the time taken to do a full backup should stop being an issue.

As for best practices info, I don't think I've ever actually seen any, certainly any which is any use. Generally most documents just tell you to make sure you have backups, make sure you can restore from your backups, and make sure you regularly test your backups... except that manage to fill several pages saying the same thing! :) If you do find something though let us know, it'd be interesting to see.

[Jeffrey_Hahne]

Thanks for the help. I am experimenting with B2D now and the network really does have some problems that I will have to address as well.

Maybe I will have to write that document myself after all the trial and error, mostly error.