Simply put, backing up your SharePoint 2013 environment is not a second-tier consideration. If you’re taking your implementation seriously, then you’ve got to plan your backup and recovery options.
This article shows you the basics about backing up SharePoint 2013. I’m going to demonstrate the different ways that you can backup your SharePoint 2013 data, as well as show you some of the PowerShell commands that you can use to backup your sites and farm configuration.
It’s going to happen. You’re going to need to perform a restore from backup. Even if a user never accidentally deletes a site or regrets his or her decision to delete a certain list, you should still perform restores as part of verifying the ability to restore from your backups. Because if your backup and restore procedures don’t work as well as you expected, there is most definitely a bad time to come to that realization.
My point is: Backup your data, and practice your restore procedures even before you need to.
You can use different techniques for backing up SharePoint 2013 to backup just the right amount of data. Sometimes, you’ll only need to backup a just a single list, library, or Web. Other times you will need to make a comprehensive approach and backup on a larger scale, such as the farm configuration, service applications, and content shared across multiple site collections.
But before your users call you to have you help them restore a file, a list item, or an accidentally deleted Web, wouldn’t it be great if they could just get their data back on their own?
By utilizing two features of SharePoint 2013, you can enable users to get themselves out of a lot of scrapes without even getting IT involved. This may not be the actual “backup” solution that you need for your farm, but it’s definitely worth mentioning because to the user that needs to do a restore it’s going to be a lifesaver.
Recycle Bin is available just for such an occasion, and the good news is that it’s enabled by default. You just need to make sure that the settings match with what you’re planning (the default is 30 days in the Recycle Bin).
Tip for restoring a Site Collection with PowerShell: After a site collection has been deleted, the Recycle Bin for the site is gone right along with the site collection. Now, if the site collection was deleted through PowerShell or some other code, it cannot be restored using this method, but if it was deleted through the browser, then you can use this command to restore a Site Collection from the Recycle Bin by using PowerShell.
Get-SPDeletedSite | Where-Object –Property URL –eq –Value “http://address.to.sitecollection/to/restore”) | Restore-SPDeletedSite
Enabling version history on lists and libraries is the other feature that will help your users be able to restore their own data. Version history keeps a copy of the documents and list items each time they are saved. Thanks to improvements in how SharePoint 2013 saves those changes, each saved version only uses space in the content database for the item changes. That’s right – the whole document isn’t saved again with each version of the document, which greatly reduces the impact on content database size.
Reverting back to a previous version of a file is easy and straightforward to the end users, and it makes you look like a superstar without you even doing anything.
Setting up version history and configuring the Recycle Bin can give huge returns for a minimal amount of effort, so you should definitely take advantage of that. But just because the users are empowered to save themselves doesn’t mean that your job is done. There are limits to what they can restore on their own, and there’s much more to SharePoint backups than simply saving the documents.
All of your Webs (the individual sites that make up your site collections), as well as the lists and libraries they contain, can be backed up either through Central Administration or through PowerShell.
You can find the Web backups in Central Administration under the Backup and Restore link on the Quick Launch navigation. From the Backup and Restore page, follow the Export a Site or List link under the Granular Backups heading.
If you’re going to use PowerShell, then you’ll want to use the Export-SPWeb cmdlet. This is a basic example using the two only required parameters – Identity (the Web to export) and Path (the file location):
Export-SPWeb –Identity “http://Sites/Projects/SharePoint2013” –Path “E:\Backups\SharePointProjectSite.cmp”
You may also want to get a backup a single site collection by using the Backup-SPSite cmdlet. Just as when you’re exporting a Web, you can get by with the basics: – Identity and Path for your parameters.
This is the big stuff that you need to work into your plan. You need to save your farm configuration data before you make changes to the farm configuration, and at regular intervals. You need to keep backups of your content databases as well.
You may have caught that fine point above about not being to use the PowerShell Restore-SPDeletedSite cmdlet to restore a site collection that had been deleted through PowerShell or programmatically. If you thought that meant that your site collection that had been deleted through PowerShell was lost beyond all hope, you’re wrong. It just means that you have to take it to the next level and restore from a previously backup of your content database.
Content databases span multiple Webs, lists, sites collections, and sometimes Web applications. Unless there is a total breakdown and you’re restoring everything, you should restore your content database back to a new name on the SQL server, and perform an unattached content database restore. Also, an unattached content database restore is something that you should practice before it’s needed.
Farm configuration is not only what servers are in your farm, but also all of the information for the service applications. Those service applications (such as Search and Managed Metadata) can contain the lifeblood of the SharePoint environment.
Recreating the service application is one thing, but duplicating the work that went into populating the term sets, or getting back the analytics data before an eDiscovery audit, is a terrible predicament.
To backup service applications, you can use the Backup-SPFarm cmdlet. To use Backup-SPFarm for backing up individual service applications, you need to enter the path of the Service Application into the –Item parameter. The path to the item can be found by entering Backup-SPFarm –ShowTree.
You can perform a farm configuration backup by also using the Backup-SPFarm cmdlet. Instead of specifying an -Item parameter, omit it and provide the cmdlet with a backup location in the -Directory parameter. Then specify the backup type (“Full” or “Differential”) in the –BackupType parameter.
The good thing about SQL backups is that you’ll end up with great results whether you’re approaching your SharePoint backups through SQL or SharePoint. Since your data is still in SQL, if you have effective backups on your databases, you’re going to be in good shape since you can restore your content databases to a new DB and perform unattached content database restores against the new databases.
VM snapshots are not a good replacement for SharePoint or SQL backups, because restoring to them is going to be an all-or-nothing endeavor. You may get back the data that was lost, but you’ll also lose any other changes that were made since that snapshot was created.
Third-party tools can be a great addition to your SharePoint farm. Honestly, they aren’t required, but those thirdparties focus their development efforts on providing those solutions, and they can be very effective and easy to use. If you can afford to bring them in, they are at least worth evaluating to see if they are a good fit for your organization and budget.
Hopefully, you’ve got a better idea now about the different ways that you can backup SharePoint 2013. From the “quick error” that the end user can fix to a full restore of a service application database, how you approach backups and restores can affect your and your end users’ workdays. Put thought now into improving your readiness, because when disaster hits, you’re in for what will either be “just another day, except I did a big restore today” or “one of the worst days of my professional life.”