Why backup Skype for Business (and my MSIgnite session)
I'm back from a very exciting week in Chicago. Not only was this a huge and great conference, but it was an excellent opportunity to meet fellow Skype for Business (SfB) users, techies and providers of the ecosystem around the product. As well as a chance to talk firsthand to some of the many minds the current release (Which, in case you missed it, was released to MSDN on the Friday before the conference).
For Ignite, I had rewritten the previous Teched and Norwegian Lyncday session to have more relevant information, and to include more restore examples than the two previous talks. The feedback from my session was great, and I was given three challenges I want to share with you. One which I will save for a later presentation (on conference information), one I will write a separate post on (how to restore a computer, part of a pool, based upon a snapshot), and a third I want to answer right away in this blog post.
One of the attendees told me the rest of his team didn't see the need for a real backup. They trusted snapshots and database backups to be good enough. He asked me if I could help to point out why specific configuration backup was necessary. And that is what I shall try to do here, and share with all of you.
The good thing about snapshots:
First of all, snapshots of a computer is a perfect way to restore certain servers quickly. Examples of servers which could and should be backed up and restored using snapshots are: OWAS servers, edge servers, standalone mediation servers or other static servers. Just remember to invoke replication and run bootstrapper to have the local configuration updated from the CMS.
The not so good things about snapshots:
When it comes to the SfB configuration or user information, one should think about this as dynamic data. And restoring a snapshot of a server which could believe it is the master of it's information (and old data) into a running cluster, could potentially cause more issues than the one the restore was supposed to fix. I can admit a solid backup of the database sounds like a good idea, but when things go wrong, how do you know you target the right information upon restore?
Let me give an example: There has been done several changes to a deployment one night, and "something" isn't working as expected. How do you want to troubleshoot and/or restore this. With only snapshots and database backups in hand, you need to restore the entire CMS database to fix the issue at hand and possibly overwrite or rewrite something that is working, and shouldn't be over written. But with a scripted configuration backup, this can be more granulated.
I tried to show this in my session at Ignite where I compared a backup configuration with a running configuration, and quite easily identified the issue. Instead of restoring the entire system, we could correct a simple error.
In addition, there are certain things not covered by a snapshot or database backup. Things like the topology information, analog phones, common area devices are all stored in a cross-mix of SfB and Active directory. These can only be grabbed with scripted configuration dumps.
Two other components I would like to highlight here are the persistent chat and route group services. These are roles not covered solely by a database backup nor by a CMS backup. The only way to possibly restore these services correctly, are through the export and import commands I talk about in my session.
The bottom line is: There are certain things a snapshot and database backup can cover. But it is in no way as flexible or versatile as one should want when restoring elements of the configuration is called for.
I hope I have been able to shed some light on why it is important to have a solid backup of not only the databases and server snapshots (because they are an important part of the backup and restore scheme), but also a backup of different aspects of the configuration.
Here is the recording, and the slide deck from my session: