If you’re new to backups, or even Backup Exec, working out how everything works, gets installed and configured, and fits together, can be a very daunting place to be.
I started out the same as any other newcomer to backups, and the skills ramp-up was quite steep. With nobody to help me (certainly I wasn’t aware of Connect at that stage), I had to rely on myself to get through things (and a bit of help from Google which WAS available!).
However, where do you start now days? I’ve decided to write a series of articles to help you get going and find your way through the backup minefield…
- Trialware / Playing with the software
If you have the time available to you, or are new to Backup Exec, the first thing to do is to get hold of the trialware if you don’t have anything available to you. The trialware comes with almost every agent available for a trial period of 60-days before it expires and stops working. What does that allow you to do? Simply put, it allows you to evaluate whatever you need to in order to make a decision to purchase Backup Exec,or play around with the software.
Taking into account the issues many people had with Backup Exec 2012 when it was released earlier this year when they went and installed it, this also ensures you don’t fall into any traps by making use of early adoption of the new software.
Best bet to test the software is to load it onto a VM and test by backing up data to disk. To get to grips with the software, it doesn’t have to be a production-sized B2D or even backup the same amount of production data. If you have a physical server you can test with, even better. Just remember that when it comes time to implement, that a physical backup server is recommended by Symantec.
During the trialware, you’ve got 60 days to evaluate for free…use it!
- Basic Environment Audit
Once you’re done with your trial, start auditing your environment. The answers you’re likely to be considering would be:
- How many servers do I have to backup? This will affect the licenses (remote agents and application agents) you require to adequately protect your data.
- What data do I have?
- How do I want to protect my environment? If you have a virtual environment, do you want to protect the entire VM, or just the data within them for instance?
- Do I have a physical backup server to install Backup Exec on, and does it have the required resources to run BE properly?
- Do I have competitor backup software installed already, and how long will it take to cut-over to Backup Exec?
- How long do I want to retain my data for? This has a direct impact on the number of tapes you need, or end up buying, and the amount of disk space required if you backup to disk
The reason you’re doing a backup environment audit is to ensure you are correctly licensed, and hardware-ready to implement your backup infrastructure. I’ve seen it on many occasions when an audit hasn’t been performed properly with the end result being the client suffers. Either additional expenditure is required if licenses are left off (either an up-front payment or a sudden increase in a renewal license!), or hardware that doesn’t cater for a backup schedule. Either way, it ends up with a seriously angry client. Try to avoid this at all times…a little bit of extra time taken here can make all the difference!
- Customer Requirements (if customer-facing)
Make sure that what you find out in your audit requirements fits in to what the customer (if you are customer-facing) wants. There is no sense in proposing a backup solution with excess licenses, or something that doesn’t meet their needs.
Find out what they are thinking of, or require before finalising, or proposing anything.
- Budgets, Implementation Timelines, and Decommissioning Old Software
What is your budget like? Can you afford all the bells-and-whistles to backup your environment in the ideal manner, or can you start off small and grow? IT budgets are tight for a number of companies of various sizes, most often affecting backup implementations. Make sure you’re not being oversold licenses or capabilities you won’t need (as with #3).
With regards to implementation timelines, if you know what you’re doing, you would know how long it will take to get Backup Exec installed and running. If not, always add in more time for this. Don’t cut down on the amount of time it will take to get a product you’re not used to installed and working. There is nothing worse than getting pressure from management as to why backups/restores aren’t working, and not being able to give them proper information.
Lastly, if you have current backup software installed, how long do you need to keep the software installed in order to ensure that you have run those tapes out of their retention periods? If you have a new implementation of Backup Exec on a new server, then this becomes a non-issue. If it is to be installed on the same server, consider whether or not you need to keep the old software installed; whether or not you can uninstall the application and reinstall it in future if required; or whether or not Backup Exec can read that vendor’s tapes (I’ve used BE 2010 R3 to restore ARCserve 11.5 data). For the latter, check the SCL of the version of Backup Exec you want to install to see if it supports that vendor.