Backing up enterprise applications: Transaction consistency is key

Hi this is Elias Khnaser, and I'd like to welcome you to this Veeam sponsored session around Backing up Enterprise Applications.

Before we go ahead and get started, I am going to give myself a shameless plug in the form of an introduction. I am the CTO for Artemis Technology, a purpose build virtualization and cloud computing systems integrator. For Artemis, I set the technical direction for the company, and I also advise customers and clients around server, desktop, and application virtualization in addition to cloud computing strategies and the automation of highly virtualized data centers.

I frequently blog for InformationWeek Forbes and Virtualization Review, both the online and printed edition. So make sure you check me out. I am a recipient of the VMware vExpert award. I have a lot of publicationsm but in the last year I have published: the VMware vSphere 4 Exam Cram, the VMware vSphere 4 Training DVD, Citrix XenApp 6 training by TrainSignal and Citrix XenApp 4 and 5 by TrainSignal as well.

All right. So I have a packed agenda for you guys. We're going to get started by talking about what is Volume Shadow Copy Services? What is this thing that's called VSS? Then we are going to talk about why should I use VSS? We are going to move on to talk about the different components that make up VSS so that you can understand it from an architectural standpoint and know how these components talk to each other and tie into one another. Then we're going to take a look at how native operating systems do VSS, how a native Windows operating system that's installed on physical machines, by the way does that still exist physical machines? What is a physical machine? We're going to talk about how that happens, and then we're going to move on to talk about how VMware vSphere 4 takes advantage of VSS in order to do its own backups and how that's different from an agent assisted VSS backup, which is typically a third-party software that gets installed that allows or that initiates and controls the backup process. I'm going to go through the different steps and stages that are required to create the shadow copy, the volume shadow copy. Then we're going to wrap up with the most important thing of all, the whole idea the whole purpose of taking a backup is so that when you need it, you can restore it. So we are going to talk about the advantages of an agent assisted VSS aware restore.

So what is Volume Shadow Copy Services, otherwise known as VSS? I'm going to give you two definitions here. I'm going to give you the short and sweet, and then we're going to give you the more elaborate definition. VSS is a Windows framework for application backups. That's your first definition. Now for the second, VSS is a built in Windows service that facilitates and coordinates the creation of consistent copies of transaction based application data. I came up with this definition by the way and I'm very proud of it.

So what this means is that VSS allows transaction based applications, such as Exchange, SQL server, SharePoint, Active Directory, and Oracle, that have open files that have these files that are consistently written to, you're always writing, there's always IO traffic going to these files, it gives you a framework that allows the backing up of these applications in a safe way so that you don't produce any kind of corruption.

Now there are two ways, two methods by which you can create shadow copies. There's the clone. Clone is very easy, very simple. It's just a full clone, otherwise known as a split mirror. So what happens is when you initiate it, it takes a point in time copy, full copy, full clone of the existing state of that machine, whether it's a VM or a physical machine.

The second is copy-on-write. Copy-on-write is very similar to a snapshot, for those of you who are familiar with VMware and vSphere. It's very similar to a snapshot. It basically writes the changes to a difference file. So what it does is when you initiate a copy-on-write VSS, what happens is it's going to pretty much render the original file as a read only file, and then any changes you make after you've initiated that are written to a difference file.

Now the advantage of using the copy-on-write method is that you can take these volume shadow copies very quickly, because all you're doing is you're taking copies of the difference file. Now the disadvantage is that when you go to restore from a copy-on-write, you best make sure that the original copy, the original volume still exists because what it's going to do is it is going to backtrack. It's going to go backwards and reconstruct the original data in order to allow you to create a restore point.

So there are pros and cons to both, but primarily or essentially the copy-on-write is much, much faster than having to take a full clone of the VM or of the physical machine every time.

This brings us to why VSS? Before I answer that question, I want to talk a little about backup, about the concept of backup. Now as you know the reason we do backups is so that when we need to, we want to be able to restore. However, that's simplified. That's a very simplistic statement, because a lot of times we are just backing up and we don't understand the architecture of certain applications and how to backup certain applications. Every application likes to be backed up in a certain way, and every application likes to be restored in a certain way.

