Creating a system backup network

Most corporate networks have moved to a network based backup infrastructure for performing data backup to another storage media (most of the time it is sent to tape). Before network based backups, systems were connected via a SCSI connection to a tape drive. There are many obvious advantages to making the shift to backing up over the network - however, there are some considerations to be aware of.

Most backup schedules run jobs during 'off hours', when the servers are not as busy. This is good for the network also, since you don't want to interfere with the traffic generated from doing business during peak usage times. However, there really is never a time the network availability is not important. Nor is there a time when it's ok for the network to be degraded. So, even during non peak times, we don't want to interfere with what I'll call primary traffic. Here are steps to take in order to ensure the different traffic types don't affect one another.

The goal here is to separate the system backup traffic from everything else. Starting with the host:

Use a dedicated network interface for system backup use. This NIC will be assigned an IP address from a subnet dedicated just for this use. This interface will not have an associated default gateway. Generally speaking, a system should always have only one default gateway, which is associated with the primary interface. In regards to routing system backup traffic (if required), that will be addressed later in this article.

Regarding the network design, ask a couple of questions first before getting started with the design:

  1. Do I have dedicated network hardware to run the backup network?
  2. Do I have multiple sites that need to talk back to a 'centralized' backup device?

Dedicated hardware in most cases would be unlikely. However, if you have a single site that had the cabling available and the budget to buy dedicated switch hardware - this is the way to go. The rest of this article will continue down the path of logical separation, in which vlan(s) will be created to run just the backup traffic.

First create a vlan id that will be assigned to this logical network. Assuming the network has the ability to configure private vlans, use this technology to protect 'backdoor' access from one host to another via the system backup interfaces. This article explains how to setup private vlans or even an alternative solution if you have older Cisco switch hardware.

Once you have layer2 isolation using one of the protected port/private vlan methods, the next step is to determine if this traffic will need to be routed. If you have only one building or physical network, chances are no layer3 interface will be needed and it will just remain a flat, non-routed network

If you have mutliple networks seperated by a wan and the 'master' backup server is at a central location, then at least some portion of that network will need to be routable. Typically in an enterprise backup environment you have two types of servers that make up the solution. One type is the 'Master' server and the others are 'Media' servers. The media servers are what is directly attached to the stoarage media and does the backup over the network from each host. The master server talks to the media servers to send them backup schedules, synchronize catalogs, submit jobs, etc. So, the traffic from the Master to Media servers are minimal, with the bulk of the network utilization being between a system being backed up and a local media server.

Most of the time, the systems being backed up will have no reason to talk to any centralized master servers, which means no routing will ever take place between the dual-homed systems being backed up. However, if there is a need like a centralized media server backing up manageable amounts of data over the wan, you want to use static, persistent routes in the hosts being backed up. By doing this, you tell the systems to only use a gateway on the system backup network to talk to a very specific destination.

Regarding the layer3 security needed for the backup network, use extended access-lists on traditional routers or vlan access-lists on layer3 switches that support it. The access-list should be placed on every system backup layer3 interface in your network. The access list will basically only allow the backup networks to talk to each other - denying everything else. This will ensure an unauthorized host on the system backup network can't reach primary networks used to carry other traffic.

One of the most important things to be on the lookout for is port speed/duplex mismatches. This one area will be the source of your pain the majority of the time when the backup administrators complain about backup throughput.

There are some other tweaks that can be done once your system backup network is up and running. Jumbo Frame support would be one of my first recommendations. You can squeeze another 20% increase in backup and restore speeds on just this modification alone. However, be sure to plan this out carefully if you intend to implement jumbo frames - the network must support this end to end or traffic could wind up being dropped.

Best wishes in your pursuits of building a backup network architecture!