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 abo...
Updated Jul 01, 2019
Version 2.0
Blog Post
1 MIN READ
VSSTester script updated – troubleshoot Exchange 2013, 2010 and 2016 database backups
If you are taking database backup's you're doing it wrong. #ThePreferredArchitecture
Love your thinking. :)
- 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.
- 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.