Backups are a lot more than just backing up Word files or Excel files or just static files. Whenever you get into the transactional type applications, like Exchange, SharePoint, Oracle, and Active Directory, you cannot treat these applications the same way you treat just regular file servers. It is for this reason that we are talking about VSS today. It is important for you to understand the architecture of what Windows offers in terms of how to backup certain applications so that when you go to restore them, you are not surprised that they are not restoring properly. Understanding VSS helps you choose and select the best backup software that you can.

Now most backup software will be able to backup and restore regular files. Not a big deal. A lot of backup software will also advertise the idea or the fact that they are VSS compatible and they'll backup your data as part of VSS. Right? They'll integrate with VSS. The question you should always be asking the vendors and whoever you are talking to in order to select the best software is, "Will your software or does your software support VSS restores," because applications again like to be restored in a certain fashion in a certain manner. Every application is different.

VSS creates that framework, creates these hooks into the actual application, backs them up in a certain way, the way they liked to be backed up, and then restores them according to a process, according to how they like to be restored in order to bring back the applications and the servers in a safe way and give you access to the data.

Now let's talk about why VSS. Well, so without VSS what you end up with is a, well, sort of a crash consistent backup. Now, what's a crash consistent backup? A crash consistent backup is the equivalent of rebooting the server or yanking the cable, the power cable out of a server. What happens is it's just going to take a copy or a backup of what it has now. It's going to cut out everything and take a copy and that's it. Exactly the equivalent of rebooting a server. It doesn't have any application awareness. So without VSS, there's no application awareness. It doesn’t understand that there are open files here, there's a transaction, there's IO going back and forth. You can't just stop it. You're going to create corruption. You're going to create a state where the application or the server itself isn't going to start. So without VSS there's no way for the backup software or the backup solution to understand the actual application itself. Now obviously, some applications, some servers, some backup software have agents for the different applications. What VSS has created is it has created that framework that allows you to hook into these applications via VSS.

Again, we take backups in order to restore, right? So certain applications, like Active Directory, when you go to restore them, there's a post restore process. There's a certain way with how you power back on Active Directory to main controller. There's a certain way with how you mount back those exchange database volumes when you are trying to restore. So again, any software that you choose from a backup perspective has to be able to execute on all these post process tasks that are required in order to power back on the application successfully. That's the importance, that's the value of the Volume Shadow Copy Services.

If you guys are anything like me, I always want to know how things work. What are the different components? How does this technology work? We're geeks, right? We're technologists. So the different VSS components are made up of obviously the Volume Shadow Copy Service. That is essential and is available with every Windows operating system starting with Windows 2003 and moving forward. That is the framework. That is what allows these backup softwares to plug in and use VSS.

Now requestors, that's another component of VSS, initiates shadow copy creation. It initiates it. Now, what would be a good example for requestors? Anyone? Come on. I'm going to get Veeam to give you guys a prize if you can guess requestors. So requestors are third-party software vendors, like Veeam, that plug into VSS and initiate the Shadow Copy Creation that initiates the backup job essentially.

Now another component is the writer or are the writers. Now, what are writers? Writers are what essentially prevent data inconsistency. The writer component prepares the application. It signals to the application that, "Hey Volume Shadow Copy wants to take a shadow copy of your existing data." So it prepares the application by ensuring that no writes occur on the volume while the shadow copy is being created. So what happens is it'll initiate a quiesce of the application's volume, for example. It forces the application to flush any existing data that's in its buffer or in its disk write in order to get a consistent copy of that application's data. The writer will also provide information about the application's name, the icons, the file locations included, etc., etc.

Providers. Now, providers are the actual sub-systems. They're the actual instrument that's going to go ahead and create the shadow copy. Now, there are three types of providers. So there's the system provider. That's what comes by default with every Windows operation system. Vendors can choose to use the system provider, or they can choose to write their own provider, their own software version of the provider that can execute in conjunction with VSS.

