Offhost Backups | Implementing Backup and Recovery: The Readiness Guide for the Enterprise

< Day Day Up >

Frozen Image Backups

The administrator faces many challenges today with backups, but one of the largest is determining how to finish the backup within the allotted backup window. One of the constraints on the backup window is the requirement to keep the database or filesystem fully available as much as possible. As we have just seen, the database agents make it possible to do hot database backups, but there is still a performance impact. Another way to address the requirement to backup data, especially data that resides in active volumes or databases with a minimal impact on the application, is to use some type of frozen image backup. A frozen image can best be defined as a stable disk copy of the client's data made prior to backup. Such a copy is important on active filesystems and databases, where updates to files or tables can occur at any time. In such cases, making a stable, consistent copy (frozen image) is a prerequisite to making a correct backup. A frozen image is created very rapidly, causing minimal impact on other applications. There are two basic types: copy-on-write snapshot and mirror.

Copy-on-Write Snapshot

A copy-on-write snapshot is a detailed account of data as it existed at a certain moment. Unlike a mirror, which we discuss next, it is not really a copy of the data, but a particular 'record' of it. The copy-on-write snapshot process works as follows:

When a frozen image is required, any unfinished transactions or changes to the source data are allowed to complete, but new changes are temporarily stalled.
The source is momentarily idled (made quiescent), and a snapshot driver is injected into the host operating system.
Once the snapshot driver is activated, new transactions or changes (writes) to the source data are allowed to take place. However, the snapshot driver briefly intercepts or holds the write requests. While holding those requests, it copies to cache any blocks that will be affected by those writes and keeps a record of the cached blocks.

In other words, the snapshot driver reads each source block that is about to change, copies the block's current data to cache, and records the location and identity of the cached blocks. Then the intercepted writes are allowed to take place in the source blocks. The immediate results of the snapshot are as follows:

A cached copy of those portions of the source that were about to change at a certain moment
A record of where those cached portions (blocks) are stored

The copy-on-write snapshot does not produce a copy of the source; it creates cached copies of the blocks that have changed and a record of their location. The backup process refers to the source data or cached copy of the data as directed by the snapshot driver. An accurate backup image is obtained by combining the unchanged portions of the data with the snapshot cache. When a backup of the snapshot frozen image begins, the backup application copies the source data until it comes to a block that changed after the snapshot driver was activated. The snapshot driver tells the backup process to skip that changed block and read in its place the cached (original) copy. The backup application continues copying source data until it comes to another changed block. Cache is read again as the snapshot driver dictates. The backup, when finished, is an exact copy of the source as it existed the moment the snapshot driver was activated.

Different kinds of snapshot backups are available. VERITAS Software's NetBackup offers a copy-on-write snapshot using a proprietary snapshot driver called nbu_snap that works with either Sun Solaris UFS filesystem or VERITAS Software's VxFS filesystem. It also supports filesystem clones, which is a feature of VxFS.

Another backup challenge that can be helped with snapshot backups is the backup of a filesystem that contains hundreds of thousands or millions of small files. Doing a standard backup of such a filesystem using the standard operating system commands is very time-consuming. Just to traverse the filesystem building a list of all the files takes a lot of time. The best way to back it up without using snapshot technology is to do the following:

Unmount the filesystem.
Perform a raw backup of the filesystem.
Remount the filesystem.

There are some disadvantages to doing this kind of backup:

The filesystem is not available during the entire time of the backup.
All backups are full backups.
All restores are full filesystem restores. Single file restores are not possible.

The better option for backing up this kind of data is to use a snapshot backup. An example is the NetBackup FlashBackup option. With this technology, you have the advantages of the raw backup without the penalties. This is a copy-on-write snapshot technology using a proprietary snapshot driver. This feature is available for the following filesystem types: Sun Solaris UFS, VERITAS Software's VxFS on Solaris or HP-UX, and Online JFS on HP-UX. For backups, FlashBackup creates consistent, point-in-time backups at the file level. In the event of a restore, it uses file mapping created during the snapshot to restore single files or directories. It also enables administrators with millions of files to conduct backup and restore operations by using a combination of file mapping and snapshot technologies.

The advantages of using a technology such as FlashBackup over standard filesystem or raw backups are as follows:

It provides increased performance, especially if the filesystem contains a very large number of files and most of the filesystem blocks are allocated.
It allows individual file restores.
The volume or filesystem remains mounted.
It supports multiple data streams.
It supports full and incremental backups.

Mirror

A mirror is a complete data copy on a separate disk, physically independent of the source. Every change or write to the source data on the primary disk is also made to the copy on the secondary disk. This creates a mirror image of the source data. As with a copy-on-write snapshot, when a frozen image is required, transactions are allowed to finish and new I/O on the primary disk is briefly halted. When the mirror image is brought up-to-date with the source (made identical to it), the mirror is split from the primary, meaning that new changes can be made to the primary but not to the mirror. At this point, the mirror can be backed up.

Since mirroring requires an exact, complete copy of the primary image, it consumes more disk space than a copy-on-write snapshot. The data can exist in a disk management software mirror, such as VERITAS Software's VxVM mirrors, or it can exist on a disk array controlled by the array-specific mirroring software, such as EMC TimeFinder, Hitachi Data Systems ShadowImage, HP-UX BusinessCopy, IBM FlashCopy, and others. At the end of the backup, the split mirror is rejoined with the primary mirror and the mirrors are resynchronized. Some backup applications, such as NetBackup, allow you to run with the mirrors split and resynchronize the mirrors just prior to backing up the data. This is a plus for those people who like to synchronize the mirrors once a day and then run with the mirrors split.

BACKING UP THE MAIL

No doubt there are many examples of customers using frozen image backups to handle applications such as mail. We know of one in particular that was using a UNIX system and had the challenge of backing up 4.2 TB of data that was across several filesystems and contained 82 million files. A standard filesystem backup of this data was taking 27 hours. After implementing NetBackup FlashBackup, they could finish their backups in 8 hours. In another case where the backup was for Netscape mail, the standard backups were taking 48 to 60 hours for full backups, and incremental backups were taking 24 to 36 hours. After FlashBackup was implemented, the full backups were completed in 15 to 20 hours, and the incremental backups were in the 9- to 12-hour range.

< Day Day Up >