\n
—FJ<\/span><\/span><\/span><\/p>\n \n Microsoft Scripting Guy, Ed Wilson, is here. I am so glad you asked that question. It gave me the opportunity to contact John Ferringer again because I knew this was right up his alley. <\/span><\/span><\/span><\/p>\n John Ferringer is a senior manager consultant with Sogeti, LLC. He has more than seven years of experience administering and supporting SharePoint technologies, and he has spent more than thirteen years working in the technology consulting industry. John is certified as an MCITP and MCTS on several platforms, including Windows Server 2008, SharePoint, SCOM, and Project Server. He has coauthored the <\/span><\/span><\/span>SharePoint 2010 Disaster Recovery Guide<\/span><\/a>. His blog can be found at <\/span><\/span>http:\/\/www.MyCentralAdmin.com<\/span><\/a>, and he’s on Twitter as <\/span><\/span>@Ferringer<\/span><\/a><\/span>.<\/span><\/span><\/p>\n \n Protecting a SharePoint farm can be pretty challenging. It’s one of those all too familiar IT problems that seems pretty straightforward (“Hey, let’s just run that Backup cmdlet and call it a day!”)—until you start diving into it and realize that there’s a lot more than that to getting it right. The nice thing is that we are talking about a pretty specific situation here: how to script a backup of a SharePoint farm by using SharePoint’s own backup tools. <\/span><\/span><\/span><\/p>\n Interestingly, the general intent and scope of SharePoint’s backup command-line tools did not change much from the product’s 2007 release to its 2010 release. Yes, SharePoint 2010 ships with plenty of great Windows PowerShell cmdlets, which is quite a big deal for the broader SharePoint command-line management story, but when it comes down to it, STSADM’s Backup operation with its catastrophic options are not a whole lot different from the new Backup-SPFarm<\/b> cmdlet. In addition, compatibility for STSADM was retained in SharePoint 2010, so if you already had a script that uses it, you can continue to take advantage of that investment if you want to.<\/span><\/span><\/span><\/p>\n A Windows PowerShell script for a SharePoint backup can be pretty simple. Just call Backup-SPFarm <\/b>or STSADM’s Backup operation, wrap it in some error checking logic, save it, create a Windows Scheduled Task to run it, and you’re good to go. If that’s the route you want to take, SharePoint’s backup tools still have some requirements that you need to keep in mind:<\/span><\/span><\/span><\/p>\n If you want to keep it vanilla, you can stop here. However, if you want to really turn things up to eleven, I have some further suggestions for you. It’s a bit more complex, but to me there’s a lot more that you need to take into account when backing up SharePoint. You want to provide your environment with the most effective, thorough, and (most importantly) repeatable protection possible. You want it to work right every time, yet you need it to efficiently use your available resources to provide that consistent protection.<\/span><\/span><\/span><\/p>\n The following is a list of items that I think are “must haves” for an effective SharePoint backup script that goes to eleven:<\/span><\/span><\/span><\/p>\n ·<\/span><\/span> <\/span><\/span><\/span><\/span><\/span>Analyze available storage before attempting a backup. <\/span><\/span><\/b>If you don’t have the storage available to keep a backup, your script needs to be able to handle that situation gracefully and report it effectively.<\/span><\/span><\/span><\/span><\/p>\n ·<\/span><\/span> <\/span><\/span><\/span><\/span><\/span>Take regular backups.<\/span><\/span><\/b> My general guidance for your backup frequency would be to do them at least daily, but your requirements may vary. Remember, the more you run backups, the greater the performance impact on your farm. The less frequently you back up, the less up-to-date your backups are.<\/span><\/span><\/span><\/span><\/p>\n ·<\/span><\/span> <\/span><\/span><\/span><\/span><\/span>Take advantage of varied backup types.<\/span><\/span><\/span><\/b><\/span>SharePoint allows you to perform both Full and Differential backups, so you want a script that is more heavily weighted toward Differential backups to save space, but a script that still takes regular Full backups to keep things current. <\/p>\n Note <\/strong> Differential backups capture everything that’s changed in the target SharePoint farm, database, or site collection since the last backup, rather than including everything in the farm. Differential backups require that you first take a Full backup, so you always have to have at least one Full backup. But you also want to continue to perform regular Full backups because large numbers of Differential backups can take a long time to restore.<\/span><\/span><\/span><\/p>\n ·<\/span><\/span> <\/span><\/span><\/span><\/span><\/span>Back up the entire farm.<\/span><\/span><\/span><\/b><\/span> This is one of those “at a minimum” kind of things. <\/p>\n Note: If you have high-priority site collections in your farm, you may want to also include logic in the script to individually target them. (You can do this with STSADM’s Backup<\/b> operation and its Site Collection<\/b> backup option or with the Backup-SPSite <\/b>cmdlet).<\/span><\/span><\/span><\/p>\n ·<\/span><\/span> <\/span><\/span><\/span><\/span><\/span>If you’re running SharePoint 2010, back up the farm’s Configuration Database individually.<\/span><\/span><\/b> All of a farm’s settings and setup information is stored in its Configuration database, and the new Backup-SPConfigurationDatabase<\/strong> cmdlet in SharePoint 2010 provides you with a nice tool to individually back up this critical resource as an additional layer of coverage for your farm. It’s not a complete capture of your farm’s configuration data, but it’s a start. See <\/span><\/span><\/span><\/span>Configuration-Only Backup and Restore in SharePoint 2010<\/span><\/span><\/a><\/span> for a great explanation of its limitations.<\/span><\/span><\/p>\n ·<\/span><\/span> <\/span><\/span><\/span><\/span><\/span>If you have SharePoint 2010, merge the SharePoint usage log files.<\/span><\/span><\/span><\/b><\/span> Microsoft recommends doing this, so it is at least worth considering for your script. <\/p>\n Note: This can have some performance implications if you decide to merge all log files, so keep an eye on it. If it takes a long time to run, try limiting this to specific usage types.<\/span><\/span><\/span><\/p>\n ·<\/span><\/span> <\/span><\/span><\/span><\/span><\/span>Handle and report errors.<\/span><\/span><\/b> This may seem like a tiny detail, but trust me, when a backup fails you want to know about it. Write your scripts to handle errors, and write them to your server event log for monitoring and alerting.<\/span><\/span><\/span><\/span><\/p>\n ·<\/span><\/span> <\/span><\/span><\/span><\/span><\/span>Rotate backup files. <\/span><\/span><\/b>![\"Hey,](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/q-for-powertip.jpg\" "\\"Hey,")
Hey, Scripting Guy! I’ve heard that I can automate the backup of my SharePoint farm with a Windows PowerShell script, but it seems like it’s a lot more complicated than just calling STSADM or Backup-SPFarm<\/strong>? What should I be including in my SharePoint farm backup script?<\/span><\/span><\/span><\/p>\n![\"Hey,](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/a-for-powertip.jpg\" "\\"Hey,")
Hello FJ, <\/span><\/span><\/span><\/p>\n![\"Photo](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/3157.HSG-6-22-11-1_59261CED.png\" "\\"Photo")
<\/a><\/span><\/span><\/span><\/p>\n\n
\n
\n