This article can also be found in the Premium Editorial Download "Storage magazine: Using two midrange backup apps at once."
Download it now to read this article plus other related content.
Identify and destroy bottlenecks with the right speeds and feeds.|
Before you start throwing hardware or software at a problem, a crucial first step is identifying the potential bottlenecks. Doesn't that sound simple? Maybe, but identifying and removing bottlenecks requires a deep understanding of how data flows through a backup environment, and there exist numerous opportunities for the backup process to slow to a crawl. Your mission is to identify and eliminate bottlenecks from your environment.
Consider the following company struggling with slow backup performance. Despite having a virtual tape library (a dual-headed VTL unit with aggregate performance up to 800MB/sec), multiple tape drives (25 drives with a native throughput of 30MB/sec) and several media servers, its aggregate backup performance was less than 200MB/sec. That may be acceptable for many environments, but this firm had nearly 75TB of data it wanted to back up in a 24-hour window. To do that, it needed to quadruple its throughput. Its million-dollar infrastructure was performing
| slower than a single LTO-4 drive. Not good.
The customer was told that it was time to investigate four key areas to find the bottlenecks. They are, in order of importance:
It's unlikely a backup administrator will have the ability to modify the client hardware, but it's critical to understand what you're dealing with from the client side. Specifically, it's important to know how many clients exist, and to have a clear picture of their network connections to the backup servers. While most environments today run gigabit networks, some individual servers still use 100Mb/sec NICs. Depending on the amount of data these slower hosts protect, these outdated connections may not be adequate. For example, this customer discovered that several of the clients were still running 100Mb/sec NICs. Most of the hosts were small enough that this didn't matter, but one problematic client had more than 700GB of data.
This was first published in September 2008