HPE Storage Tech Insiders
Showing results for 
Search instead for 
Did you mean: 

Nimble OS Part 11: Exchange Snapshot Log Truncation / Verification


This post wraps up our 11-part series on Nimble OS 2.1 with a look at some great new features for Microsoft Exchange Server.

A bit of background first on deploying Microsoft Exchange on Nimble Storage. Nimble is able to store 10-15X more mailboxes per disk than legacy SAN vendors due to our unique CASL architecture. In the past Nimble has provided two Exchange Solution Review Program (ESRP) submissions for Exchange 2010. This is a standard Microsoft benchmark using Jetstress that most storage vendors publish results for. The Nimble results can be found here:

20,000 mailboxes on a CS240G: http://bit.ly/1rHv2Nr

40,000 mailboxes on a CS460G-X2: http://bit.ly/1fiBZsk

Well with the advent of Nimble OS 2.1 and the CS700 platform we’ve submitted a new ESRP but this time for Exchange 2013:

100K mailboxes on a CS700: http://bit.ly/TFfw4V (this one has additional flash and one expansion shelf)

Remember these are 3U arrays with proven uptime of over 99.999% that draw 450-560W of power. Our always on in-line compression greatly reduces the capacity required for Exchange without compromising on performance (approximately 1.6X reduction as measured across our customer base). Due to the capacity density and performance profile of Nimble arrays the cost per mailbox is industry leading.

Additionally, built in to the Nimble arrays is best of breed data protection with hardware snapshots that enable our customers to store literally hundreds of recovery points (up to a 1,000 for any volume) whilst only consuming a fraction of capacity. Recovery from our hardware snapshots only takes seconds to complete. Zero Copy Clones allows our customers to clone and mount a snapshot backup for single item search and/or recovery, for testing purposes, and best of all our clones don’t consume any additional space or require a software license!

The snapshot backups are fully integrated with the Microsoft Volume Shadow Copy Service (VSS) on the host via the lightweight Nimble Windows Toolkit which contains a VSS requestor and hardware provider which works in conjunction with the Exchange VSS writer to ensure all snapshots are application consistent. This enables full snapshot backups to be taken of Exchange data in milliseconds without impact to the application.

Consider a DAG architecture for Exchange 2010 or 2013. A DAG (or Database Availability Group) is simply a Windows Server Failover Cluster that manages multiple copies of a database running on different hosts. The concept is one of the databases will be active and the others replica’s which can be activated in the event that the normally active one fails for any reason (network failure, card failure, database issue and so on). The diagram below illustrates a typical DAG configuration where two copies are available in the production site and another is available in the DR site. Data changes are replicated by Exchange by transferring log files between hosts and database copies.


With Nimble you can configure full snapshot backups to occur not only on the active database copy, but also on the replica database copies. The schedule and retention on each database copy can be different but you must ensure that only one copy of a database is being backed up at a time so therefore stagger you snapshots so that the active and replica backups don’t overlap.

You can only restore the active database copy in Exchange, however if you need to restore a replica copy from a snapshot backup it is possible using the method below:

  1. Remove replica database copy from the DAG
  2. Add the database replica back in but with seeding postponed
  3. Restore the volumes back to the last snapshot
  4. Resume seeding on the replica

This process effectively performs an incremental reseed of the replica copy i.e. only the differences between the active copy (up to date) and the point in time to which the replica was restored to (time of snapshot in step 3) are replicated.

This snapshot integration has been available in previous Nimble OS versions, but with the release of 2.1 some new functionality is available for Exchange 2010/13; the ability to truncate Exchange transaction logs without requiring a database verification. Previous Nimble OS versions always required database verification to perform log truncation and this added a heavy sequential (256KB) read operation through the database. This is fine if you’re not 24/7 but if you are or have other critical tasks to run each evening this new functionality removes the unnecessary IO load.

To leverage this functionality you must be in a supported configuration as outlined by Microsoft; “For databases in a DAG that has two or more healthy copies, the database consistency checking step can even be skipped”


So how do you leverage this new backup capability where database verification isn’t needed? Here’s the steps:

1. Upgrade your arrays to Nimble OS 2.1 (non-disruptive).

