I started a backup at 5pm yesterday evening and it is now 9.15am the following day and the backup is still running. That's over 16 hours! I don't believe the site to be too large, there are 10 sites with an average of 3 sub sites. Only a handful of them would have more than 2 pages in each. There are also a couple of lists but only around 100 items in total in all the lists.

I tried creating the backup by going to Site > Administration > Backup Web Site and the dialog box has said "Creating backup files" with the animation of paper moving from one folder to another.

SharePoint Backup

There is no progress bar, no indication of how long it will take, no indication of it doing anything! Is this the right way to do the backup? Should it take this long?!

  • Will the backup process interupt users?
    – user9790
    Commented Jul 31, 2012 at 22:55

3 Answers 3


I'm glad you included an image of the operation in progress, because it makes it easier to clear up some confusion and answer your question. I think previous respondents missed the fact that you're actually working in SharePoint Designer 2007 -- not Central Administration or the command line.

First, let me clear up some confusion: the operation you're carrying out through SharePoint Designer 2007 (SPD) is not actually a backup. Even though the menu item lists the operation as "Backup Web Site," what you're actually doing is creating an export - not a backup. This is important for a couple of reasons:

  1. Export operations from within SharePoint leverage the Content Deployment API (aka the "PRIME API") and are not full-fidelity. Things like workflow state, alerts, and some other items will not be captured by an export.

  2. When it comes to getting data out of SharePoint for protection, export operations are among the slowest mechanisms available compared to the standard backup operations.

Should it take 16 hours or more to export your data? Believe it or not, it certainly can. In tests that my team ran for export speeds with SharePoint 2007 (we work on a commercial backup product), it wasn't uncommon to see 10+ hours for a 100GB site collection. The actual amount of time it takes is dependent upon the nature of the data being backed-up, the amount you have, your hardware capabilities, etc., but 16 hours isn't unheard of.

If I had to guess, your export is probably stalled-out. While SharePoint is generating the export package (one or more .cmp files), they are temporarily being written to the site collection you are "backing up" unless you specified an alternate location using the "Advanced ..." button prior to the start of the operation. If your administrator has any sort of reasonable quota in-place, all those temporary files probably ran the site collection up to the max and caused the operation to seize.

So, now that you know what's actually happening in your case, here's what I suggest: if you need to back up or get data out of SharePoint 2007, your options (from fastest to slowest) are:

catastrophic backup > site collection backup > export

Each of these operations can be performed from the command line through STSADM. If you want to perform a backup (rather than an export) using a UI, only the catastrophic backup (farm backup) option will be available to you through Central Administration. Note: if you were using SharePoint 2010, you'd have PowerShell and some other Central Admin options available to you.

Some tips on each:

Catastrophic (full farm) backup: If all you need is a site collection, you'll still have to grab the entire database containing the site collection. The backup/restore API doesn't get any more granular than the database level. Still, your backup will be faster than either a site collection backup or an export, and it can be restored to your current farm (if there's loss) or ported to another farm without issue.

STSADM.exe -o backup -directory <UNC path> -backupmethod <full | differential> -item <ID of the target database>

Site collection backup: This method has been pointed out by a couple of respondents, and it will generate a single .bak file that is a backup of your site collection only. This backup method actually punches down to unmanaged code to operate, and it is still significantly faster than performing an export. Worth mentioning is that Microsoft does not recommend this option for site collections that are larger than 15GB in size, though you can make it go significantly farther than recommended.

STSADM.exe -o backup -url <site collection URL> -filename <name of backup file to create>

Export: You've already seen this first-hand. It's great for granular (item-level) data, but pretty poor and slow for capturing entire site collections. You can do this through SPD (as you were doing) or with STSADM.

STSADM.exe -o export -url <site collection/site/list to export> -filename <export file name>

If you aren't a farm and server administrator, I'll tell you straight away: you're going to be out of luck with regard to the methods I mentioned (Central Administration and command line options). You'll need to enlist the help of your (hopefully) friendly SharePoint administrator to carry things out on your behalf.

I hope that helps!

  • 1
    As I started reading through this thread, I was wincing because I knew I wasn't going to be able to walk away from it without commenting but that it was going to require a lot of attention. But, much to my relief I found this response which had already devoted exactly the attention I felt necessary (and after the second paragraph I knew who had written it, which was even more of a relief ;) ). I know this is a long answer, but I think there's a lot you need to think about with this issue and Sean tackles it ALL for you. Commented Nov 2, 2011 at 13:20

The actual time of a backup will depend on a few things

  • Size of the database
  • Hard drives being backed up from, are they fragmented, older, slower, etc.
  • Existing activity on the server during the backup
  • Backup destination, library vs network share vs SAN, etc.

The first one is easy to find out, and is really the biggest factor. There will be a difference between a 1GB and a 10GB backup. Taking 16 hours for a backup however probably isn't simply a database size issue... Where are you backing it up to? Dragging a 5GB database over a 10MB network to older IDE hard drives would take a long time (vs a 1GB network to SCSI or SATA drives), but again 16 hours seems ridiculously long, almost like you're going over a WAN.

Also, like @David Nordqvist said, use the SharePoint stsadm backup feature, or with SharePoint 2010 use the powershell command

backup-spsite http://url -path PathtoBackup
restore-spsite http://url -path PathtoBackup



The best way to backup a SharePoint site is –

Stsadm –o backup –url <SiteURL> -filename <FileName>

And then at a later date you can restore the site using

Stsadm –o restore –url <restoretoURL> -filename <filetorestorefrom>

However, the above commands must be run using proper access rights, or the restore will be half crap.

  • So I should stop the backup that is currently running? It shouldn't be taking > 16 hours then! Why would the Backup Web Site option be included if it doesn't work right? How long should a backup take? Commented Nov 2, 2011 at 9:35
  • the back up size depends upon the size. In you case, it might have hunged up or frozen...but I would strongly recommend you to use stsadm to perform the same task in parallel to see how long it takes. Commented Nov 2, 2011 at 10:12

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.