Backup is still an area where many administrators have significant pain and yet many do not implement storage area networks (SANs) to improve their backup environment. Even when they do, they may struggle to see all the benefits they should expect. Why is this?
Let's get one thing straight right from the start: There is no business benefit in doing a backup -- all it does is waste the time of the IT administration staff, waste CPU cycles of the servers involved (if the servers are more than simple file servers) and create cost when purchasing expensive hardware that achieves absolutely nothing. Indeed, the more backups you do, the more tapes you have to look after.
Most of us probably well aware that the actual business requirement is to restore data in a number of problem scenarios -- when data is corrupted or lost, when a system needs to be rebuilt or when someone deletes a critical file. Clearly, in order to recover data in these cases, we need to go back in time.
Restoring data from a backup is one way of doing this. Backups can be done to and restores from either primary storage -- disk -- or secondary storage -- tape.
There are a number of articles that discuss many of the subjects highlighted above, but for the moment, let us just assume that part of your strategy is to operate a traditional backup from live servers to one of the tape media formats. Given my original statement -- that backup has no value in and of itself, and that
So, what are the primary options for backup?
- Direct backup: This option has a tape drive, autoloader or library directly connected to each and every server so that each and every server can directly backup and restore data.
- Network backup: This has much larger tape drives, autoloaders or libraries connected to just one server. It backs up the data of all servers through that one backup server.
- Storage-area network (SAN) backup: This has some form of storage network to which all the servers and the backup device is connected so that, with appropriate arbitration, all the servers can backup to these shared devices.
In reality, most people use a combination of the above. For this discussion, it is a little simpler to focus on the extreme cases. Similarly, in each case, there are variations on a theme, which I may touch on later.
Let us first look at the capital costs of each of these solutions.
For direct backup, each server requires its own tape drive or auto loader. This is a capital cost, though typically these tape drives will cost less than those used in the other solutions. You may use a tape drive rather than an autoloader, or an autoloader rather than a library or a lower capacity, slower drive than you can for other solutions. In addition, each server requires a full copy of the backup software along with the necessary, optional modules to back up the applications on that server. Finally, you can argue if this is a capital cost or not, but each server will have its own batch of tapes used for the backup of its own data.
For network backup, only the backup server has a backup device -- but typically this would be a higher capacity, faster, more expensive backup device. In such cases, you are far more likely to use tape libraries, which are comparatively rare in the case of direct backup. In this case, just the one server requires full backup software and indeed will be more likely to need the additional, often chargeable option from the backup software to enable it to operate a tape library. All the other servers need either no additional backup software components, or worst case, a comparatively inexpensive backup agent (certainly inexpensive compared to the local backup software). Regarding tape media, this is also now pooled and so there is most likely a savings in tape media costs. Additionally, it is very common to add a network card, which requires additional network ports to keep the backup traffic on a private, fast network rather than mixed with normal network traffic.
Finally, for SAN backup, as with network backup, we will typically have just the one or a small number of high capacity backup devices -- most likely tape libraries. Unlike the network backup case though, each server requires a fairly expensive backup software license, adding up to probably more software costs than both the other cases as each server needs the backup software plus the library option plus some form of shared media option (the exact details will vary for the different backup products of course). The tape media position is just like the network backup case. Where network backup gives you the option of having an additional network card in each server and additional network ports, in this case each server will need an HBA and SAN switches, and possibly an additional router box to connect the backup hardware to the SAN. While costs have come down, HBAs and SAN switches are typically more expensive than network cards and network switches.
At the very high level, it is not 100% clear what the relative capital cost differences are between the different solutions. As with disk storage consolidation, when starting from a clean slate, you may spend less on tape hardware with either the network or SAN backup case than the direct backup case. All else being equal, the hardware cost for SAN backup is more than network backup. But in reality, as SAN backup is faster and more efficient than network backup (if well-implemented), there may be hardware savings as you may not need as many tape drives.
The software element is the one that often scares people. Network backup entails less software costs than direct backup. However, it is a little more finely balanced because you'll be more likely to use an advanced backup product anyway. It is clear that the software costs for the SAN backup are the highest of all these solutions.
Also, this is often the one where the existing capital equipment is the biggest problem. You already have expensive tape drives in each server and a lot of backup software. Although backup is a significant pain point, it is also far easier to justify during an infrastructure renewal than an incremental project -- at least from a capital asset perspective.
Now, let's look at the operational and the soft costs.
The biggest difference in operational costs -- and we can broadly look at this as the time IT staff spends doing backups and restores -- is between direct-attached backup and either network or SAN backup. With direct-attached backup, staff time is lost to the tape monkey -- running around, changing tapes in all the servers, labeling tapes, putting tapes in boxes, putting the tapes somewhere away form the server, trying to find the right tape when you need to restore some data...etc.
There is an argument about the relative operational costs of network and SAN backup. SAN backup and restore is typically faster than network backup because the SAN is more efficient for block data transfer than a normal network, though, I know some people would argue the point. Of course, the operational guys also have to be able to administer the SAN -- though they may do so already if you have the SAN for storage consolidation as well as for backup.
What about soft costs? Broadly here we are referring to staff efficiency: What would the IT operations people be doing if they were not tied up on backup or restore? What would the normal users be doing if they were not waiting for data to be restored? What is the impact of the data or server being unavailable for a period of time? While we can see there is an impact, unlike the capital asset discussion and even the other operational costs I have discussed, these are the ones that are hardest to quantify. Unfortunately, if we are not looking at a greenfield data center, they may also be the most significant (unless, as I mentioned, you already have a SAN for disk consolidation).
What about the other problems?
The first thing I have to say here is that while I claim to be a storage or at least a SAN expert, I do not claim to be an expert on backup -- and that is the problem! Just putting a piece of backup software on a server, or even setting up network or SAN backup, is quite simply not all that hard. However, setting up a comprehensive backup infrastructure, ensuring that each application is handled properly with all the problems of online backup of e-mail systems databases and the like, optimizing it so that you really get the performance you need, setting up all the operational procedures, automating the systems, and testing the various backup and restore scenarios relevant is a very specialized area.
A significant part of backup pains come down to not getting all this stuff right, and that comes down to having the right consultancy, the right training, the right planning and so on. I must point out that user pain and cost savings, whether hard or soft -- capex or opex, are different things. I am a firm advocate of the cost benefits of SANs in general and of backup SANs in particular. I am also a firm believer in reducing user pain, which leads to unhappy IT departments, staff retention problems and mistakes. In the final analysis, all these things do impact the bottom line of a company.
Well, how do I summarize? My cop out is that this is a strategic decision, as I have said before. Take the telephone example: How do you quantify the benefit of each person having a phone on their desk (I remember when I started working, we shared a phone between six people), or having a mobile phone or voicemail. Qualitatively we know many of the benefits, and we have some idea of the costs, but to say we can produce a 100% bullet-proof argument, justification or cost analysis would be quite hard.
I think the most important point really is to think through all the options. Indeed, when it comes to backup I would argue that this is incredibly important. One thing is certain -- when you have lost data, the time when you're trying to get it back is not the best time to think through your options and possible solutions.
About the author: Simon Gordon is a senior technical consultant who has been working with storage area networking technology, particularly with Brocade based SANs for over four years and is currently looking for his next career move. Simon has been working in the IT industry 15 years in software development, systems integration, Microsoft infrastructure design and most recently storage area networking.
About the author: Simon Gordon is a senior solution architect for McDATA based in the UK.
Simon has been working as a European expert in storage networking technology for more than 5 years.
He specializes in distance solutions and business continuity. Simon has been working in the IT
industry for more than 20 years in a variety or technologies and business sectors including
software development, systems integration, Unix and open systems, Microsoft infrastructure design
as well as storage networking. He is also a contributor to and presenter for the SNIA IP-Storage
Forum in Europe.
This was first published in December 2007