8.3 Cloning, snapshots, and lies

 < Day Day Up > 



The traditional approach to backups saves an offline or online copy of data to tape. Tape throughput, better software, and increased automation have all improved and increased the ability to manage backups, but the amount of data to be processed has increased at a faster rate. The tape drives and libraries deployed to back up Exchange 5.5 servers with 10-GB Mailbox Stores may struggle to handle the demands of a modern Exchange server with multiple large databases. If you cannot back up your databases in a reasonable time or, more importantly, quickly restore your databases from a backup set should a disaster occur, then you inevitably need to limit database sizes. Limiting database size then restricts the number of mailboxes you can support on a server or limits the size of the mailboxes you can provide to users. Given that most users struggle to cope with a small mailbox, especially in corporate environments, and that administrators want to consolidate small servers into larger servers, we need a way to back up and restore large databases as quickly as possible. This has been a requirement since Exchange 5.5 lifted the 16-GB limit for a database, and the need has become increasingly urgent as servers become more powerful and storage costs decrease.

Backups to disk are always faster than tape and you can use disk instead of tape if that is your preferred backup medium. However, it is difficult to keep enough free disk space available to process backups, so it is unusual to find this implementation. Volume cloning and snapshots-sometimes referred to as "hot backups"-have attracted a lot of attention in the last few years. The marketing term for cloning is Business Continuance Volumes (BCV), which describes the intention behind the technology: reduce the possible downtime due to data unavailability to a minimum. Up to now, you need to deploy specific storage technology to be able to take snapshots, and some limitations exist in application support. Now, the availability of Volume ShadowCopy Services (VSS) in Windows 2003 brings this technology into the mainstream.

Clones and snapshots use different mechanisms to duplicate data so that you can create point-in-time copies. Clones are physical copies of data and are based on RAID 0+1 technology, so the technology to create a clone has been in storage architectures for a long time. You create a clone by establishing a new member of a RAID 0+1 mirror set so that the controller duplicates any data written to the mirror set automatically to all member drives. To create the clone, you split one of the members from the mirror set. The application can continue working, because the mirror set still exists and you can proceed to back up the newly created clone to create a backup save set for long-term storage. When the backup is complete, you can then reintroduce the drive into the mirror set to restart the cycle. Clones hold a complete copy of the data on a volume, so you can use a clone to very rapidly recover data should the need arise. The right-hand pane in Figure 8.3 shows the concept in action after you split off the clone from the mirror RAID set containing production data.

click to expand
Figure 8.3: Snapshots and clones.

As its name implies, a snapshot is a point-in-time picture, or mapping, of the physical blocks on a volume. You can also think of a snapshot as a logical copy of data. When you create a snapshot, the blocks mapping the original file on disk are maintained, and the snapshot is created from a combination of the original blocks (the starting point) and any blocks of data that hold data that has changed since. The left-hand panel in Figure 8.3 illustrates how a snapshot is built from original and changed blocks.

Implementing hot backup technology is not simply a matter of plugging in appropriate storage technology. Storage systems commonly support many operating systems, so they include the necessary hardware and firmware support for cloning and snapshots. The operating system then implements the necessary support within its file system and drivers and then applications come along to take advantage of whatever they can from the new facilities. Applications include backup utilities as well as the applications that generate data. A complex collection of relationships and dependencies needs to come together before you can truly generate and depend on hot backups.

The Exchange developers knew that Windows would eventually include the necessary support for hot backups, so they never sought to build their own implementation into the Exchange backup API or ESE. From 1997 onward, storage vendors decided not to wait for Microsoft and began to build their own implementations. These solutions enabled pseudo hot backups for both Exchange 5.5 and 2000 by working around the essential fact that the Store is a transactional database with no way to become fully consistent unless it shuts down. Some solutions addressed the problem by closing down the Store process before they take a hot backup. This forces the Store to flush any outstanding transactions and creates a consistent version of the database on disk. The normal flow is to break the mirror set as soon as the Store process shuts down, followed by a fast restart of the Store process to restore service to users. You can then mount the disk that contains the clone on another server and begin a tape-based backup to take a copy of the database. Users usually do not notice the interruption in service if you schedule it early in the morning or at a time of low demand. The time taken to close down the Store, break the mirror set, and restart is a matter of a few minutes, and these operations are usually automated through vendor-provided scripts that can handle backup and restore operations.

Recent variations on this theme involve breaking the mirror set while the Store is still running and then taking a backup of the database copy plus all its transaction logs. While this technique works-most of the time-it exhibits inherent flaws, because the Exchange Store does not support backups made in this manner. In effect, what you are doing is creating a backup of an inconsistent copy of the database from disk. In this scenario, the database copy is always inconsistent, because the Store has not had the chance to commit outstanding transactions, so you rely on the roll-forward capability to capture transactions in the logs whenever you need to make the database consistent-if you ever need to restore and use this copy of the database. In addition, because you halt Store processing in a very abrupt manner, there is no guarantee that the internal structures are intact, because you never know what the Store was doing at the exact moment that you take the hot backup. Finally, unlike normal backups, the Store does not perform checksum validation on pages as it writes them out to the backup media, so you could easily take a copy of an already corrupt database and make it even more corrupt. It is not surprising that Microsoft does not support this technique for Exchange 2000 and leaves any support issues that occur, such as recovering a corrupt database, to the vendor that supplied the storage, scripts, and other technology used to take the backup. If you insist on using such a method to take backups, you should also take frequent full tape backups, so that you are sure that you always have something to recover. Or, even better, upgrade to Windows 2003 and Exchange 2003 and find storage and backup vendors that support the Volume ShadowSet- Copy Services API and take proper, fully supported hot backups.

