Due to a recent act of user stupidity, I've been tasked restoring a file from a backup of our SharePoint site, and due to management decisions, we don't have, and aren't going to get the ability to use a plugin for our SharePoint backups, making restoring files from SharePoint quite the ordeal.

(At the moment, I'm building up a new database server on old hardware so I can attach the site database and run a TSQL script to extract the file.)

Since I very much don't want to have to do this ever again, it looks to me like the best solution is to turn on versioning for all our sites' various document libraries, and before I go about writing this script, I was wondering if anyone had already written one, or had another quick-and-easy way to accomplish the same thing. I came across this blog post in my Googling, which convinced me that it's at least possible, but it uses PowerShell and is for SharePoint 2010, and we use SharePoint 2007 running on Server 2003 (without PowerShell installed).

Does anyone here have a solution that they think might work, or maybe even a different approach that might be beneficial?

2 Answers 2


Did they look in the recycle bin?

Global versioning is a bad idea for a training issue, storage costs will skyrocket as Sharepoint doesn't do diff versioning, it's a copy of the item. I've seen single document libraries with a handful of files get into the gigabyte ranges because of versioning and improper setup. Imagine that farm wide with every file. Just changing metadata results in a new version of the file.

In a past work environment, we had along with the SQL Server backups, some stsadm backup commands that ran nightly to do a backup of each site collection. So in the off chance we had to recover a file, we could restore the offending site collection instead of restoring the enire database.

  • Someone deleted auditing data from within a file, so the Recycle Bin (which is also inexplicably turned off) isn't gonna help. And while I'm aware of the storage implications, I'm much less concerned about them than the state we have now where restoring a SharePoint file from our backups takes many hours of my time and involves building new systems from scratch. Worst-case scenario I can see is that management actually sees what the true cost of our current implementation is and lets us improve it Dec 12, 2013 at 22:19
  • 1
    In your script logic you can also limit the number of versions as well. That could assist keeping storage costs from getting out of control.
    – tyshock
    Dec 12, 2013 at 22:21

There's an alternative solution that may be worth considering - the completely nontechnical approach.

Once you've shown management how great is the cost to recover a deleted file, propose that they enact a new policy along the lines of:

Due to the high costs involved in recovering data from SharePoint backups, we will no longer perform such recovery for individual overwritten files within SharePoint libraries on which versioning has not been enabled. Effective [x date] (some reasonable timeframe after this policy is announced), all site owners will be responsible for:

  • Understanding the concept of SharePoint versioning, including its impact on storage utilization (provide link to informational document),
  • Determining the probability of needing to recover a previous version of any file on their site, and how easy or difficult it would be to recreate those files in the absence of backup recovery by IT or the impact of not recovering them, and
  • Determining for which of their site's libraries the storage impact of enabling versioning on that library is outweighed by the risks and impacts of manually recreating or being unable to recover the prior versions of those files, and enabling versioning on those libraries.

Put simply, each site owner would be expected to make a risk/benefit analysis of enabling versioning on their libraries. If they do not enable versioning on a given library, they are effectively saying "The files in this library are easy enough to recreate in a pinch, or are of low enough importance, or the chance of an accidental overwrite is so unlikely, that we are willing to accept that risk."

  • After writing this answer on my own, I found the following on my organization's SharePoint hub site: "All content within SharePoint is stored within a Microsoft SQL Server database.... including configuration, search, user profiles, terms, security, etc. Backups are created for disaster recovery and business continuity purposes and NOT for every day restores. Content from a backup is only restored in the event of a catastrophic loss of data or corruption of a site. As a matter of practice individual sites, lists, libraries, items, or documents are NOT restored from tape backup." Aug 11, 2016 at 19:05
  • I no longer work for those particular cheap morons... not that this would have worked, as their attitude was "that's a computer thing, IT needs to do that." Aug 11, 2016 at 19:35
  • @HopelessN00b yeah, I saw this was a really old question, so this answer is more for those who might find this question today from a search than for you as the OP. I didn't figure it was still an open question from your own perspective after nearly 3 years! Aug 11, 2016 at 22:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.