Ntbackup.exe supports backup to disk as well as to tape, and snapshots and cloning are two approaches to disk backups. You can take a snapshot in seconds rather than in hours (which tape-based backups of large databases often require). However, you need sufficient disk space to store the snapshot, which usually equals the size of the database that you back up. Also, Exchange 2000 Server doesn't offer native support for snapshots or clones.
A snapshot is a logical copy of a disk volume—think of it as a physical copy of the block map that maps a RAID volume's logical blocks to the physical blocks on the volume's disks. You can use the snapshot as a separate LU (and therefore as a separate Windows 2000 device) that points to the original physical disks. You can implement a block map at the OS or RAID-controller level.
Cloning, which other OSs have offered for well more than a decade, is a simple idea: Add a mirror member to a volume, let the OS update the member so that it contains the same content as the volume, then break the member out of the mirror set. The result—an exact physical copy of the volume—can contain one or more databases. If you lose the original database, you can swap in the cloned copy and replay the transaction logs to recover data, then bring the restored database online.
Exchange databases tend to be large, so aside from the disk space these methods require, using snapshots or clones to speed backups has obvious advantages. In addition, because a snapshot is a true image copy of the database, you have a reasonable guarantee that the copy will be good and will let you recover all the data. A tape backup can write bad data to the tape or can prove unreadable during a restore. You can use snapshots or clones to recover individual mailboxes or public folders that have been deleted through administrative error but only after you move the snapshot to a recovery server.
Be aware, however, that Exchange 2000 requires the Store databases to be quiescent (i.e., in a consistent state) before you can take a snapshot or database clone because Exchange 2000 doesn't support a backup API extension to take a point-in-time snapshot. Some backup solutions achieve quiescence by temporarily dismounting the database to force the Store to commit all outstanding transactions. Usually, the backup vendors provide scripts that drive these operations so that they flow with minimal operator intervention. The big problem with this scenario is that users lose connections to the Store while the script runs, although you can mitigate that problem by scheduling snapshots at times of low user demand. Some solutions take snapshots by splitting off one drive in the mirror set. However, the Exchange 2000 Store isn't designed to provide good backups through mirror splits or cloning, and the drive that you split off might not contain a good copy of the database, so my advice is to avoid solutions that use these methods. In fact, if you want to take true hot backups, consider deploying Windows Server 2003 and Exchange Server 2003—which provide Microsoft Volume Shadow Copy Service (VSS), a standard API that lets applications enable snapshot support—and VSS-aware backup hardware and software—which are necessary to support VSS backups and restores.
