If you find the inner workings of Exchange data backups using Volume Shadown Copy (VSS) a bit mystifying take comfort in not being alone. Administrators may ask, What s all the freezing and thawing I m seeing in my event logs? What is the Exchange VSS Writer really, and what is it doing to my databases? How does it create a snapshot of a 685GB database in less than 65 seconds? If you ever asked these questions but only felt more confused with the answers, here s a guide to clear some of that up. To understand how a VSS backup of Exchange works it s critical to understand the basics of VSS itself. There is some excellent documentation on TechNet and MSDN on this, as well as the Windows Server Core Team blog, My esteemed colleague Randy Monteleone sums up the basics of VSS very nicely early in his post, while also providing links (repeated here) to some good TechNet primers on VSS: If you re already familiar with at least the basics of VSS, then look forward to Part 7 in this series, where we will break down the events that occur in a VSS Exchange backup, and how Exchange logs them in the application event log.Av Hookups owensboro ky
Everything you need to know about conference championship
If you need a quick primer or refresher on VSS basics and the Exchange Writer I ve condensed them into some visual points below to complement the references above. Bear in mind that VSS solutions for Exchange, and for all applications, vary greatly between different hardware and software configurations. There are clone and COW snapshots, hardware and software solutions, just a very wide variety of technologies based on the core VSS subsystem. For the purposes of understanding Exchange backups we re only going to illustrate one specific type of solution out of the multitude. Detailed below is what s called copy-on-write, or COW snapshots. In a COW snapshot-based VSS backup of Exchange we have the creation of snapshots of the disks where Exchange data is hosted. No matter what is getting backed up, even if it s a single database file and a few logs, VSS creates a snapshot of the entire disk where any data is stored. So what is a snapshot? A volume snapshot is an area of space inside what s called shadow storage, which is itself a typically small area of space on the disk located in its System Volume Information folder. After a disk snapshot is created a change to any data block from that time forward cannot get written until a copy of that block s data before the change (as it was when the snapshot was created) gets written to the differencing area in shadow storage. In this way the data on the disk at the time the snapshot was created is preserved, block by block, in the shadow storage area. The snapshot data is then available either from the original disk, if the data blocks requested haven t changed, or from the differencing area if they have. The fundamentals of this are illustrated below:
A minute later one of the blocks gets written to, but not before the data as it was at 6PM gets preserved in the differencing area: As the actual disk changes the data as it was at 6PM gets written into shadow storage, preserving a record of the disk as it was in that moment: In the figure above a backup server requests data from the snapshot of blocks 7 and 58. Block 58 from 6PM is preserved in the snapshot, so it s copied directly from shadow storage. Block 7 is unchanged since 6PM, so it is copied via the VSS driver VOLSNAP. SYS, which operates much like a filter driver underneath the NTFS. SYS file system driver. By working in the IRP stack (the part of kernel memory that manages disk I/O) underneath the file system it can read blocks of data without NTFS objecting that a file is in use. VOLSNAP. SYS is also responsible for ensuring blocks are copied over to shadow storage if a write is requested to them, hence the name Copy On Write. Here is more about VOLSNAP. SYS from Tim McMichael: Now that we ve got the basics of a COW snapshot down let s look at how it works with Exchange, along with some other major concepts:
Everything You Need to Know About Destiny 2 IGN
So we know that any disk that stores Exchange data gets a snapshot created of it by VSS. How exactly, though, does a backup application find out which disks those are? Oftentimes an administrator selects databases for backup without specifying anything about what disks their data files are stored in. So something is required to provide the information about where the data files are, and therefore what disks VSS needs to create snapshots of. This information also tells a backup application, also known as a VSS requestor, what specific data files should be copied out of the snapshots for preservation on backup media, as we don t want to copy out anything from the disk we don't need. The mechanism at work here is the Microsoft Exchange VSS Writer. Like any application s VSS writer (there are many, just run VSSADMIN LIST WRITERS to see them) its first job is to tell the backup application about the data needed for backup, especially the EDB file, logs, and checkpoint file for each database requested. The information about these specific Exchange data files is known as writer metadata. In the figure above we see the initial steps of an Exchange backup. The Exchange Writer tells the backup server (the requestor) that there is a database located in a folder on volume E:, and that transaction logs for that database are in a folder on D. Based on that information the backup application will request snapshots of the D: and E: volumes when the job progresses.
Here's more information on how an application's VSS writer interacts with VSS with regards to freeze, thaws, and the time needed to get a snapshot completed: The last major responsibility of the Exchange Writer is to tell the Information Store Service (MS Exchange Replication Service in the case of a passive copy backup) that the backup was completed and, if applicable, carry out post-backup tasks like log truncation, marking the database as no longer with a backup in progress, etc. In the part two and part three of this series we ll look at a play-by-play breakdown of how the elements described above all come together in an Exchange backup, the application log events that get generated, and compare the process for a mounted database to that for a passive database copy. Thanks go out for the collaboration on the content in these posts to Michael Blanton, Tim McMichael, Randy Monteleone, Dave Vespa, and Tom Kern. Thanks for making things clear. I really like the snapshot explanation. //When databases are thawed write I/O held in RAM is allowed to go to disk again. // whether we need to worry about RAM requirements fro MB server for this? The time it takes VSS to create a snapshot for a single volume is typically short enough that available memory is in no way challenged to handle the very brief uptick in usage. Hence, the Exchange Writer forces the Information Store Service, or the MS Exchange Replication Service, from writing what’s in RAM to the frozen database files I think the word forces was meant to be interpreted as prevents in the above line. Am I correct? Thanks for explaining in detail. Request you to also add some troubleshooting steps, I have see lot of time Exchange writer stops responding and backup fails, so current solution is to reboot the server, if you have more details on that please provide.
Otherwise the concepts are the same. An updated troubleshooting guide is still far off, so in the meantime you can try posting the errors you re seeing and circumstances of the issue in the forum: Nice blog indeed. But what if the databas was member of three copy DAG, and after the snapshot is taken, the db get mounted on another server and set of disks? ! Will the vSS writter allocate snapshot area for all disks for all database copies allocated in the three servers? I m not sure I understand the first question entirely, though. To answer the second, no, a VSS snapshot of a database on one server results in a snapshot in shadow storage only for that server. To approach the first, if a database whose disk(s) has a snapshot available gets mounted on a different server it wouldn t necessarily affect the integrity of the backup solution. It really depends on the circumstances, though, can you elaborate on the question? Good Article which has provide more stuff on exchange. . Waiting for next one.