Now this leaves the two other options. The hardware providers, think of them as an interface between VSS and the different hardware components, the controllers, whatever the hardware components are that are going to initiate or they are actually going to perform the actual creation of the shadow copy. These are typically much faster. They are very hardware specific providers.

Now the software providers are your typical backup providers that are kind of hardware agnostic. They don't care about the disk. They don't take advantage or use any of the features of that particular disk. They are just pretty much software that again interfaces and initiates these commands and creates the shadow copy commands or the shadow copy process.

Source volume. The source volume is the volume that contains the actual data that you want to create a volume shadow copy of. So that's just the source volume. Then the storage volume is sort of like the volume that hosts the shadow copy. It's the volume that would host your differentials if you're doing the point in time copy-on-write, or this would be where the full clone would reside if you're doing the full clone VSS approach.

A picture says a thousand words, and if your mind is anything like mine, I like to visualize things. So let's take a look at these components in a graph here and see if we can make more sense of them. You'll notice that on the right we have the requestors, the requestor in this case. The requestor is your typical backup software. In this case, in this instance what we're taking a look at is a native operating system VSS backup, which means you have your operating system installed directly onto physical hardware and you're trying to backup, whether you're backing up SQL or Exchange or just an operating system, whatever it is you are trying to backup, but you're trying to hook directly into the operating system. In this case, the backup software becomes the requestor that is initiating the volume shadow. It's going to talk via the VSS obviously, Volume Shadow Copy Service.

It's going to interface with the writers. The writers are on the left side. The writers are what are going to provide hooks into the actual applications themselves. Writers are going to prepare that application to take a shadow copy. So it's going to quiesce it. It's going to force it to flush anything that's in memory that's in buffer so that we can get a consistent copy a consistent shadow copy.

Then you have your providers. Your providers can be the operating system. You have the default system provider that comes with the operating system. Third-party software vendors, like Veeam and others, can use that if they choose to do so, or they can write their own that can act as the provider. Again, here there are also hardware providers that do everything in hardware. So from a performance standpoint, the hardware providers will perform better. But the software providers will always have more features. They will always be hardware agnostic. So they don't care about the hardware that it's relying on or its features. It will talk to it regardless.

Now let's take a look at how this is different in a virtualization environment, specifically how this is different with VMware vSphere 4.X backups. With VMware vSphere 4, you will notice in our graph that we have changed the backup software at the requestor level to VMware Tools. VMware Tools is going to be the initiator for when you're using VMware for when you're using your native vSphere in this case.

So what happens when I say native vSphere is I'm talking about the VMware VCB, a consolidated backup which is no longer a supported product with 4.1 and up. I'm talking about VMware's data recovery appliance, which in essence replaces VCB.

So when the VMware data recovery appliance wants to initiate a backup, it is going to use VMware Tools as it's mechanism to initiate that backup. Now what is the problem? What are the limitations of VMware Tools? What are the pros and cons of VMware Tools? So VMware Tools is not application aware. So what VMware Tools will do is it's going to issue a file system level quiesce to VSS.

What a file system level quiesce will end up with is an image level backup of the actual VM that is crash consistent, which means it's going to not care about what's running on that VM in terms of applications. It doesn't understand what's running in terms of applications. So it's going to give you a quiesced machine but not a quiesced application. So in essence, VMware Tools creates a crash consistent image level backup of a virtual machine.

Now what happens with a crash consistent level backup, I don't want you to think that, "Oh this is a horrible thing." It's not a horrible thing. Some people are willing to live with it, are willing to accept a crash consistent image level backup. What happens with that is you have to just have a little more manual process, a little more hand-holding in terms of the backup process and in terms of the restore process.

