This article can also be found in the Premium Editorial Download "Storage magazine: Optimizing your enterprise database storage."
Download it now to read this article plus other related content.
Every once in a while, you stumble upon something you think will revolutionize the way people do something. I felt that way when I saw my first DVD player. I also remember the first VCR I ever saw, and feel it whenever I use my Tivo. I certainly felt the same the first time I saw BackupReport from Bocada.
|Trends and analysis reports|
Success and failure reports are noted by differently colored squares.
Storage trends report shows how much of your storage capacity is coming from each backup server.
If you're running ARCserve, Backup Exec, NetBackup, NetWorker, Omniback, or TSM, you'll definitely want to give this product a look.
Storage administrators are asked to deal with extremely complex environments today. They need to administer storage area networks (SANs), network-attached storage (NAS) and often a number of backup and recovery products. Before they start their day, they just want an answer to one question: "How did my backups work last night?" Believe it or not, getting the answer to that question can be difficult. The following are some common problems storage administrators face today.
Even if every server in your environment is backed up using the same product, it's unlikely it will be backed up by one instance of that product. Odds are that you have several backup servers-each backing up a certain number of clients. When you need to find out how backups worked last night, you'll need to point your reporting application to each backup server. There's usually no centralized way to provide a single report or graphical-based display of how backups worked in your environment last night.
Another problem is that many environments have multiple backup products. It's common to start out with workgroup level products such as ARCserve, Backup Exec, or NT Backup and eventually upgrade to enterprise-level products such as NetBackup, NetWorker, Omniback, or TSM. It's also common to keep the old product around for a long time. Sometimes this is because the environment that was being backed up by the first product is happy with it. This is especially true if it was backing up all Windows or NetWare machines. Windows and NetWare administrators often prefer the user interfaces of the workgroup level products and choose to continue to use them-even if the rest of the environment is changing to another product.
Another reason that an environment may have multiple products is if they allow individual cost centers to start with their own backup system. Then one day they try to centralize, and they find out that they've got three different backup products in house. I personally have seen one shop where they have NetBackup, NetWorker, Omniback, ARCserve, and Backup Exec. For various reasons, it's not uncommon for an environment to have multiple backup products. The following are some reasons why this can be problematic:
Different procedures. The biggest problem is that a storage administrator must understand how to use the reporting tool for more than one backup product. This increases the learning curve and increases the chance that they will not learn the advanced reporting functionality of any of the products-functionality that could provide a vital function.
Different reports. Even if the backup administrator manages to understand all of the interfaces, it will result in reports that all look different and very few of them can be prepared in a nontechnical format. Only a few of them can be viewed by end users or managers. And if they could view it, they wouldn't understand it.
Proprietary or nonexistent databases. Each of the backup products has their own reporting database. This database can almost never be queried by a third-party tool such as SQL. A few products support this functionality-but they are limited.
Every backup/reporting product that I'm aware of will show you what jobs succeeded and what jobs failed. That's good, right? What about the backup job that was made inactive last night by a customer request, but that you forgot to enable today? Most of the backup/reporting tools work only if you are logged in as administrator or root or if you're listed in their database as a backup administrator. This means that Jane has no way of finding out if her backups ran last night without asking you-resulting in more work for you and Jane.
Although some of the backup/reporting products are command-line based, many of the advanced reports are available only via the GUI, making automated reporting difficult. If you'd like to write a program that notifies you if a backup fails, you may not be able to. Even if your product supported such functionality, you'd have to write a different program for each type of backup software you are using.
Have you ever wondered if there were systems in your network that nobody told you about? They represent data that's not getting backed up, and probably won't get backed up until somebody notices-often when it's too late. I have often dreamed of scanning the network and comparing that against my backup configuration database, but never got around to writing such a tool.
This was first published in November 2002