Hi there, Everynight, I take a backup of the web application running on port 80 of sharepoint. The backup file size is around 25 GB. I use the command below: stsadm.exe -o backup -url http://portal -filename \\srv32\Backup\Sharepoint\1\portal.bak -backupmethod Full -overwrite The problem is, during the backup http://portal becomes inaccessible. When you navigate, it says "error occurred" or does not display at all. What am I missing here? Is this normal during backups?

Hi, No, it isn't normal. You stated you've been taking the backup before, that means you haven't been having this problem. First, the command is a bit off. This is for site and sitecollections: stsadm -o backup -url <url> -filename <filename> [-overwrite] This is for a full farm backup that you want: stsadm -o backup -directory <UNC path> -backupmethod <full | differential> [-item <created path from tree>] [-percentage <integer between 1 and 100>] [-backupthreads <integer between 1 and 10>] [-showtree] [-quiet] Another item to watch out for is site locks, this is how to unlock: stsadm -o setsitelock -url <url> -lock <none | noadditions | readonly | noaccess>You've only got one life; help as many people as you can, and enjoy it while it lasts.

I am trying to backup a single site collection under a web application.. it is: http://portal the only difference with your first command is the backupmethod parameter. I am not trying to take a full farm backup .. I just need to backup the http://portal , http://portal:81 etc.. Do you think the problem is "-backupmethod full" parameter? Yes I wasnt having this problem before. But I just thought it was because of the growth of the data. Back then, It was under 10 gb now its 25 gb - (a single site collections content database it is )

Hi, In that case, simply use stsadm -o backup -url "http://servername:port/sites/sitename" -filename "D:\Foldername\sitename.bak" -overwrite You don't need to specify Full or Differential, it's always a full. When you are done check the size of the backup and ask yourself if the size is commensurate to what you imagine the site's size to really be. If you are in doubt, check the SQL database for a near-comparison. And if you are in doubt of an active lock or not, run this first: stsadm -o setsitelock -url "http://servername:port/sites/sitename" -lock none Let's see how it goes for tonight's backup.You've only got one life; help as many people as you can, and enjoy it while it lasts.

Got a couple of thoughts on this subject: 1) If your SharePoint 2007 environment is patched to Service Pack 2 or later, there's no point in locking the site prior to the backup. In Service Pack 2 STSADM's Backup operation was modified to automatically include lock site collections before they're backed up and unlock them once the operation completes (http://technet.microsoft.com/en-us/library/cc262811%28office.12%29.aspx ) 2) Without direct knowledge of your environment its difficult to know exactly what is causing the problem with your backup, but honestly I'm not surprised that you're having issues with a backup of that size. I'm not trying to be harsh, its just that Microsoft doesn't recommend using STSADM to back up a site collection with more than 15 GB of content in it, because site collections larger than that can run into issues exactly like you're having because it can take so long to backup that much content. For MS's specific guidance on the subject, I'd highly recommend taking a look at http://technet.microsoft.com/en-us/library/cc706871%28office.12%29.aspx . If your backup file is 25 GB, I would have to think your site is even larger than that, so you're in the range where you'll probably see problems. If you want to try to troubleshoot the issue, one thing I'd look at would be checking for any running search crawls of that content (or in general if you're running the backup from the Index server) occurring while the backup is run, or if there are any other timer jobs running at that time. They could be causing resource contention issues on your SharePoint server or its Database server. You could also check the performance metrics of your SharePoint and SQL servers, there may be perf issues there too. My recommendation would be to move the site collection to its own content database (if its not on its own already) and back that content database up through SQL Server rather than with STSADM. Its going to be much more reliable and can handle the size of your site much better than STSADM. Even if you resolve the contention issue you're facing now, there could easily be other issues down the road that will crop up and threaten your backups, which is why I'd recommend moving to something more stable now. JohnMCTS: WSS v3, MOSS 2007, and SCOM 2007 Now Available on Amazon - The SharePoint 2007 Disaster Recovery Guide. Coming Soon - The SharePoint 2010 Disaster Recovery Guide. My blog: My Central Admin.