SQL Server Backup and Restore - Simple Talk

Chapter 2: Planning, Storage and Documentation
My experience suggests that advances in controller architecture along with increases in
disk speed and cache storage have "leveled the playing field." In other words, don't worry
overly if your read-heavy database is on RAID 10, or a reasonably write-heavy database is
on RAID 5; chances are it will still perform reliably, and well.
Network device
The last option for storing our backup files is the network device. Having each server
backing up to a separate folder on a network drive is a great way to organize all of the
backups in one convenient location, which also happens to be easily accessible when
dumping those files to tape media for offsite storage.
We don't really care what form this network storage takes, as long as it is as stable and
fault tolerant as possible, which basically means RAID storage. We can achieve this via
specialized Network Attached Storage (NAS), or simply a file server, backed by physical
disks or SAN-attached space.
However, as discussed earlier, backing up directly to a network storage device, across a
highly utilized network, can lead to latency and network outage problems. That's why
I generally still recommend to backup to direct storage (DAS or SAN) and then copy
the completed backup files to the network storage device. A good solution is to use a
scheduled job, schedulable utility or, in some cases, a third-party backup tool to back up
the databases to a local drive and then copy the results to a network share. This way, we
only have to worry about latency issues when copying the backup file, but at least at this
stage we don't put any additional load on the SQL Server service; if a file copy fails, we
just restart it. Plus, with utilities such as robocopy, we have the additional safety net of
the knowing the copy will automatically restart if any outage occurs.
58