In my last column I described the need and best practices for creating a disaster recovery plan. I pointed out that a strong backup plan is a key element in successful disaster recovery. Now, a reader of that column probably said to himself: "Self! My network doesn't HAVE a backup plan in place! Whatever am I to do?" Don't panic. Where there's a will, there's a way.
In this two-part series, you'll find 10 best practices that can help you build a blunder-proof backup plan, whether you are building a new network, taking over an existing structure that doesn't have a backup mechanism in place, or looking to expand your existing backup and restore architecture. In part one, there are five tips for building a backup foundation. In part two, there are best practices for implementing your backup plan.
1. Create a baseline.
Even though you certainly want to start backing up your critical data right now (and I mean yesterday), you should still take some time to determine your plan of attack. How much data needs to be backed up? Is it housed on a single server, on multiple servers in a single subnet/building, or on many machines across an enterprise WAN? How much does your data change from day to day? A store of archive information that is accessed often but rarely changed will dictate a different backup strategy than a frequently updated interactive database. Make a list of specialized applications -- Exchange, SQL, Oracle, etc. --that will likely require a special software agent in order to be backed up successfully.
2. Plan for obsolescence.
Have you taken a baseline of all services and data on your network? Good. Now throw it out the window. Not really, but make sure you leave yourself enough room for expansion. With the ever-increasing dependence on data warehousing, and the ever-decreasing price of storage media, your network will only grow. In your selection of software, backup hardware and backup media, allow enough room for expansion so that you aren't scrapping the entire setup six months down the road. Your accounting department will thank you, and so will your blood pressure.
3. Industry compliance.
Data retention schedules should always go hand-in-hand with backup planning, and with the Enron's of the world tramping across the CNN news ticker every day, this becomes all the more critical. It is absolutely essential that you comply with any and all federal, state, and/or industry-specific regulations regarding how long data should be maintained in archive. Tap your legal department or whomever else you need for assistance in this matter, because like everything else in this venture, it's certainly best to get it right the first time.
4. Strike a balance between cost and convenience.
We are all in a time of belt-tightening and making do with less than we'd maybe otherwise like. So, in the words of Tony Soprano, have a "sit-down" with your decision-makers and department heads. Figure out how much downtime is, if not acceptable, at least tolerable. If they're not willing to drop five figures on a Gigabit-Ethernet SAN, then give them the "down-sell". Before you leave the room, make sure they understand what they're paying for and what it's getting them. If your company doesn't use SLA's (Service Level Agreements), this might be a good instance to bring one into play anyway.
5. Create a workable backup schedule.
Unless you invest in an "Open File Manager" technology, your files will be unavailable during the time it takes to perform your backups. Full backups take the longest amount of time to backup but are the quickest to restore. Integrating incremental or differential backups into your backup strategy will reduce the time that nightly backups require, but will add to the time needed in the event a file restore is necessary. As with everything else, you need to find a comfortable balance that keep all concerned parties happy and content.
This was first published in August 2002