VSSTester script updated – troubleshoot Exchange 2013, 2010 and 2016 database backups

[The_Exchange_Team]

Just wanted to let you know that the VSSTester script has now been updated to version 1.2. The main feature in this version is that the script now supports Exchange 2016 servers.

To read more about previous update see this, or for much more comprehensive information about the script, see the original blog post here.

Matthew Huynh

[#2]

If you are taking database backup's you're doing it wrong. #ThePreferredArchitecture

[#3]

Love your thinking. :)

[#4]

Lagged database copies are all very well, if you have SLAs that specify that data deleted more than a few weeks ago will not be recoverable and you don't have legal reasons to need to be able to restore a given mailbox to a particular point in time. Every time we've been asked to restore a mailbox it's been from months ago, maybe because a user left under a cloud and an investigation is taking place; maybe they left and came back again. Touch wood, we haven't needed to restore because of system failure but we HAVE needed to restore for various "layer 8" reasons.

One size does NOT fit all and saying backup is wrong is way too simplistic.

[#5]

Thank you for the script, it is helpful to those that require Software based VSS backups and are having issues that are not obvious to solve.

Like MG stated, there is no one-size fits all solution with Exchange.

While lagged copies can protect from short term issues and in-place hold can retain data for a specified period. The issues are then with storage capacity for Exchange and whether the organizational compliance requirements allow for that to replace backups.

For organizations without Exchange storage concerns or compliance restrictions, such as requirements to store data off-site, offline or in a WORM format the in-place hold or lagged copies can work well. Organizations with those restrictions unfortunately have little recourse than using a backup solution.

[#6]

Thanks