|This chapter excerpt from Inside Windows Storage, by Dilip C. Naik is printed with permission from Addison-Wesley/Prentice Hall, Copyright 2003.|
A snapshot is simply a consistent point-in-time copy of a volume. Consistency in this case is defined as the original application's ability to recognize the data; for example, a Microsoft Exchange server sees a data set as a valid Exchange store, and a Microsoft SQL server recognizes a data set as a valid SQL server database. The data set being referred to here is typically a logical volume.
Volume snapshots are becoming increasingly popular and are used for various different reasons, such as the following:
* To back up a clone of a volume created with snapshot technology while the original volume continues to be used by applications. This is what Microsoft has done with the Windows XP volume shadow copy service, in which a clone of the original volume (at a given point in time) is constructed (assuming that enough free disk space is available) and used to perform backup operations.
* To create a clone of live data for use in a data mining operation.
* To create a clone of live data for testing a newer version of the application in a "live" environment.
* To create a clone of live data as part of a disaster recovery operation.
So how is a volume snapshot created? There are several possible ways, all of them essentially duplication of write operations. The only real difference in the solutions is where the write operations are duplicated. There are four possible locations:
1. In hardware. The first obvious way to create a volume snapshot is to have the volume mirrored by hardware and then split the mirror. With low-end hardware and purely host-based (softwarebased) volumes, each write operation is split into two duplicate write operations—one targeted at the original volume and the other targeted at the mirror. This approach is fairly resource intensive because both of the write operations must be completed before the write response can be sent. Write error operations also need to be handled. The advantage is that although it is resource intensive to keep a mirrored volume, breaking the mirror and thereby creating a volume snapshot is extremely fast. The high speed and reliability of hardware mirroring comes with a cost, though: the expense of the duplicate disks needed for the mirror. With high-end storage units, there is an extensive amount of per-track metadata because instead of the writes themselves being split, after the mirror split the writes are tracked in the metadata. Further, high-end storage units do not delay the mirrored writes, because the writes are declared complete once they hit the storage unit's battery-backed cache.
Above the file system. The second way to create a volume snapshot in the Windows Server family is to write a file system filter driver that sits above the file system driver -- for example, NTFS or FAT -- and duplicate each IRP (I/O request packet) sent to the file system driver. This process is rather complex and cannot easily take advantage of snapshot technology provided in hardware. Examples of products that implement such filters above NTFS include St. Bernard Open File Manager, Vinca (now LEGATO) Open File Manager, and Cheyenne Open File Agent. Note that these products do not necessarily implement snapshots.
3. In the file system itself. Moving down the driver stack chain, the third way to implement snapshots is in the file system itself. Network Appliance's WAFL (Write Anywhere File Layout) and the Linux SnapFS file systems are examples of products that implement such functionality. Obviously these are not products that run on Windows NT. Writing a file system is fairly complex, and writing snapshot technology inside a file system makes it even more complex. There is no such method available in the native file systems included with Windows NT.
4. Below the file system. The fourth way of creating volume snapshots in Windows NT is to have a filter driver beneath the file system use copy-on-write technology. The idea is that logical blocks that are changed by an application are first copied to a side store, before the application writes are committed to those logical blocks. This is illustrated in Figure 5.7. This technique is also referred to as differential snapshot because only the difference is stored (rather than a complete mirror image/copy being made).
WINDOWS BACKUP AND RESTORE TECHNOLOGIES
Tip #1: Reasons for backup and restore
Tip #2: Backup problems
Tip #3: Backup classifications
Tip #4: Windows 2000 backup utility
Tip #5: Techniques to create a volume snapshot
Tip #6: XP and Windows 2003 volume shadow copy service
Tip #7: Windows-powered NAS devices and snapshots
Tip #8: Network Data Management Protocol
Tip #9: Practical implications
Tip #10: Summary
About the author: Dilip C. Naik has more than twelve years of experience in various roles at Microsoft, including software engineer, program manager, and technical evangelist. His contributions include writing CIFS/SMB code, CIFS-related RFCs, code and documentation for the Windows NT Installable File System Kit, as well as Windows Management Instrumentation (WMI) and performance/management (including storage management) features for the Windows platform. Dilip has also represented Microsoft on a number of industry standards organizations.