SharePoint Backups – On-Premise

Blog written by:
Chris Ang
SharePoint Architect
CCNA, MCPD, MCTS, A+

Intro

SharePoint being deemed as one of the most imperative collaboration tools used across organizations and commercial hubs of all sizes, it should be set up with scalability and high availability in mind. All-inclusive data consistency and continuous availability are two of the major concerns of hosting data on a SharePoint server.

To help prevent data loss due to human error or unavoidable conditions, it is of extreme importance to set up a plan to periodically backup data. While there are quite a few backup and recovery options available, one needs to select the right method, as required, as per the size of the database, type of backup, backup time and maintenance procedures.

Due to SharePoint’s architecture and design, it is quite a challenging job for backing up and restoring the SharePoint content.

These are the different possible ways available for performing backup in SharePoint

Backups using Versioning and Recycle Bin Settings

Pros:

  • Easy configuration using UI
  • Can keep a back up of sites and lists if they are deleted
  • Can keep a back up version of web pages, items and documents if they need to be restored due to incorrect change, overwrite, deletion
  • Simple way for a Site Owner to restore files for their users. Therefore lowers burden and time required by SharePoint administrator for some tasks
  • Does not require secondary media to store the content, however this also is the same reason it may be of risk in case of disaster where the whole site collection is lost for example
  • Simple way to review and restore different historical versions of a page, file or item from UI

Cons:

  • May require PowerShell or another tool to ensure the versioning settings are correct on all lists
  • Recycle bin only can back up sites, lists and items. It cannot backup or restore anything else such as a web application, entire site collection, service applications, SharePoint root files
  • Sites and Lists cannot be restored unless they are deleted
  • Does not protect against disaster, where the entire farm, site collection or web application is lost
Backups using Central Administration

Pros:

  • This is a UI option present in Central Administration
  • Supports full and differential backups
  • Supports compression
  • Supports multiple threads to improve performance and time to complete jobs
  • Provides on-screen logs and live status of backups and restores in Central Admin
  • Granular backup and restore, although it does not provide item level restores, it allows you to easily choose from check boxes, target backup & restore components (such as an entire site, web application, service application, etc..)
  • Supports Full Fidelity backups – includes permissions, workflows state, etc…

Cons:

  • No scheduling in the UI
  • Does not backup windows system files
  • Prone to failure of timer jobs
  • Prone to processing conflicts if users are on the system
  • This is not an ideal approach for site collection more than 100 GB in size, and may fail for content databases larger than 200GB
  • Time to backup often can exceed the outage time/window/SLA allowed for a business for large sites (size of content database, number of sites & lists)
  • Does not support restoring to a different SharePoint version
Backup using PowerShell

Pros:

  • Flexibility is provided by PowerShell in obtaining full or differential backups
  • Windows task scheduler assists in scheduling the scripts
  • Supports full, incremental and differential backups
  • Supports backup of content databases and service applications such as search
  • Considered more trustworthy than Central Admin backup, as the UI can hang or if Central Administration site is down
  • Granular backup and restore, although it does not provide item level restores, it allows you to backup & restore components (such as an entire site, list, web application, service application, etc..)
  • Supports Full Fidelity backups – includes permissions, workflows state, etc… (NOTE: some commands such as Export-SPWeb does not support full fidelity)

Cons:

  • Limitations like inadequacy of backup of configuration and IIS settings
  • PowerShell need proper set up permissions locally by administrators to execute the commands
  • This is not an ideal approach for site collection more than 15 GB in size.
  • While performing site collection back-up, the entire site collection should be in read only mode for the duration of backup, any modification made to the site collection during the backup process would corrupt the entire backup files
  • You cannot use a backup made from one version to restore to another version
  • Most of the commands do not support restoring to a different SharePoint version
SQL Server Backup

Pros:

  • Reduced knowledge required as most admins are familiar with SQL Server
  • Supports full and differential backups
  • It would be a good option for site collection size in between (15-100) GB
  • This is the fastest backup and restores process in comparison to SharePoint backups using Central Admin UI or PowerShell
  • Supports Remote Blob storage (SP2013 and higher)
  • Supports Full Fidelity backups when restoring an entire Site Collection content database to the same source location
  • Can support Point-In-Time recovery if content database setting is set to Full, this however will increase database log sizes
  • Supports detach attaching of content databases to provide a faster recovery time

Cons

  • Does not backup entire farm, Windows System, IIS settings and search crawl indexes. SQL Server backup is deficit in backup of farm, IIS settings and search crawl indexes
  • Only supports the Database backups
  • This is not supported for site collections over 100 GB in size and content databases over 200 GB in size
  • Restore is typically a longer process than using Central Admin or PowerShell
  • Cannot perform a granular restore, such as when you need to restore an individual site, list or item, it will require restoring the content database to another web application on a different farm (as the duplicate site GUID may cause issues), and then extracting the required artifact for restore. This may also introduce challenges with moving content and permissions across to target restore location(s)
VM Snapshots

