This article can also be found in the Premium Editorial Download "Storage magazine: Storage managers reveal details on tape reliability."
Download it now to read this article plus other related content.
The traditional backup architecture
Before explaining how the different D2D backup options work, it's important to understand the backup systems they'll work with and why you might want to augment those systems with disk. In a traditional backup architecture (see Traditional backup architecture, this page), software resides on the backup client (the server to be backed up) that allows the backup server to transfer that client's data to tape, disk or virtual tape. The data may be transferred across the network (LAN-based), from the client directly to tape/disk across the storage area network (SAN) (LAN-free) or directly from primary storage to secondary storage across the SAN (server-free). In each case, the data is converted into a different format that's understood by the backup software running the backup. This format could be tar, cpio, dump, NTBackup or a custom format understood only by that particular backup package.
The biggest advantage of the traditional backup architecture is that it's well understood and mature. The biggest disadvantage is how it uses tape. It's difficult for a traditional backup system to use the streaming nature of modern tape drives efficiently. To properly stream tape drives, some backup software products (like EMC Corp.'s Legato NetWorker and Veritas Software Corp.'s NetBackup) send multiple backup jobs simultaneously to the same tape drive, a technique called multiplexing or interleaving. This technique helps backups but has a negative impact on the restore of a single backup; the backup software has to read the entire tape and disregard the data it doesn't need. Other backup software products, such as IBM Corp.'s Tivoli Storage Manager, solve the streaming issue with disk staging where backups are first sent to disk before they're sent to tape.
With the advent of lower-priced ATA-based disk arrays, however, everyone can take advantage of disk staging or disk-based backups without switching from a traditional backup architecture. You simply augment your tape library with a combination of disk and tape.
Disk backup options
There are four ways to augment your traditional backup system with disk. The first two options are called disk-as-disk because they involve using disk drives behaving as disk drives--the disks aren't pretending to be tape. In a SAN disk-as-disk configuration (see SAN disk-as-disk, this page), a disk array is connected to one or more backup servers via a SAN, and a disk volume is assigned to each server. Each server then puts a filesystem on that volume, and backups are sent to that filesystem. In a network-attached storage (NAS) disk-as-disk architecture (see NAS disk-as-disk, this page), the disk resides behind a filer head that shares filesystems via NFS or CIFS, and backups are sent to those filesystems.
The last two options employ virtual tape libraries (VTLs), where disk systems are placed behind a server running software that allows the disk array to pretend to be one or more tape libraries. Standalone virtual tape library, ( on this page) shows standalone VTLs that sit next to a physical tape library and pretend to be another tape library. Once you back up to a standalone VTL, you must use the backup server to copy its backups to physical tape if you want to send them offsite.
An integrated VTL (see Integrated virtual tape library, this page) sits between a physical tape library and a backup server, where it pretends to be a physical library. The backup server backs up to the integrated VTL, which then copies the data to the physical tape portion of its library.
When backup software backs up to a disk-as-disk system, it knows it's a disk and typically creates a file within the filesystem. To distinguish these backups from those sent to a tape (or virtual tape) target, some people refer to these types of backups as filesystem-based backups.
This was first published in February 2005