Now what I mean by that is whenever you have an application that's trying to backup, that is doing it crash consistent, that it doesn't understand the application and in a lot of instances that particular backup application also doesn't know and doesn't understand whether or not the backup process was successful or not. So what happens if you are doing an image level for example crash consistent backup using VMware vSphere and their SQL server on there, the transaction logs become the problem. So because the application doesn't know that a backup process took place, it doesn't know whether or not to prune or flush its transaction logs after the backup process completes. If you don't interrupt, if you don't go in there and manually flush the transaction log, that transaction log can fill up and eventually lead to the crashing of that application.

Now if you're a savvy administrator that understands the limitations, there's no reason why you can't take a crash consistent image level backup with for example VMware Data Recovery, as long as you take care of the transaction logs afterwards and as long as you're aware that once the backup process is complete and you've flushed the transaction logs, whenever you go to restore that particular virtual machine, there are post-process post-restore tasks that you have to be aware of in order to implement manually in order to bring back that virtual machine in a functional and useable state, which means if you're doing crash consistent, you have to reapply the transaction logs after the restore takes place so that all the data that was in flight, that was in transit, that you didn't capture during the crash consistent or any data that might have been lost due to corruption or whatever the case might result in because of the crash consistent approach that you took, you have to restore and reconstruct that data from the transactions logs that you have properly flushed, backed up, and whatever you've done properly in order to accommodate that particular process.

So this is when you are looking at it from a VMware vSphere 4 backup perspective. VMware Tools as soon as they are installed and it's a mandatory install for any VM that's running on vSphere that it has the VMware Tools. VMware Tools has the drivers that are needed to initiate the quiesce of the file system – in this case it would be Windows – in order to take an image level backup of it.

It gets better. So with agent assisted VSS aware backups, what you are doing and if you will notice our graph, now we've added an extra function to the requestor. So now you have the on demand assistive agent that communicates with VMware Tools and then uses VMware Tools to go through the same process that we've been talking about.

Now what is that exactly, and what are the pros and cons? So when we were talking about how vSphere does its backup, it's doing it via VM Tools only, the problem is it was doing a quiesce of the file system and doing an image level backup, but it was not application aware. Now the agent assisted extends that a little bit. So instead of just doing a file system quiesce, it also understands the applications and it does an application quiesce as well, ending up with an image level backup of the VM that is file system quiesced and also application quiesced. You kind of get the best of both worlds.

Now some software vendors take it one step further, like Veeam for example, where it's almost agentless. Now it's not really agentless, because you still have to install that agent, but you're only installing that agent during the backup process, and it's removed after the backup process is complete.

Now the advantage to an on demand backup agent is that while it installs during the backup process, it's backed up with the backup job, right? So when you go to restore, that agent is automatically or auto-magically present during the restore process. So it helps you in the restore process because that agent is already there. Again, during the backup process, it'll install it on demand, run everything it needs to do from a backup perspective, and then when it's done, it will uninstall that backup agent. So it's kind of seamless to you. It doesn't leave behind software that we all hate because it clutters the operating system and the actual system itself. It removes it after it's done. It serves a purpose and then takes it off.

Now the advantage again of using an agent assisted VSS aware backup is when we were talking about crash consistent, one of the downsides, the downfalls of using crash consistent is there's a lot of manual process that you have to do in order to make sure that your restore process is successful. You have to take care of your logs. You have to make sure that certain applications come up in a certain way, etc., etc.

So for example, if you're taking the approach of Exchange, you want to make sure you un-mount the Exchange databases. There are two or three steps that you have to do with Exchange in order for the restore process to be successful. If you are restoring an active directory domain controller, you have to make sure that when you're powering it up, it comes up in a non-authoritative mode. Otherwise you're going to have a domain controller with Windows 2008, for example, that automatically gets isolated because when it comes up, its data is inconsistent with the other domain controllers. Therefore, the other domain controllers are going to automatically isolate that domain controller.

Again, with an agent assisted backup and restore process, it will handle that automatically for you. So again if you understand what the different applications require, what the different applications need in terms of backup and in terms of restore and you do crash consistent, more power to you. Go ahead and do it.

