Backup on a budget

ANALYSIS At a recent Dell CIO briefing (concerning Dell's recent agreement with EMC to sell storage), I was reminded of my own past struggles to find affordable -- and high performance -- storage options. One instance in particular was especially rewarding. If Storage Area Network (SAN) technology hadn't been too expensive and Network Attached Storage (NAS) had had higher performance levels, my team never would have had the incentive to create the high-capacity backup solution that we did. Here is how we did it. A little background
As the IT manager for a global software company, I was always under pressure to improve performance and reduce costs. Since my company had standardised on leasing equipment, I was always looking for three-year solutions that matched the lease terms of our equipment and solutions that provided vendor support for the same period. The existing lease was ending and I needed to look for our next three-year solution. Our file storage requirements were large, growing, and critical, especially for functional areas like Product Development, which needed a flexible system for storage of multiple product releases and work in-progress. The file system had to be 100 percent available, secure, and I needed restores to be quick. The existing solution had been Novell 4.11 using two HP servers with manual failover and a cabinet full of disk arrays using RAID 5 with storage of about 200 gigabytes and projections to double every two years. Application servers usually required 20-100 gigabytes and were stored locally. We did backups using Veritas across a 100-megabit network with two servers and a host of DLT drives. We did them at night and the backup times started to exceed the backup windows on given days, which affected performance for users. The environment called for full backups in order to do more easily the kind of restores that were necessary. I learned that a key element in making the backup windows was that the tape drive had to run full speed without stopping to wait for data. The drives had to be fed data as fast as they could accept it. This is where our then-current solution fell short. Deciding on and building the solution
Before I started the storage and backup project, I talked to several vendors. Their solutions were attractive -- I really liked their backup solutions and fiber channel speeds, but they were just too expensive. I asked my team why we couldn't develop our own high-speed backup network and rely on more conventional storage from Dell, especially since Windows 2000 clusters were available, fast, reliable, and administratively strong with Active Directory. It seemed to me that we could also utilise low-cost disk arrays that could handle incremental storage requirements and use low-cost copper gigabit networking. I knew that even if we were inefficient by using the continued decentralised disk storage solution, we could meet performance needs at a fraction of the cost of any SAN available at the time. My team went to work and researched various solutions with our partners. As the team was building the solution, we faced several obstacles. Isolating the backup network required some tweaking and we found the solution worked for everything except the Exchange Server and the Active Directory Domain servers. The Exchange 2000 cluster was set up as "active failover," and we had to back it up on the front-end network. It also required its own active restore server in the Domain with its own dedicated DLT tape drive. The Domain controllers also had to be backed up on the front-end network because the multiple IP addresses caused problems on the public network.