Sharing storage usually simplifies storage administration and adds flexibility since cables and storage devices do not have to be physically moved to move storage from one server to another. Note, though, that with the exception of SAN file systems and clustered computing, SAN storage is still a one-to-one relationship. That is, each device (or Logical Unit Number (LUN)) on the SAN is "owned" by a single computer (or initiator). In contrast, Network Attached Storage (NAS) allows many computers to access the same set of files over a network. The contrast between the SAN and NAS has been blurred with the creation of a NAS head.
SANs tend to increase storage capacity utilization, since multiple servers can share the same growth reserve.
Other benefits include the ability to allow servers to boot from the SAN itself. This allows for a quick and easy replacement of faulty servers since the SAN can be reconfigured so that a replacement server can use the LUN of the faulty server. This process can take as little as half an hour and is a relatively new idea being pioneered in newer data centers. There are a number of emerging products designed to facilitate and speed up this process still further. For example, Brocade Communication Systems offers an Application Resource Manager product which automatically provisions servers to boot off a SAN, with typical-case load times measured in minutes. While this area of technology is still new, many view it as being the future of the enterprise datacenter.
SANs also tend to enable more effective disaster recovery processes. A SAN attached storage array can replicate data belonging to many servers to a secondary storage array. This secondary array can be local or, more typically, remote. The goal of disaster recovery is to place copies of data outside the radius of effect of an anticipated threat, and so the long-distance transport capabilities of SAN protocols such as Fibre Channel and FCIP are required to support these solutions. (The physical layer options for the traditional direct-attached SCSI model could only support a few meters of distance: not nearly enough to ensure business continuance in a disaster.) Demand for this SAN application has increased dramatically after the September 11th attacks in the United States, and increased regulatory requirements associated with Sarbanes-Oxley and similar legislation.
Newer SANs allow duplication functionality such as "cloning", "Business Continuance Volumes (BCV)" and "snapshotting," which allows for real-time duplication of LUN, for the purposes of backup, disaster recovery, or system duplication. With higher-end database systems, this can occur without downtime, and is geographically independent, primarily being limited by available bandwidth and storage. Cloning and BCV's create a complete replica of the LUN in the background (consuming I/O resources in the process), while snapshotting stores only the original states of any blocks that get changed after the "snapshot" (also known as the delta blocks) from the original LUN, and does not significantly slow the system. In time, however, snapshots can grow to be as large as the original system, and are normally only recommended for temporary storage. The two types of duplication are otherwise identical, and a cloned or snapshotted LUN can be mounted on another system for execution, or backup to tape or other device, or for replication to a distant point.