SQL Server Backup and Restore - Simple Talk

Chapter 2: Planning, Storage and Documentation
The reason I offer the option to write the backups to local storage initially, instead of
straight to network storage, is that it avoids the bottleneck of pushing data through the
network. Generally speaking, it's possible to get faster write speeds, and so faster backups,
to a local drive than to a drive mapped from another network device, or through a drive
space shared out through a distributed file system (DFS). However, with storage networks
becoming ever faster, it is becoming increasingly viable to skip Step 1, and back up the
data and log files directly to network storage.
Whether you write first to locally attached storage, or straight to a network share, you'll
want that disk storage to be as fast and efficient as possible, and this means that we want
to write, not to a single disk, but to a RAID unit, provided either as DAS, or by a SAN. We
also want, wherever possible, to use dedicated backup storage. For example, if a particular
drive on a file server, attached from the SAN, is designated as the destination for our SQL
Server backup files, we don't want any other process storing their data in that location,
competing with our backups for space and disk I/O.
Local disk (DAS or SAN)
Next on our list of backup media is the local disk drive. The main benefit of backing up
to disk, rather than tape is simply that the former will be much faster (depending on the
type and speed of the drive). Of course, any consideration of local disk storage for backup
files is just as relevant to the storage of the online data and log files, since it's likely that
the initial backup storage will just be a separate area in the same overall SQL Server
storage architecture.
Generally speaking, SQL Server storage tends to consist of multiple disk drives, each
set of disks forming, with a controller, a Redundant Array of Inexpensive Disks (RAID)
device, configured appropriately according the files that are being stored.
52