2. Upgrade the version of the Nimble Windows Toolkit (NWT) on the Exchange hosts to 2.1.

This will require a host reboot (as a newer Nimble DSM gets installed) so plan this during a maintenance window or fail over your active database copies to another DAG member server

Note: You should upgrade in this order (Nimble OS then NWT) because NWT1.x/2.0 works with Nimble OS 2.1 and scheduled VSS snapshots will continue to work as expected until the toolkit is upgraded. In place upgrade from NWT2.0 to NWT2.1 is possible, however if you are running NWT1.x you need to uninstall before installing NWT2.1.

3. Edit you volume collections for Exchange and change the “Application” to “MS Exchange Server 2010 or later w/ DAG”. Note you only need to do this on the volume collections you normal verify Exchange on.


4. Then click on the Schedules tab and you’ll see a new option under the “Verify backups” area to “Skip consistency check for database files”


Note that if you hover over the “not recommend” link next to this it highlights the following:


So you must have two or more copies of each database in the DAG to leverage this.

Note: We don’t explicitly check that two or more database copies are available, that’s the responsibility of the admin.

Now when we perform the backup (with verify) we only verify the logs (as per Microsoft’s requirement). No database file (EDB) verification is undertaken and that means much quicker backups and more IO available for other tasks.

And that’s it you’re done. Simple.

I hope you found this blog useful, if you have comments or questions please post below.

You can find the entire Nimble OS 2.1 blog series here: https://connect.nimblestorage.com/docs/DOC-1391

About the Author



We are currently using 2.0.x.x and are leveraging daily snapshot verification on our CS260 (1Gb model, no 10Gb yet)
We have a 2013 DAG with database volumes with 4 DB's on them and is roughly 3TB.  Currently it takes in the ballpark of 20hrs to do the verification.

What would you think a good ballpark estimate would be leveraging the skipping of the consistency check on our 1Gb array?
I know I'm asking for an answer that has some outside influence too, but % wise what would the best guess be?


Hi Julez,

3TB in 20 hours is running at about 45MB/s. With this new option we won't run the eseutil process against the database, but we do still checksum the logs (as per Microsoft's requirement - see link in blog above). As we don't run that process I would expect your back ups to reduce significantly as majority of the 20 hours is the eseutil process. As you say its hard to put a figure on it but given the reduction in work required for a full backup I would "guess" the backup time would reduce to less than an hour assuming this is sufficient for the log checksum process.

Please post the results if you implement!




We were able to do our upgrade yesterday evening.

We definitely cut time off the snap and verifications, and I've only done a single manual snapshot with the verification.
I checked my event log to see when the ESE actually did the log truncation which was around 6AM this morning, and we started at about 10PM yesterday evening.  So we went from about a full day down to 8 hrs.  And that's with our array rebuilding drives for the parity change in

It looks like it still took about 8 hrs even after this had been implemented.
Like I said significant reduction, however, definitely not sub 1hr.

We'll give it a couple days to see what it settles down to.


Hi Julez

The db verification should have been the bulk of the 20 hours previously, so after the change to "skip db verification" I'm surprised the duration is still 8 hours. Can you parse the event logs to check when the snapshot occurred, log checksum completed, exchange truncation timing. How many logs did you have to verify in the 24 hour period between backups?



I've done some monitoring.  Let me preface this with we have been doing some massive imports from an old archive into the new Exchange In-Place Archive.  Some of these imports were causing the logs for the archive databases to grow into the 200gig range.

Ultimately this is why the initial backups were taking in the end over 24hrs to process.  When we migrated to we were still having these level of imports.  Which is why I believe the 24hr process was only dropped to 8hrs.  Remember this is over a 1gig connection.

Last night we did not have any imports and the logs of the archive database were minimal.  We saw less than 30min to complete the backup.

Keep up the good work guys!


Great news Julez! Thanks for posting the update.


Jan 30-31, 2018
Expert Days - 2018
Visit this forum and get the schedules for online HPE Expert Days where you can talk to HPE product experts, R&D and support team members and get answ...
Read more
See posts for dates
HPE Webinars - 2018
Find out about this year's live broadcasts and on-demand webinars.
Read more
View all