It is indeed a known fact that data management continues to be one of the critical activities of a growing business. From organizing your company’s complete hierarchy of the users’ computers or getting to know the network adapter to which they are connected using the Active Directory services or utilizing the SQL server to retrieve a large number of records in a matter of seconds – MS applications no doubt hold their significance.
A crash-consistent backup will capture all of the data on the VMs at the same time. It takes a snapshot of all the files on the disk at the same time.
But, are crash- consistent backups just enough?
True. Crash consistent backups were sufficient when it came to legacy backups- for they took snapshots without the knowledge of those MS applications. Well, that’s not all. For example, let’s assume you are running a relational database like that of a SQL server. When a snapshot is taken for the file system/volume where the application data resides, the backups end up being inconsistent since the snapshots of crash consistent backups aren’t interfaced with the SQL server.
When a snapshot is triggered for this SQL server, it undergoes what is called a two-phase commit. First, the changes are updated in the transaction logs and later written to the database files. And only if the data is written on both these places(the logs and the DB), will the process hit the commit phase. But you face the real problem when a disaster strikes the SQL server and data still persists in memory or pending I/O operations and are not updated to the database. Now, the transaction log, in this case, will attempt to either rollback or rollforward. Sometimes it does pass successfully and there are high chances where it could fail too. Thus while ensuring a backup policy for VMs, it is very important that an additional application consistent backups are enabled for them.
So, what’s with the application-aware backups that make it competent enough than the legacy crash-consistent ones?
What are Application-aware backups?
The “point-in-time” snapshot backups like the application-aware backups, do work with the Microsoft Volume Shadow Copy on a block level basis. But the most critical utility that assures consistent backups that’s worth an efficient recovery is the VSS Writers. With crash-consistent backups, get to perform the crash recovery process for every successful backup that’s is not reliable at all! This is not the case how the application-aware backups work. They have an eye on data that would reside both on the memory as well the pending I/O operations (if any) with the help of the Volume Shadow Copy Service writers. Availing application-aware processing for Microsoft applications not only become important criteria for reliable backups but for successful restores too.
The Volume Shadow Copy Service Writers are a significant component of the Microsoft’s Volume Shadow Copy Service that will make sure the following actions are executed. It is to be noted that the three main steps in this process will only take a few seconds.
Let’s consider the working of application-aware processing for a Microsoft Exchange Server. First, the Exchange Server application data is flushed from the memory then the application is frozen to initiate the VSS snapshot and finally when the snapshot is taken, the freeze is released. This operation that assures application consistency also makes sure that the MS applications like Exchange, SQL, Active Directory or SharePoint remain transactionally consistent as well.
The problem that the traditional crash consistent backups pose is the time that it takes for bringing up the application to a consistent state at the event of a disaster. The time that this application will take will heavily impact the RTO of the configured backup job. Not only does this crash consistent recovery takes time in restoring the RAW images but also while replaying the transaction logs and the time that it takes to bring back the application to a consistent and reliable state.
Before we begin exploring how Vembu tackles application-aware processing for MS applications that reside on VMware/Hyper-V/ Physical Windows servers- it’s very important to gain some insight on the ground knowledge of troubleshooting these VSS Writers.
Understanding Microsoft VSS Writers:
Usually, the VSS writers are installed along with MS-applications like Exchange, SQL etc. The VSS writers can also be installed on the application using other tools as well. Among other tools and utilities, one of the simplest yet effective commands is the vssadmin command.
For instance, if you would like to perform specific actions with the Volume Shadow Copy Service you can utilize the above command.
The above list of commands will be of great use when you are troubleshooting the VSS service for that MS application when things go wrong. If you are backing up a Physical server that is running Microsoft Exchange 2016 and if you would want to check the VSS writer status- you should have to run the vssadmin list writers command.
The below screenshots will give an insight into the recent status of all the VSS writers. They are:
- The name of VSS writer
- The writer ID
- Writer Instance ID
- State- that tells if that specific writer is stable or not
- Last Error- checks if there’s any recently detected error by the VSS Writer
If you happen to notice, the “Microsoft Exchange Writer” is listed in the above screenshot since we ran the vssadmin list writer command on an Exchange server.
One of the most important prerequisite to ensure successful application-aware backups for an MS-application that’s running on VMware server is to make sure VMware tools is installed on that virtual machine. Similarly, if its a Hyper-V server, the Hyper-V Integration Services should remain updated as and when the application-aware processing is initiated corresponding to the backup schedule.
If at all there seems to an issue with the VSS, you would have to enable logging for the VMware tools running on the guest machine while troubleshooting since it is turned off by default. You should either create and edit the tools.conf file on that guest VM that runs the MS application and then restart the VMware tools service.
Alternatively, you can also avail the flexibility to troubleshoot the VSS via Windows Event Viewer as well.
Application-aware processing with Vembu
Vembu supports application-aware processing for MS applications like Exchange server, Active Directory, SharePoint and SQL that should run on any VMware/Hyper-V or a Physical Windows server.
Few inbuilt features that definitely are a not-to-miss-functionalities:
- Log truncation for SQL and Exchange logs to free up storage space
- Check for the stability of the VSS writers and then proceed for further to create application consistent snapshots
Curious about how it works? Watch this video now! Application-Aware Processing – Vembu
Concluding Thoughts
This functionality is definitely a big plus to all those IT admins who are running MS applications and would want to manage transactionally consistent backups for them. That’s not all. It does come handy while performing granular-level recovery using the Vembu Universal Explorer too. Any user can export data from Active Directory using .DIT format, .EDB & .PST formats for Exchange server and .MDF for SQL and SharePoint. Reduce RTOs and protect business-critical applications with the Vembu BDR Suite v4.0.
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
