IT managers have been struggling with the constantly shrinking backup window for years. A common way to address this issue is to purchase bigger, faster tape libraries.
This solution becomes large and expensive very quickly and can be quite complex to manage. My last four columns discussed disk-to-disk backup solutions as a way of reducing backup windows. While a disk-to-disk device can make a larger impact than a tape-based alternative, it is still just more of the same.
Adding disk-to-disk is really just adding a really fast tape library. While this may be good enough for many environments, there is a better way; there is no need to suffer with clunky, multi-hour backup windows.
A typical nightly backup of a server (such as a database server) looks something like this: At the scheduled time for the backup, the backup server executes a script on the database server which either shuts the database down or puts it in some sort of “hot backup” mode (seconds to minutes).
The backup server then backs up the database server’s data to a tape device (usually hours). The database is restarted or taken out of hot backup mode (seconds to minutes).
The time needed to complete these three steps is called the backup window. Steps one and three take very little time. The majority of the backup, step two, can take many, many hours to complete.
This is the step that IT departments throw hardware at to fix; bigger, faster tape libraries in an attempt to minimize how long this step takes.
A logical step in decreasing the backup window is to consider backing up production data to disk. This allows backups to finish far faster than backing up to tape and more importantly, recovering data is dramatically faster.
Tapes for offsite storage can be created by copying the data to tape after the backups are complete. Virtual libraries, devices that have large pools of Serial ATA (SATA) disks and emulate tape libraries, are becoming more popular. They are so popular because they are very fast and require nothing special on the backup server to work; they integrate seamlessly into the existing backup environment.
Another option is to add additional licensing or software to the backup server and direct the backups to a pool of disks. Both solutions are excellent options to add to a backup environment, but while they will reduce step two, they will not eliminate it.
The only way to come close to eliminating step two is to implement some sort of snapshot technology.
A snapshot is a point-in-time copy of the original data. Snapshots can be considered a disk-to-disk backup solution because they are stored on disk. With a traditional backup, the database is in degraded mode (hot backup mode) or is shut down completely for long periods of time; frequently for several hours.
With snapshot technology, the database is only impacted for a few seconds. It usually takes longer for the database to shut down or enter hot-backup mode than it takes to perform the snapshot.
Snapshots are so powerful because a database can be snapped in seconds, the database returns to normal operation and then the data can be archived to tape at any time by simply mounting the snapshot directly to the backup server.
A backup that takes advantage of snapshots looks like this: At the scheduled time for the backup, the backup server executes a script on the database server which either shuts the database down or puts it in some sort of hot backup mode (seconds to minutes).
A snapshot is taken of the database data (seconds). The database is restarted or taken out of hot backup mode (seconds to minutes). The snapshot is backed up to tape at any time.
Step two has been virtually eliminated. Backing up the data to tape may still take hours to complete, but the database is neither in hot backup mode or shut down while it occurs.
There are, essentially, two types of snapshots:
Pointer-based. A pointer-based snapshot is not exact copies of the data but a set of pointers that point to the original data. As the original data is written to, the changed blocks are written to a reserve area (another section of disk used to hold changes) and the pointer moved to that block; this process is called “copy on first write.”
Subsequent writes to the original data are not copied to the reserve area because the original data has already been moved.
One of the most attractive aspects of a pointer-based snapshot is that the snapshot reserve area needs just a fraction of the original disk space, since only the changed blocks are copied. Because pointer-based snapshots require such a small amount of space, they can be taken more frequently at a low cost.