Machine-level backup in SharePoint scenario

This topic has come out since I was responsible for providing backup and recovery solution for a medium SharePoint 2013 farm. The farm consists of 3 web front-end servers, 2 applications servers and a couple of database severs which are configured Failover Clustering.

Part of the backup process, many people would commonly perform a machine-level backup. This basically means everything including drives, file system, folder, system state or so on is backed up into a package. In their mind, if any of virtual machines goes down, they just simply need to restore a backup. In SharePoint scenario, this approach would be very risky even essentially things will be fully restored.

SharePoint stores its configuration in the hierarchical configuration store in the configuration database. This is synced to each machine in the farm by the configuration cache refresh timer job every 15 seconds. This process is to update file system cache, configuration cache or other things and let the configuration database know which servers belong to the farm. If you restore a machine with an out of sync cache you will have a potentially serious problem. The cache will update itself with a flush and repopulate but there will be a small time window of minutes where something could break. Another example of sync is crawling. Imagine you perform a backup in middle crawl, you will run the possibility of a search partition being out of sync when you restore a backup. Or even not during a crawl, you could just be making regular analytic processing updates and again restore one machine and index is out of sync.

There is no really an official documentation from Microsoft saying machine-level backup is supported in SharePoint scenario. In a single-server farm, machine-level backup may be well supported. For multi-server farm, this approach is supported for the farm in a fully stopped state. If you are to be required to back up your machine including operating system, the built-in Windows Server backup combining with some PowerShell scripts to create or join to a farm is a recommended best practice. I would like to thank Neil Hodgkinson, Wictor Wilen and other people for the valuable recommendations regarding my topic in MVP private forum.

Here are some helpful additional references:



  1. June 20, 2014 — 5:49 pm

    That’s really nice post.Because if there are lots of workflow running on, then all users may be affected or interrupted. So I just guess that we do the backup at the weekend, isn’t it? I would like to know in your case above, how long does the backup take?

    • June 21, 2014 — 4:02 pm

      Hi Duy,

      Thank you for your comment. SharePoint workflows can be backed up and are restorable, but there are considerations. For example, declarative workflow made by SharePoint Designer in SharePoint 2013 is stored in content database. However, custom declarative workflow relies on many components that are out of content database. There are the following locations you would be aware of:
      1. Assemblies for the Workflow Activities are stored in GAC.
      2. XML definition files (.ACTIONs files) are stored in 15 folder (TEMPLATE{LCID}Workflow

      These things basically need to be backed up. If you are using the new model of SharePoint 2013 workflow, read this post for more information about the workflow backup


Leave a Reply

© 2018 The Soldier of Fortune.