Ignite 2015:
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.
The question:
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:
Powerpoint Slides