If you're like me and I can find and I want something to be a little more automated, I want that extra 30 minutes out of my day, and I don't want to have to worry about these post process or these pre processes that I have to take into account for the different applications, then I want to use that. So in my opinion, I would strongly recommend and suggest, and this is not to push Veeam or anything else, this is whatever you are going to choose, make sure that it gives you that flexibility so that you don't have to worry about, "Well, what am I doing about my transaction logs? Do I have to flush the transaction logs or not? Do I have to worry about them in the restore process? Are they going to be healthy when I'm trying to reconstruct my data?"

You're taking a big risk when you're doing it manually, because here's the trick with backups. Let's be honest. So backups are the type of operation where you don't really appreciate its value until something crashes. I've been to a lot of customers, to a lot of clients where, "Yep, we have backups." "Yep, we have backups." They've never tested these backups. They've never done restores, or if they've done restores, they've done them on files. Somebody lost a particular file here or a particular file there. They've never done them against databases.

In a lot of cases, in enterprises they'll rely on the SQL administrator to do his or her own backups. In smaller to medium sized organizations, it's usually the IT administrator that's backing up everything, and typically there isn't that dual protection sort of where the SQL administrator is doing his own backups and IT is doing their own backups of overall things. So what happens is when you go to restore and you don't have all the necessary components or you don't have the right software selected or chosen six months ago or ten months ago when you bought it or two years ago when you bought the software, when you go to restore it, at that point it's going to hit you and you're going to be like, "What is this?"

So backup software are tricky because when you buy them, you don't really appreciate or know if you've made the right decision or the wrong one until you go to restore. So that's why what I want to leave you with at the end of this session is to have enough knowledge to question the backup vendors or to at least do your homework around what type of application software you're buying that backs up the different components in your environment.

We all have these components. We all have some kind of a mail system. It could be Exchange, it could be Lotus Notes, it could be GroupWise, it could be a hundred different types of mail systems, right? We all have a directory of some sort. Obviously, most of us have Active Directory, SharePoint, Oracle etc. So sure, you can master all of these products from a post process and a pre process perspective and figure out what you're doing, or you can off-load that to the software and let the software worry about it.

Obviously, with an agent assisted VSS aware backup, also what you get is you get the ability for the application to be notified again of the results of that backup. The application has to know that a backup took place and whether or not it was successful or not. Again, if the backup process wasn't successful with an agent assisted VSS aware backup, it could reinitiate that backup. Whereas if you were doing it with a data recovery appliance, for example, and this is just an example to throw out there, it might not know that the backup process was successful or not. It's just doing a backup at that point. So there are pros and cons that you need to be aware of when you're making your choices.

Let's take a closer look. Let's dig deeper and see how volume shadow copies are created. What are the steps? What are the phases that it goes through in order to create the volume shadow copy and see if we can link that or connect that to what we have been talking about throughout this session.

So the first step is the requestor is going to ask VSS to enumerate the writers. What this is basically saying is that the requestor, the backup software or VMware Tools for this matter are going to initiate a request to VSS, "Hey I would like to take a shadow copy." What happens in this case is the writer component is going to create an XML description of the backup components that are needed to successfully run this backup. It's also going to define the restore method. So it's also going to tell you how to restore it. So that's all part of it. It's going to put all that into XML and send it back to VSS.

Now VSS notifies the application specific writers. So it's not enough to notify the writer. The writer is going to create the overall print, consider them the architect. Then VSS, once it receives this plan, it's going to notify the application specific writers. Those are the writers that are going to talk directly to SQL, talk directly to Exchange, and so on and so forth. Then these specific writers are going to prepare the particular application for shadow copy. What I mean by prepare is it's going to tell the application to complete any open transactions, any rolling transaction, any logs for example, flush any cache, commit everything to disk because we are about to take a copy of you, so we need to be able to take a copy with nothing sort of open. So please finalize everything that you are doing so that we can take a copy of you basically.

