Problem solve Get help with specific problems with your technologies, process and projects.

Implementing a SAN for backup

What are the issues, trade-offs and considerations I should understand in planning and implementing a SAN based backup and recovery strategy for my organization?

Actually, implementing a SAN for backup is the most useful advantage of using FC. I get the feeling you have some experience with SAN and FC. One big advantage of using SAN as the backup transport is the low latency of the protocol FC. You could use Gigabit Ethernet and achieve good performance (~87,5 MB/sec). The problem is protocol translation (SCSI to IP and IP to SCSI), which is normal in a centralized backup environment with a dedicated backup server. In a SAN you don't have the error correction overhead like TCP (Transmission Control Protocol). FC is the best from both worlds. So, in a SAN you really get the better performance (100 MB/sec) and no protocol translation. The CPU is offloaded and your applications perform better.

If you only will use your SAN for backup and don't have the intension of hooking up your primary storage in the near future, I really suggest that you build this SAN with hubs. That, off course, depends what budget you have for this project. You need HBAs for your servers (it's like a SCSI adapter but it talks FC), you hook this HBA to a FC hub. The library connects to a bridge (FC > SCSI converter) also called an MDR modular data router. Most often with two SCSI channels supporting two drives per SCSI channel. The library is equipped with a SCSI interface card for library control; you chain this with one of the drives. You need to think about start up sequence in this environment. Start your library, MDR, HUB, and server. It's very important, otherwise it would not work.

When it comes to backup applications my advice is to use some of the more well-known applications like Legato NetWorker or Veritas NetBackup. All your servers will see the library as a "Direct Attached" Storage device, which means you need a mechanism for the media control. It's like a "traffic cop," making sure request of tape devices get prioritized correctly.

Just because you build this backup SAN, it doesn?t mean you have to connect every server to it. Every server is a "backup server" you have the possibility to make backups true on these servers over your ordinary LAN. One off the biggest reasons for the need for speed is "backup window" so if you have servers with little data, back them up through the LAN.

When it comes to restore you get the same performance. But just because you have a nice performance on your SAN, it doesn't mean your backup and restore speeds up. You need tape devices with higher speed too. Today you have LTO from IBM, 9840 from StorageTek, S-DLT from Quantum. S-DLT will be available for libraries very soon.

When the time has come and all of your storage is connected through a SAN it will be possible to do server free backup, moving data directly from disk to tape. Today this technique is far from ready. I'm still waiting. In the meantime use the benefits of a SAN today (LAN less backup).

The conclusion of this article is "Think big, build small."

Daniel Hogberg

Dig Deeper on SAN technology and arrays

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.