Once you have split a mirror set to create a copy of the database, you need to take a file-level backup to copy the data to tape. In this respect, backups take roughly the same amount of time as they would when you take an online backup of the Store, but restores can be dramatically faster if you can use an on-disk copy of the database. For example, tests performed by HP using its Rapid Restore Solution for Exchange demonstrated that it is possible to restore a 41-GB storage group (two Mailbox Stores and one Public Folder Store) in 6 minutes from a clone, compared with 1 hour 45 minutes from tape. Clearly, restoring a database or storage group takes the same amount of time if the disk clone is not available and you have to use the tape backup.

There is no doubt that hot backups work when properly implemented and integrated into a backup and restore plan. Everything works extremely well at the storage hardware level and all of the issues occur with the application. Exchange knows nothing about the hot backup, because you must stop the Store to remove the clone of the database. The other problem is the variety of approaches and implementations taken by vendors, because they build off their own platform. This is not a problem when you always work with a single technology, but it can be a problem where different groups deploy a variety of technologies inside a large organization.

8.3.1 Volume ShadowCopy Services

VSS provides the necessary architecture for application and storage vendors to support hot backups using a common API. VSS incorporates application synchronization (how to control the taking of a hot backup), discovery and listing of shadow copies (both clones and snapshots), and a plug-and-play framework for backup components from different vendors.

Vendors use the VSS API to develop provider processes that maintain data about physical clones and snapshots and can expose them to the operating system and applications. VSS processes can contain kernel-mode (device drivers) and user-mode code (the user interface and processing to take a hot backup). Windows 2003 contains a software-based VSS provider as part of the operating system. Storage vendors such as HP and EMC have hardware providers to allow their storage technology to participate in VSS backups.

In addition to VSS providers, vendors also develop VSS requesters. These applications coordinate the processing required to take a backup or perform a restore. VSS providers and writers do the actual processing to create a backup or perform a restore. Typical processing incorporated in a requester includes the identification of the volumes to include in a backup, requesting data from different writers (Exchange, SQL, Oracle, other applications), and communication through a user interface. You can think of the requester as the center coordination point for hot backup operations. It has to communicate with the applications to ask them to provide data and with the providers to identify how to back up the data from volumes under their control. Traditional backup applications such as Legato and Backup Exec are likely VSS requesters.

In VSS terminology, the applications that control data permit writers to allow VSS requesters to include data from the applications in shadow set copies. Exchange 2003 is the first version to support VSS and incorporates the necessary support to be a VSS writer in the Store process. Each application controls its own data and may use dramatically different ways to access and maintain that data, but this complexity is hidden from requesters by the ShadowCopy interface, which ensures data integrity and consistency across applications. During ShadowCopy processing, application writers perform operations such as prepare (get data ready for processing), freeze (prevent writes while processing proceeds), thaw (allow I/O to begin again), and normalize (complete operations). Each writer defines its needs through a set of XML metadata that the requester can interpret and process during a backup or restore operation. For example, the metadata published by Exchange 2003 includes details of the databases and storage groups to include in an operation (the components), whether a reboot is required after the operation completes, what type of restore operations are possible, and so on.

The fact that the VSS framework exists means that a common way of implementing hot backups exists, but you must upgrade many components before you can take hot backups. The storage hardware, operating system, applications, and backup software must work together, so it is important that you have the correct versions installed to make everything work.

8.3.2 Using VSS with Exchange 2003

Assuming that you have the right combination of backup software and hardware, you can plan to incorporate snapshots into your backup strategy. VSS backups for Exchange are always taken at the storage group level, so a full VSS backup contains the complete set of databases in the storage group and the transaction logs, and the log set is truncated (old logs are deleted) after a successful backup. Exchange also supports VSS copy backups at the storage group level, with the major difference being that the transaction logs are not truncated. Incremental and differential backups only copy transaction logs, and, once again, everything is done at the storage group level, with the difference being that the logs are either truncated (incremental) or not (differential). Exchange writes the information about the components assembled into the backup in an XML document that it then provides to the VSS requester, which then proceeds to copy the information stated in the document.

In a restore situation, the backup application is only responsible for extracting information from the backup and restoring it to disk. The Store is responsible for making the database consistent through log replays using the normal soft recovery process, which the Store initiates when you remount databases after recovering them from a backup set.

You should view snapshots as complementary to tape backups, but not as a complete replacement. Streaming to tape retains some advantages that snapshot backups do not have. For example, the Store calculates a checksum for each page as it streams data out to the backup media, but obviously this does not happen when you take a snapshot. The same is true for empty page zeroing (or scrubbing), which the Store can do as it processes pages during a backup, but it cannot be done for a snapshot. As long as you are confident that your databases are in good order, you can proceed to take snapshots with confidence, but it is still a good idea to take an old-fashioned tape backup from time to time, just to be sure.

Software and hardware vendors are likely to collaborate to create special packages to handle VSS-based Exchange backup and restores in an automated manner. Because every hardware and software backup vendor will now use a common API to take hot backups, the benefit in these packages comes from the ease and speed in which the software and hardware combination processes backup and restore situations. Before buying any solution, investigate how easily it handles various disaster recovery situations, such as corrupt databases or logs, as well as the routine of daily backup operations. If a disaster occurs, you will be grateful if the solution automates the entire recovery process instead of leaving you to figure out how best to restore service.



 < Day Day Up > 



Microsoft Exchange Server 2003
Microsoft Exchange Server 2003 Administrators Pocket Consultant
ISBN: 0735619786
EAN: 2147483647
Year: 2003
Pages: 188

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net