Once VSS is notified that, okay, the application was notified, VSS knows, it has the plan, it's notified the writers. The application is ready. It will initiate. It's going to give the go ahead, "Okay. I've revised. I've reviewed everything I have. I'm committing to this plan. Go ahead and execute." At that point, VSS is going to tell the writers to quiesce their data and temporarily freeze application access to the file system.

So what's going on here in essence is, in order for you to take a copy of the VM or of anything that's open, you are going to have to get to a point where you're freezing all write IOs, so nothing can be written anymore to it in order for you to make a good valid copy of this data.

So what happens in this case, applications will not stop writing. So the SQL database or the Exchange isn't going to stop writing. The user isn't going to be interrupted. However, all these transaction IOs that are happening when the VM, when the file system is frozen, they are getting queued up.

Now keep in mind this quiesce period shouldn't take more than a few seconds. If it takes more than 60 seconds, then everything is dropped and the job fails. If within these 60 seconds, it's successful, then what happens is all of the backlogs will then at a later stage be re-executed.

So once everything is frozen and you're able to take a good copy of the data, VSS will then tell the provider to go ahead and create the shadow copy. That is the final step. That is when, "Okay. Go ahead. Take it. Create it. I've done everything. You're ready for it." This shouldn't take more than 10 seconds. Again, that's a maximum that VSS sets on this

After this process, VSS is going to file the file system after the shadow copy is created. It's going to release the writers from their temporary inactive phase, and all queued writes are going to be executed. So anything that's in queue is going to be processed. All of the application transaction logs that SQL or Exchange were generating while the quiesce process was taking place, while the file system was frozen, all of that backlog is automatically going to start being processed and committed to the disk at that point.

VSS is now going query the writers and say, "Hey, can you confirm that this shadow copy IO held, that we have a successful shadow copy?" If the writers were not successful, if they say, "No, we weren't able to get a good copy and our data is potentially inconsistent," then the shadow copy is going to delete the files that it created, and it's going to notify the requestor that, "Hey, your job or your process failed."

Now, depending on the requestor, depending on the software basically that you're using to initiate all of this, the software might have intelligence built into it to automatically reinitiate that process without notifying you. So maybe the software will try three times, and if all three times fail, at that point they will notify the administrator that, "Look, I just can't do this. Something's wrong with the machine." Maybe the VSS service isn't working, maybe it's corrupted, for whatever reason. If the requestor has built in intelligence, it can automatically retry. Or if the requestor doesn't have any built in intelligence, it's automatically and instantly going to notify the administrator that, "Look, your job has failed. Try again later."

If the copy is successful, if the writer tells VSS that, "Yes we have a consistent copy," and at that point VSS is going to deliver or is going to return the location information for the particular shadow copy back to the requestor. That way you know where it stored it at. It's that easy.

Now the whole point of the exercise of running backups is that so when we restore the backups, we have a good restore. When we are restoring SQL and Exchange, we want to make sure the applications come up. When we are restoring a domain controller, we want to make sure that it doesn't get isolated.

So a lot of products will do agent assisted VSS aware backups, but they won't do agent assisted VSS aware restore. So let's take a look at this and let's think about this for a second. So if you can't do an agent assisted VSS aware restore, then doesn't that negate the idea or doesn't that render your VSS aware backup sort of useless? Well, it does. In that case, your VSS aware backup is just as good as your crash consistent backup. What's the difference in that case, right? So you have a VSS aware backup job, but you have no way of restoring it. So the way you are going to restore it is the same way a crash consistent backup would restore it anyway. So what's the benefit here? So it's very important when you're investigating your backup software that you ask these questions.

Now what are the advantages? What should a VSS aware restore do? It should properly initialize the VM on startup, which means things like domain controllers, they have to be put in non-authoritative mode on startup before you can initiate the restore process. In a crash consistent state, that wouldn't happen. It would just try to bring up the VM automatically. In the event of Exchange, it has to un-mount the exchange volumes that hold the mailboxes before it runs the backups and then re-mount them. So there's procedure that would have to happen before the VM is powered up. So you would have to bring up the virtual machine or the physical machine in this case in the proper steps and in the correct manner in order for you to take advantage of your backup jobs and restore them properly.

