This article can also be found in the Premium Editorial Download "Storage magazine: Managing data storage for remote employees."
Download it now to read this article plus other related content.
High-speed storage routers are capable of supporting seven 10MB/s tape devices running concurrently through a single FC port. High-speed storage routers with two SAN ports can support an aggregate backup transfer rate of 140MB/s, which is approximately equivalent to 500GB/hr. Compared to traditional network backup performance, this is an enormously high number.
FC SANs are capable of supporting backup transfer rates of approximately 75MB/s over any supported link. An important design consideration is configuring the backup streams that will run over the individual SAN links. For instance, if there are 40 backup jobs running over four links through four storage router ports, you may want to try to distribute the backup load evenly, over time, across the four links. This creates the shortest overall backup process. Keep in mind that servers capable of using multiple SAN backup links simultaneously probably need to be Unix systems with powerful I/O capabilities.
Creating the model SAN
After you have some idea of the amount of backup traffic you are working with, it's time to construct an initial SAN model. The idea isn't necessarily to get it right, but to create a hypothetical system that you can use as a tool as you develop your plans.
The key pieces of the model SAN are the number of servers, switch
ports, router ports and tape devices you will use. One of the key outputs of the model SAN is an estimate for the cost. Netreon's SAN Designer is a software product that can help you build a model SAN complete with a parts list that you can use to start setting a detailed budget. Over time, a tool like SAN Designer saves you a lot of time as you tweak your SANs to fit changing requirements as they are identified.
Once the model SAN is created, you can start putting together an operations schedule for your LAN-free backup system. Building the backup operations schedule is probably the most difficult part of the project because it usually forces you to rethink some of your expectations about how the system will work.
The first step is to identify all the backup targets that will be part of the LAN-free backup system. A backup target can be a complete server or storage-volume/database-partition that can be managed as a discrete entity by your backup system. These targets are probably already identified in your current backup systems.
Now calculate the backup transfer rate (BTR) for each target. The BTR is determined primarily by the slower of the system backup transfer rate or the tape drive's transfer rate. Obviously, you first have to have some idea of type of the tape drive you'll use for each target. If you are using tape drives that support transfer rates of 10MB/s or greater, you may want to use a conservative transfer rate of 8MB/s for Intel systems.
Determining the backup window
As you may know, the backup window is defined as the starting time and ending time that a backup operation for a single target is expected to complete in. Setting realistic backup windows is critical for success for all backup systems, including LAN-free backup. Often backup windows are determined by the access characteristics of the primary applications running on a system. For instance, if an Internet server is expected to be used 24 hours a day, you might find the hours of least use are between 2 a.m. and 5 a.m., thus determining a three-hour backup window between 2 a.m. and 5 a.m.
Obviously, determining backup windows this way can be a problem if you have many backup targets, all with the same user access characteristics. The brute force, cost-is-not-an-issue approach is to build a large SAN with multiple storage routers and tape devices and run as many parallel backup streams as necessary. But cost probably is an issue and you shouldn't expect to backup more targets than the performance of your LAN-free backup system will allow. In that case, there's no choice but to shift the start times of some of your targets' backup windows.
An effective concept is to think of backup windows as time containers, similar to buckets that have set capacities. This allows you to think about managing LAN-free backup systems in terms of maintaining time capacity in the system. In the long run, this is probably the most effective way of maintaining a healthy and reliable backup system.
Be careful to avoid setting impossible backup windows. Backup windows should be determined conservatively using your estimated backup workload and target transfer rates so the backup operation can complete within the time prescribed by the window. If the backup window is too small, you have two options: find a way to subdivide the backup target and do the work in parallel - which may not be possible - or increase the backup window to something that's realistic. This isn't merely an exercise in making backup schedules work out, but it has a direct impact on the recoverability of your systems. You're better off re-calibrating your expectations for backup windows than you are having chronic incomplete backup operations constantly exposing your ability to recover.
The master backup operations
Next on your list is the creation of a master operations schedule. Consider this a work in progress: Any operation schedule is an iterative process - expect to make many adjustments as you fine-tune the process. Backup windows for all targets should be laid out chronologically by start time and end time - similar to a television broadcast schedule - so you can easily see the workload as a function of the clock. If you don't have a method for doing this, create a master backup schedule where the top row is a 24-hour clock starting and ending at 8:00 p.m, with 30-minute increments. Then assign a row in the schedule to each backup target and block out the backup window for the target. This schedule will have a lot of blank space because each row only contains a single backup window.
You'll want to make four derivative schedules from the master that analyze bottlenecks in other resources in the LAN-free backup system. The idea is to apply the SAN model you previously developed and then test its capacities against the master backup operations schedule.
The four derivative resource schedules you'll create are for SAN links, router ports, SCSI buses and tape drives.
This was first published in September 2002