This article can also be found in the Premium Editorial Download "Storage magazine: Tools for successful data migrations."
Download it now to read this article plus other related content.
Cisco's switch-based backup
Cisco Systems inc. recently announced its Fibre Channel (FC) MDS 9000 Storage Services Module (SSM) and SAN-OS 2.1 software--which includes support for Xcopy, or Extended Copy--to enable Network Accelerated Serverless Backup (NASB). With serverless backup, the server is removed from the backup process so it doesn't become a performance and reliability bottleneck.
Xcopy has been around for quite a while and is part of the SCSI command set, intended to enable copying data from one storage device to another without passing the data through a server. The notion of serverless backup is attractive because it offers faster backup speeds, lower server loads and less LAN traffic. Still, Xcopy hasn't been widely embraced by users. Users found that without backup software support, serverless backup had many problems that Xcopy didn't address (and still doesn't).
What Cisco has done that's different from the Xcopy support built into other storage products is to make deals with backup software vendors to support their hardware, so the backup software has access to the Xcopy protocols through Cisco's MDS 9000. Users still have to run their backup software, but it connects to the Cisco hardware and bypasses the server. However, Cisco's Xcopy approach isn't necessarily unique: EMC Corp. offers backup apps within its proprietary hardware/software that use Xcopy to the same effect, and other vendors--such as
|Different ways to move copied data|
Different ways to copyIn the traditional definition of serverless backup, the application server doesn't process data; it's moved directly from storage to backup from an FC storage array to an FC or SCSI backup device. The problem is that the backup application's ability to handle errors, as well as issues like tape changing in libraries, can't be handled through the Xcopy protocol.
Making a fast, block-by-block copy of a volume is useful, but not the only desirable backup strategy. Because Xcopy operates at the device level--it needs to be available in only one device on the SAN (switch or array)--passing blocks from one device to another, it isn't easy to make backup software aware of the Xcopy process. This means that each vendor must come up with its own method of supporting Xcopy.
Today, serverless backup is viewed as less of a panacea than it was a few years ago because replication-based backup is better for many apps. W. Curtis Preston, vice president of services development at Framingham, MA-based GlassHouse Technologies, says he knows of only a handful of companies that use Xcopy for serverless backup--most use replication.
However, Preston is a fan of serverless backup under certain circumstances. For instance, backing up a large database can be hard on the database server, so serverless backup may be the only way to make backups run faster. He also likes the idea of combining Xcopy with virtual tape libraries (VTLs) to copy data from disk to tape inside the virtual tape library. This can be done with existing systems, but the backup software isn't aware of the copy being made. If Xcopy was implemented in a VTL, a backup application would be aware of Xcopy and be able to use it intelligently.
This was first published in September 2005