You have to be able to instruct the application to perform restore procedure from the shadow copy. So again, if you're taking a shadow copy, if you're doing it using a backup aware, a VSS backup aware software, but then when you go to restore it, you're not restoring it from a shadow copy, then it's sort of like, "What's the point, right?" So you have to choose an application that's restoring from the shadow copy as well.

So those are some of the key things to look out for when you're choosing your backup software to make sure that that backup software is not only VSS aware at the backup level, but it's also VSS aware at the restore level, which is going to make all the difference in the world.

All right folks, this brings us to the end of the session. So let's go ahead and quickly recap what we covered here. So we started out by talking about what is Volume Shadow Copy Services? What is VSS? We talked about how VSS is a framework for application backups, especially those application backups that are transactional, that always have open files, that always have this IO that is consistently being written to. We gave examples like SQL servers, Oracle servers, SharePoint, Exchange, and Active Directory in the form of domain controllers.

We then talked about why VSS. What is the advantage of using VSS? We talked about what would happen without VSS, and the idea that without VSS, you're backing up in a crash consistent state. When it comes to these particular applications, if you're not using any form of a third-party agent, if you're just taking everything out and you're trying to backup an open file, it's the same concept as rebooting the machine or yanking a power cable out of it. It's just going to backup whatever it could, and that results in data corruption, because when the server reboots after a crash, then it's going to take a look and say, "Okay. I have bits and pieces of this file but I can't literally open it." So that's what happens in a crash consistent state.

We also talked later on that a crash consistent state is not necessarily bad if you're willing to accept the consequences of it. If you've taken the necessary provisions, for example in a SQL server approach, if you have the transaction logs also backed up that you can use to reconstruct some of the data that was corrupted when you did the crash consistent backup, if you're willing to prune and flush the transaction logs after, if you're willing to do some of the manual work required, then the crash consistent backup might work. But keep in mind that there's a lot of manual process that goes into it that you probably want to off load and there are very application specific post and pre processes that need to take place for the application that you might not be an expert at. You might not know all of them, or you might not remember to do all of them. So an automated approach is always the safest approach for a VSS or for a backup process in general.

We talked about the different components that make up VSS. We talked about the requestors. We talked about the writers, the VSS service itself. We talked about the providers, and how they all tie in and what they do.

We talked about how VSS works in a native operating system backup approach and how the requestor is the backup software in terms of the requestor as a native system approach. We talked about how that is different in a VMware vSphere 4.X approach, and how the VMware Tools become the requestor and how VMware uses that when it's using VCB or when it's using the Data Recovery Appliance to initiate and run these backup jobs.

We also talked about the agent assisted VSS aware backups, especially in a virtualized environment, and how in a VM environment for example, the agent assisted is going to communicate with the VMware Tools and use that as a mechanism in order to communicate with VSS.

We talked about on demand agent installation so that you can install the agent when you're doing the backup and then uninstall it when you're done. It's literally sort of like an agentless approach in that matter. How when you go to restore that particular job, the agent is already installed because it was taken during the backup process, so it's already there. It's auto-magically there and facilitates the restore process.

We then talked about the 11 steps to volume shadow copies. What are the different steps and stages that VSS goes through before it creates the shadow copy and what happens if it's successful as opposed to when it's unsuccessful and has to either retry if there is intelligence built into it or notify the administrator to try again later.

Then we talked about the benefits of agent assisted VSS aware restore. So it's not enough to have awareness at the backup level. You need to have awareness at the restore level. Otherwise you won't know how to restore it in a consistent manner, and you end up with almost the same thing as a crash consistent state, because now you have a consistent backup that you can't consistently restore. So it's sort of like, "What's the point?"

So it was very important and I reiterate and stress here that it's very important when you're going through that selection process that you take all of the stuff that we covered here into consideration.

Finally, I hope you found all of this information very useful. I'd like to thank you for viewing.