Notes:

  • This is often an Administrators first option as its ease of use and often a VM tool is already in-place
  • VM Backups are NOT recommended with SharePoint, see Cons below

Cons:

  • SharePoint Timer services will often fail and will not be reliable
  • Introduces many risks, such as possible duplicate names on the network due to changes, AD membership failure, unexpected notifications to end users from the new, non-production system, etc
  • Service account passwords may have issues if you use the VM backup method
  • Even if your timing of VM backups are perfect, this is an all or nothing approach, if the backups fail to restore, you are out of luck

SharePoint ‘Components’ that can fail or need to be recovered

(* are the ones I think are more common)

  1. *Individual SharePoint Files, Web Pages and Documents (Item Level)
    • Use Versioning, Recycle Bin, Offline Sync/such as OneDrive + Windows File System Backups (will not restore permissions but metadata will be intact, stored with MS Office files only), and/or Site Collection Backups
  2. *Entire SharePoint Lists and Libraries
    • Use SharePoint Central Admin or PowerShell Site Collection Backups
  3. *SharePoint Site Collections and Sites/Subsites
    • Use SharePoint Central Admin or PowerShell Site Collection Backups
  4. *SharePoint Customizations, such as Branding, WSPs and Code base
    • Use SharePoint Central Admin or PowerShell + File System Backup
  5. *SharePoint Branding WSPs or manual editing of SharePoint CSS/JavaScript
    • Use SharePoint Central Admin or PowerShell + File System Backup of WSPs
  6. *Files located in the SharePoint Root
    • Use SharePoint Central Admin or PowerShell + File System Backup of WSPs
  7. Entire SharePoint Farm
    • Use SharePoint Central Admin or PowerShell + File System Backup
  8. SharePoint Configuration Database
    • Use SharePoint Central Admin or PowerShell
  9. Entire SharePoint Web Application and IIS Web Sites
    • Use SharePoint Central Admin or PowerShell + File System Backup
  10. SharePoint Service Applications, such as Search or User Profile Service
    • Use SharePoint Central Admin or PowerShell
  11. Service Accounts in Windows lost or corrupted
    • Not sure about this one but should not happen unless someone deletes one of the service accounts 🙁
  12. SQL Server Database(s)
    • Sql Server Backups
  13. SQL Server Service(s), program files and configuration
    • Sql Server Backups
  14. IIS Configuration data
    • File System Backup
  15. Web/App/DB Servers – Windows file system or OS
    • File System Backup

SharePoint components for backup and recovery

This table shows components of a SharePoint environment, and the tools that can be used to back up and recover each component

Component SharePoint
(Central Admin
or PowerShell)
SQL Server File system backup
Farm Yes
Service applications Yes
Web application Yes
Content databases Yes Yes
Site collection Yes Yes
Site Yes Yes
Document library or list Yes Yes – but requires 2 step process
List item or document Yes – but requires 2 step process Yes – but requires 2 step process
Content stored in remote BLOB stores

 

Yes Yes
Customizations deployed as solution packages Yes Yes
Changes to Web.config made by using Central Administration or an API Yes Yes
SharePoint configuration settings Yes Yes
Customizations not deployed as solution packages Yes
Changes to Web.config not made by using Central Administration or an API Yes
IIS configurations not set through SharePoint 2013 Yes
SQL Server Reporting Services databases Yes

SharePoint is a great option that has totally revolutionized the content management arena. However, the complexity of SharePoint and its many moving parts have proven challenging even for the most technical engineers.It is needless to say that with the introduction and growth of the SharePoint, many enterprises have an increased need and set of requirements for flexibility of data backup and the recovery process, and to find that at a reasonable cost.

References

https://technet.microsoft.com/en-us/library/gg266384.aspx
https://technet.microsoft.com/en-us/library/ff806332.aspx
http://technet.microsoft.com/en-us/library/cc262787(v=office.14).aspx
https://technet.microsoft.com/en-us/library/cc262787(v=office.14).aspx
https://blogs.msdn.microsoft.com/mossbiz/2013/01/14/sharepoint-vs-snapshots/

Do you use SharePoint? Try our toolkit
Download SharePoint Essentials Toolkit Now
Download the SharePoint Essentials Toolkit
Chris Ang

Chris Ang

Solution Architect at Cognillo (formerly QiPoint)
Chris Ang (New York, NY USA) is a SharePoint Architect with 20 years experience in programming and network infrastructure.

Currently working at Cognillo (https://www.cognillo.com), he has helped architect and develop SharePoint Enterprise products for customers such as the U.S. Navy, U.S. Army, U.N. Security Council of Netherlands, Australian Government, U.S. Dept of Treasury, U.S. Dept of Justice, Canadian Dept of Defense, Scotiabank, JPMorgan CHASE Bank, Intel, Ford Motors, Microsoft, NASA, DARPA, SNC Lavalin, Penguin Books, and more.

He is a proud father of 2, and when he has any spare time, he loves to paint portraits of his kids.
Chris Ang

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.